What A Cryptographic Inventory Is, And What It Should Tell You
A cryptographic inventory links each algorithm, key and certificate to a system, an owner and the data it protects. Here is what to record and why a list of algorithms is not enough.
Checked against primary sources and independently reviewed on . Sources are listed at the end.
Every government roadmap for post-quantum migration starts with the same step: find out where your organisation uses cryptography. The CISA, NSA and NIST joint factsheet of 2023 named a cryptographic inventory as a core early task, alongside a roadmap, a supply chain assessment and conversations with vendors.1
The word “inventory” can mislead. A spreadsheet of algorithm names found by a scanner is a start, but it does not tell you what to do next. This article explains what a useful inventory records, how much detail is needed at each stage, and how to keep it honest about what it does not know.
More Than A List Of Algorithms
Knowing that RSA-2048 appears somewhere in your estate is not actionable. Knowing that RSA-2048 signs the certificates for a customer portal run by a named team, on a load balancer from a specific vendor, protecting data that must stay confidential for seven years, is actionable.
Europol’s 2026 report on prioritising migration in financial services makes this point by framing the inventory around business use cases that rely on public-key cryptography, rather than around individual technical assets.2 NIST’s NCCoE takes a complementary approach, correlating discovered cryptography with the hardware, software and services already in an organisation’s asset inventory.3 Both point the same way: tie each finding to the thing the business cares about.
- Algorithm, Key And ParametersFor example ECDH on curve P-256, or RSA with a 2048-bit key. Record the exact variant rather than only the family.
- Certificate And ProtocolWhere the algorithm is used: a TLS 1.2 endpoint, an SSH host key, a code signing certificate, with validity dates.
- Library, Module Or HSMWhat implements it: a library version, an operating system component, a hardware security module.
- Application, Device Or ServiceThe system that depends on it, with version and patch level.
- Business Use Case And Data Shelf LifeWhat the system does and how long its data must stay confidential or trustworthy.
- Owner And SupplierWho can change it: an internal team, a managed service provider or a vendor with its own roadmap.
What The Official Guidance Asks For
The UK National Cyber Security Centre lists what its discovery phase should cover: your services and data holdings, including how long the data is expected to remain valuable; how data is protected in transit and at rest; whether systems are on premises or in the cloud and who manages them; and hardware such as network equipment, mobile devices, servers, IoT and industrial control devices, and tokens issued to users. It also asks for version information and patch levels where available.4
The NCSC is clear that at this first stage the aim is to understand the nature of each system, not to build a formal register of every item.4 OMB sets a higher bar for US federal agencies over time: a dynamic, continuously updated inventory of all cryptographic assets, built with automated tools wherever possible and feeding a central cryptographic bill of materials (CBOM).5 The CBOM article explains that format.
Lifecycle data matters too. The CycloneDX CBOM guide gives a simple example: an RSA certificate that expires next week carries less risk than the same certificate valid for another 20 years.6
Record The Evidence Behind Each Finding
An inventory supports decisions, so each entry should show where it came from. A finding without provenance is hard to trust and impossible to re-check. For every observation, keep:
| Field | Why it matters |
|---|---|
| Source | Which tool, scan, file, interview or supplier statement produced the finding. |
| Scope | What was examined, and what was deliberately left out. |
| Collection date | Configurations change. A finding from last year may no longer be true. |
| Supporting evidence | The certificate, configuration line or handshake record behind the finding, kept close to it. |
| Confidence | Whether the finding was observed directly, inferred, or reported by a third party. |
| Open questions | Unknown purpose, unknown owner, incomplete collection. |
How Much Detail, And When
A reasonable approach is to work in two passes. The first pass, as the NCSC suggests, builds a system-level picture: which services use public-key cryptography, who runs them, how long their data matters and which suppliers are involved.4 That is enough to draft a plan and spot the obvious priorities.
The second pass goes deeper on the systems that matter most or that you run yourself, mapping the exact algorithms, protocols and hardware they depend on. The NCSC notes that this deeper work is most needed for IT and operational technology an organisation manages directly.4 For commodity platforms, the supplier’s roadmap often matters more than a scan.
The NCSC recommends combining two directions of work. A top-down view starts from core services and how they depend on each other. A bottom-up view explores the network and systems directly to find components that need updating. It also asks organisations to identify dependencies between components, which helps show where the change will be simple, for example because a provider or routine supplier update will handle it.4 The same map is also a practical way to spot where one upgrade will unblock several others.
Keeping It Current
An inventory goes stale as soon as systems change. OMB’s expectation of a continuously updated inventory, fed by automated tools and dashboards, reflects that.5 In practice, the inventory should be refreshed when significant systems change, when suppliers publish new roadmaps, and on a regular schedule. Compliance regimes may set their own review intervals; see Cryptography Compliance for those.
Footnotes
-
CISA, NSA and NIST, “Quantum-Readiness: Migration to Post-Quantum Cryptography”, 21 August 2023. cisa.gov ↩
-
Europol, “Prioritising Post-Quantum Cryptography Migration Activities in Financial Services”, Publications Office of the European Union, 2026. Contributing authors: Oscar Covers, Thibaud Ecarot, Rebecca Gibergues, Jaime Gómez García, Francis Gorman, Imran Khan, Ivan Makarov, Sarah McCarthy, Michele Mosca, Iván Soto, Leila Taghizadeh and Jelena Zelenovic. Licensed under CC BY 4.0. europol.europa.eu ↩
-
NIST National Cybersecurity Center of Excellence, SP 1800-38B (preliminary draft), “Migration to Post-Quantum Cryptography: Quantum Readiness: Cryptographic Discovery”, December 2023. nccoe.nist.gov ↩
-
UK National Cyber Security Centre, “Timelines for migration to post-quantum cryptography”, 20 March 2025. ncsc.gov.uk ↩ ↩2 ↩3 ↩4 ↩5
-
Office of Management and Budget, “Execution of the Migration to Post-Quantum Cryptography” (M-26-15), 24 June 2026. whitehouse.gov ↩ ↩2
-
OWASP CycloneDX, “Authoritative Guide to CBOM”, second edition, 21 October 2025. cyclonedx.org ↩
Knowledge Hub content is general information. It is not legal advice, a compliance certification, a guarantee of security or a substitute for an assessment of your own systems. Standards and rules change; check the sources for the latest position.