How to build a cryptographic inventory: what to record, cryptographic discovery methods compared, certificate discovery, CBOM, prioritisation and a 90-day plan.
A cryptographic inventory is a maintained record of every place your organisation uses cryptography: which algorithms, key sizes, certificates, keys, libraries and protocols are in use, on which systems, protecting which data, owned by whom. It is built through cryptographic discovery (scanning networks, hosts, keystores, key managers, code and certificate sources) and it is the first step of every post-quantum migration programme, because you cannot replace RSA or ECC in places you don't know about.
Most organisations already believe they know where their cryptography lives: the load balancers, the PKI, the HSM. Discovery usually proves otherwise. Certificates sit in Java keystores nobody owns, applications pin libraries that negotiate legacy cipher suites, cloud KMS keys were created by teams that have since moved on, and vendor appliances embed cryptography that no scanner can see. Regulators have noticed: the US federal government has required a prioritised cryptographic inventory since 2023, and European and Swiss supervisors now expect one as part of quantum-risk management.
This guide explains what to inventory, compares the discovery methods and their blind spots, covers certificate discovery specifically, shows how an inventory becomes a CBOM, and ends with a 90-day plan you can start this quarter.
The business problem is simple to state. A cryptographically relevant quantum computer would break the public-key algorithms (RSA, ECDH, ECDSA) that protect key exchange and signatures almost everywhere. Replacing them is a multi-year engineering programme, and data recorded today can be decrypted later. You cannot budget, sequence or prove that programme without knowing where those algorithms are used. That is why the major public frameworks put the inventory first.
OMB Memorandum M-23-02, "Migrating to Post-Quantum Cryptography" (18 November 2022) directs federal agencies to submit, by 4 May 2023 and annually thereafter until 2035, a prioritised inventory of information systems and assets that contain CRQC-vulnerable cryptographic systems, to ONCD and CISA. The scope focuses on high-impact systems, High Value Assets, systems with data expected to remain mission-sensitive in 2035, and PKI-based access control. For each system, agencies must record, among other fields, the cryptographic algorithm used, the service it provides, key length, the software vendor, the operating system and version, the hosting model and how long the data needs protection ("time to live").
That field list is a good template for any organisation, regulated or not. The memo also counts a cryptographic system as "actively used" if it can be employed, even only for legacy clients, which is exactly the kind of fallback configuration discovery tends to surface. Our overview of US post-quantum regulation covers the wider federal timeline.
The joint factsheet "Quantum-Readiness: Migration to Post-Quantum Cryptography" (CISA, NSA, NIST, August 2023) tells organisations to start with "proactive cryptographic discovery activities" and to use discovery tools to find quantum-vulnerable algorithms in three places:
It adds two points that matter for scoping. Discovery tools may not see cryptography embedded inside products, so you should ask vendors for lists of embedded cryptography. And the inventory should be correlated with existing asset, identity (ICAM/IdAM), EDR and CDM inventories, and should record how long the most sensitive datasets need protection.
The NIST National Cybersecurity Center of Excellence project "Migration to Post-Quantum Cryptography" is documented in NIST SP 1800-38. Volume B, "Quantum Readiness: Cryptographic Discovery", describes a functional test plan for discovery tools, an approach to discovery most organisations can start now, and a lab architecture that integrates contributed discovery tools. The latest versions we could verify on csrc.nist.gov are preliminary drafts (Volume A April 2023; Volumes B and C December 2023), so treat it as practical guidance rather than a final standard.
In Switzerland, FINMA Guidance 05/2026 expects supervised institutions to keep a continuously updated cryptographic inventory and a board-approved PQC roadmap; see our FINMA 05/2026 post-quantum roadmap guide. For EU financial entities and essential entities, see DORA encryption requirements and NIS2 crypto-agility requirements.
A useful cryptographic inventory is not a list of certificates. It covers every asset type that carries or performs cryptography, and records enough context to make a migration decision.
| Asset type | Where it hides | What to record |
|---|---|---|
| TLS/X.509 certificates | Load balancers, web servers, API gateways, Kubernetes secrets, Windows certificate stores, PEM files, appliances | Subject/SANs, issuer, signature algorithm, key algorithm and size, expiry, owner, endpoints served, quantum risk |
| Private keys and keystores | PEM/DER files, PKCS#12/PFX, JKS/JCEKS, TPMs, application config directories | Algorithm, key size, format, location, protection (file, HSM, KMS), owner, linked certificate |
| KMS and HSM keys | Cloud KMS (AWS, Azure, GCP), on-premises HSMs, vaults | Key ID, algorithm, size, usage (encrypt, sign, wrap), rotation policy, data protected, owner |
| Protocols and cipher suites | TLS endpoints, IPsec/IKEv2 VPNs, SSH, internal service mesh | Protocol version, key exchange group, cipher suite, whether a PQC or hybrid key exchange is offered |
| Libraries and code usage | OpenSSL, BoringSSL, Java JCA/JCE, .NET, Go crypto, vendored libraries, CI/CD dependencies | Library and version, algorithms called, hard-coded parameters, owning application |
| Signing infrastructure | Code signing, firmware and software update signing, document signing, internal CAs | Algorithm, key size, validity, where the key lives, which artefacts depend on it |
| Embedded and vendor cryptography | Network appliances, OT devices, SaaS, COTS software | Vendor statement of algorithms, PQC roadmap, contract renewal date |
| Data at rest | Databases, backups, storage encryption, archives | Algorithm, key reference, data classification, required protection lifetime |
For each entry, the minimum fields are: algorithm, key size, owner, expiry or rotation date, library or product, protocol, the data it protects, and a quantum-risk rating. Algorithm and key size tell you whether it is quantum-vulnerable; owner tells you who fixes it; data lifetime tells you how urgently.
No single technique finds everything. Each method sees a different layer, and the gaps are predictable.
| Method | What it finds | Strengths | Blind spots |
|---|---|---|---|
| Passive or active network/TLS scanning | Certificates, protocol versions, cipher suites and key exchange groups on reachable endpoints | Fast, agentless, covers external attack surface first | Only sees what is negotiated on the wire; misses data at rest, internal libraries, unreachable segments |
| Host and filesystem scanning | Certificate and key files, keystores, OS certificate stores | Finds orphaned keys and certificates nobody registered | Needs an agent or credentials per host; does not show which code uses the key |
| Keystore, HSM and KMS APIs | Managed keys with algorithm, size, usage and metadata | Authoritative for managed keys; low noise | Only covers keys created in managed systems; shadow keys stay invisible |
| Code, SBOM and library analysis | Crypto API calls, libraries and versions, hard-coded algorithms | Finds cryptography before it ships; fits CI/CD | Static analysis can over- or under-report; runtime configuration may differ |
| CA exports and Certificate Transparency logs | Certificates issued by your CAs or for your domains | Complete for publicly trusted certificates; no access to systems needed | CT covers only publicly logged certificates; private CA coverage depends on export quality |
| Vendor questionnaires | Embedded cryptography in products and services | The only way into closed products | Self-declared; needs follow-up at contract renewal |
The practical answer is to combine them: network scanning for exposure, host and keystore scanning for what sits on disk, KMS/HSM APIs for managed keys, code analysis for what your developers build, and vendor engagement for what you cannot scan. Then de-duplicate: the same certificate seen on a load balancer, in a PFX file and in a CT log is one asset with three locations.
Certificates are usually the largest and fastest-changing part of the inventory, and a certificate discovery tool is often where teams start. Four sources together give good coverage:
Reconcile the four: a certificate in CT but not on the network may be unused (or deployed somewhere you don't scan); one on the network but not in any CA export is unmanaged. Both deserve a ticket. Once found, certificates belong under lifecycle management; see DuoKey certificate management.
A cryptographic inventory is the working data set; a CBOM (Cryptography Bill of Materials) is a standardised, machine-readable export of it. CycloneDX added CBOM support in version 1.6, released by OWASP on 9 April 2024, described in the release as "a structured framework for inventorying cryptographic assets". The difference matters in practice. Your inventory can hold owners, tickets, risk decisions and business context. The CBOM is what you exchange with auditors, vulnerability-management tools and suppliers, and what you diff between releases. Our CBOM guide for DuoKey Cockpit walks through generating and reading one step by step, so we do not repeat it here.
A first discovery run typically returns thousands of findings. Rank them on two axes:
| Short data lifetime | Long data lifetime | |
|---|---|---|
| High exposure (internet, partners) | Plan migration; watch certificate lifetimes | Highest priority: hybrid or PQC key exchange first |
| Low exposure (internal) | Migrate with normal refresh cycles | Schedule early; check backups and archives |
Signatures follow a different logic: they cannot be forged retroactively, so priority goes to long-lived trust anchors such as root CAs, firmware and code-signing keys, whose replacement takes the longest. Our PQC migration roadmap guide shows how to turn this ranking into a sequenced plan.
A one-off inventory is out of date within weeks: certificates renew, new services ship, cloud teams create keys, vendors push updates. A one-off project is still a valid way to produce the first baseline and the first regulatory submission, but it should hand over to a continuous process:
This continuous loop is what the market calls cryptographic posture management: discover, score, plan and remediate, then discover again.
Days 1-30: scope and baseline
Days 31-60: go inside
Days 61-90: decide and operationalise
DuoKey's PQC Scanner is the discovery engine of DuoKey cryptographic posture management (CPM). Per the DuoKey documentation, it discovers:
Findings are rated P1 to P4 by algorithm (RSA, DSA, 3DES, RC4, ECDSA P-256 and EdDSA are flagged; ML-KEM, ML-DSA and SLH-DSA are P4, informational). Each scan produces a Quantum Readiness Score (QRS) from 0 to 100 and a CBOM, with compliance references to CNSA 2.0 and BSI TR-02102, and a ServiceNow integration to track migration work.
DuoKey CPM runs this as a continuous loop (discover, score, simulate, remediate) with a living CBOM, drift alerts, simulation reports, remediation pull requests drafted by an agent and approved by a human, ServiceNow sync, and regulatory mapping to DORA, NIS2, FINMA 05/2026, NIST IR 8547 and CNSA 2.0.
For a first view before granting any access, start with the free Quantum Risk Score, which needs no access to internal systems. The scanner and CPM run on the DuoKey Cockpit platform; for anything beyond what is listed here, contact DuoKey.
Q: What is a cryptographic inventory?
A cryptographic inventory is a maintained record of all cryptography in use across an organisation: algorithms, key sizes, certificates, keys, libraries and protocols, with their location, owner, expiry and the data they protect. It is the basis for assessing quantum risk and planning a post-quantum migration.
Q: What is cryptographic discovery?
Cryptographic discovery is the process of finding cryptography automatically, by scanning networks and TLS endpoints, hosts and keystores, KMS and HSM APIs, source code and dependencies, and certificate sources such as CT logs and CA exports. Its output feeds the cryptographic inventory.
Q: How do I find all certificates in my network?
Combine four sources: Certificate Transparency logs for publicly trusted certificates on your domains, network scans of your IP ranges and DNS names, exports from your internal CAs, and host scans of keystores and certificate files. Then reconcile them, because each source misses certificates the others find.
Q: What is the difference between a cryptographic inventory and a CBOM?
The inventory is your working data set, including owners, risk decisions and remediation status. A CBOM is a standardised, machine-readable export of cryptographic assets, defined in CycloneDX since version 1.6, used to share the inventory with tools, auditors and suppliers and to compare it over time.
Q: Is a crypto inventory required by regulation?
In the US federal government, yes: OMB M-23-02 requires agencies to submit a prioritised inventory annually from 4 May 2023 until 2035. In Switzerland, FINMA Guidance 05/2026 expects supervised institutions to maintain one. In the EU, DORA and NIS2 cryptography and asset-management obligations make an inventory the practical way to show compliance.
Q: Which algorithms count as quantum-vulnerable cryptography?
Public-key algorithms based on factoring or discrete logarithms: RSA, Diffie-Hellman, ECDH, ECDSA and DSA. OMB M-23-02 lists these and asks agencies to include any asymmetric algorithm not definitively known to be quantum-resistant. Post-quantum algorithms such as ML-KEM, ML-DSA and SLH-DSA are the replacements.
Q: Can a scanner find all cryptography automatically?
No. Scanners miss cryptography embedded in closed products and appliances, and each method sees only its own layer. The CISA, NSA and NIST factsheet recommends asking vendors for lists of embedded cryptography to close that gap.
Q: How often should a cryptographic inventory be updated?
Continuously, or at least on every significant change. Certificates renew, keys are created and services ship every week, so a one-off inventory goes stale quickly. Use scheduled and CI/CD-triggered scans, drift alerts and periodic CBOM exports.
A cryptographic inventory turns quantum risk from an abstract warning into a list of assets with owners and dates. Build it from several discovery methods, record the context that drives decisions, export it as a CBOM, and keep it running.
Written by
DuoKey Team
Related Resources
Tell us where control is difficult today. We will help you identify a practical next step.
