Most organisations cannot say which algorithms, keys and certificates their systems rely on, so they cannot retire weak cryptography, rotate a stolen key quickly or plan a post-quantum migration. A cryptographic inventory answers three questions for every system: what cryptography is in use, where the keys and certificates live, and who owns them. A Cryptography Bill of Materials (CBOM) is the machine-readable format that records those answers and their dependencies. This guide explains how to scope an inventory, which discovery techniques find what, how to model the results in CycloneDX CBOM, and how to keep the inventory current. It is written for security architects, PKI and platform teams, and the people who will run a post-quantum programme. Migration planning itself is covered in the Post-Quantum Cryptography Migration Guide; this page stops at a trustworthy inventory.
Key takeaways
- Inventory is the prerequisite for everything else. NIST, CISA and the UK NCSC all put discovery first: the NCSC timeline expects discovery and an initial plan by 2028, before priority migration by 2031 and completion by 2035.
- No single tool sees everything. NIST SP 1800-38B describes four discovery angles (source code and CI/CD, endpoint filesystem scanning, binary analysis, network traffic) because each one misses what the others catch.
- Keys and certificates are non-human identities. A signing key or TLS certificate authenticates a machine or service, so it needs an owner, a lifetime and a revocation path like any other NHI.
- CBOM gives the inventory a standard shape. CycloneDX 1.6 and later model algorithms, certificates, protocols and related crypto material, with dependency links that show which component uses which asset.
- An inventory is a process, not a project. Generate CBOMs in the build pipeline, rescan the estate on a schedule and measure coverage, or the data will be stale before the migration starts.
What a cryptographic inventory must contain
A software bill of materials lists components. A cryptographic inventory goes one level deeper and records how each component uses cryptography. The NCCoE discovery work (SP 1800-38B) treats both executables (application binaries, cryptographic libraries, Java archives) and non-executables (keystores, X.509 certificates, OpenSSH keys, PKCS#1 and PKCS#8 key files) as cryptographic assets, and asks that each one is tied back to the hardware, software or service it belongs to and to whether it is developed in-house or supplied by a third party.
| Asset class | What to record | Why it matters |
|---|---|---|
| Algorithms | Family, primitive (signature, KEM, key agreement, block cipher, hash), parameter set or key size, mode and padding, classical and quantum security level | Finds RSA-1024, SHA-1, 3DES, ECB mode and every quantum-vulnerable public-key scheme |
| Keys and secrets | Type (private, public, secret), size, algorithm, state, storage location (HSM, KMS, file, memory), creation and expiry dates, owner | Keys are what attackers steal; location and lifetime drive exposure |
| Certificates | Subject, issuer, serial, notValidBefore and notValidAfter, signature algorithm, key reference, state | Expiry outages, weak signatures and orphaned certificates |
| Protocols | Protocol and version (TLS 1.2, TLS 1.3, SSH, IPsec), cipher suites, endpoints | Downgrade exposure and which channels need hybrid key exchange first |
| Libraries and modules | Library name and version (OpenSSL, BouncyCastle, Go crypto, OS providers), FIPS 140-3 certificate where relevant | One library upgrade can fix hundreds of services; one unpatched copy can undo it |
| Data context | Data protected, its required confidentiality lifetime, business owner | Long-lived data is exposed to harvest-now, decrypt-later collection and must be prioritised |
The data context row is the one most teams skip. The NCSC migration timeline asks organisations to record the data they hold, its expected lifetime and its value to an adversary, and NCCoE prioritises migration using Mosca's theorem, which compares data shelf life plus migration time with the time until a cryptographically relevant quantum computer. Without data context, every RSA key looks equally urgent.
Scoping the estate
The NCSC guidance is explicit that the discovery exercise is not intended to be a formal asset register: the aim is to understand each system's nature, scale, versions and dependencies, combining top-down (services and data) and bottom-up (hosts, code, traffic) analysis. A practical scope covers:
- Applications and services: in-house code, commercial software, SaaS integrations and APIs, including the token signing keys behind authentication services.
- Infrastructure: servers, load balancers, VPN concentrators, network devices, storage arrays and their management interfaces.
- Cloud: KMS keys, managed certificates, service-to-service TLS, storage encryption settings and workload identity federation trust.
- PKI: every internal and public certificate authority, including Active Directory Certificate Services. See the AD CS Security Guide.
- Edge and long-life devices: NCSC lists IoT and ICS devices, end-user tokens and field sensors; these are often the hardest to upgrade, so find them early.
- Developer and pipeline assets: code signing keys, SSH deploy keys, artefact signing and package registry credentials. See the SSH Key Management Guide.
For a large organisation, start with one business service end to end (its code, hosts, network paths, certificates and keys) rather than one technique across the whole estate. The pilot shows which data sources are missing before the programme commits to tools.
Discovery techniques compared
SP 1800-38B (preliminary draft, December 2023) exercised contributed tools in four categories and noted that each platform reports in its own format, so results must be normalised. The table below summarises what each angle finds.
| Technique | Finds well | Misses | Typical output |
|---|---|---|---|
| Source code and CI/CD analysis | Algorithm calls, hard-coded parameters, library dependencies, weak modes; can run on every pull request | Third-party binaries, runtime configuration, keys created at deploy time | SARIF findings, CBOM per build |
| Endpoint and host scanning | Keystores, certificate files, PKCS#8 and OpenSSH keys, installed crypto libraries and versions | What is actually negotiated on the wire; password-protected private keys reduce fidelity | File and library inventory per host |
| Binary analysis | Algorithms inside commercial or legacy software with no source | Configuration-driven choices, protocol negotiation | Per-binary algorithm list |
| Network traffic analysis (active, passive, packet capture) | Negotiated TLS, SSH and IPsec versions, cipher suites, certificates presented, unknown endpoints | Data at rest, internal library use, encrypted traffic it cannot see the handshake of | Endpoint records: IP, port, hostname, ALPN, CPE 2.3 |
| Platform and API queries | Cloud KMS keys, managed certificates, CA issuance logs, HSM partitions, secrets manager metadata | Anything held outside managed services | Key and certificate inventory with owners and dates |
The fifth row is not one of the NCCoE categories but is usually the cheapest source: CA databases, certificate transparency logs for public names, cloud KMS listings and secrets manager metadata already hold dates and owners. Two cautions from the draft apply everywhere: port numbers are ambiguous because TLS protects many protocols on many ports, and future quantum weaknesses fit the CWE weakness model poorly, so a finding on a quantum-vulnerable algorithm is a planning signal, not a vulnerability to patch today.
Modelling the inventory in CycloneDX CBOM
CycloneDX added CBOM support in version 1.6 (the specification is also published by Ecma as ECMA-424). A cryptographic asset is a component of type cryptographic-asset with a cryptoProperties object whose assetType is one of four values.
| assetType | Key properties (field names from the CycloneDX guide) | Example use |
|---|---|---|
algorithm | primitive (for example signature, kem, key-agree, ae), parameterSetIdentifier, mode, padding, cryptoFunctions, classicalSecurityLevel, nistQuantumSecurityLevel, executionEnvironment, certificationLevel | RSA-2048 signature with quantum level 0; ML-KEM-768 with its NIST level |
certificate | subjectName, issuerName, serialNumber, notValidBefore, notValidAfter, fingerprint, certificateState, relatedCryptographicAssets | Public TLS certificate on an API gateway |
related-crypto-material | type (private-key, public-key, secret-key, token, credential and others), size, algorithmRef, state, securedBy, expirationDate | JWT signing key held in a KMS, with state and expiry |
protocol | type (for example tls), version, cipherSuites (each with algorithm references and identifiers) | TLS 1.3 listener and its suites |
The value of CBOM over a spreadsheet is the dependencies section. dependsOn records that a service uses a library, which uses an algorithm, with a key and a certificate. provides records that a library implements an algorithm. The CycloneDX guide warns that an implementation being present does not mean it is in use, so do not count every algorithm a library provides as exposure. Key and certificate states (pre-activation, active, suspended, deactivated, compromised or revoked, destroyed) follow the lifecycle language of NIST SP 800-57, which makes CBOM data easy to reconcile with key management records.
- Generate per build: produce a CBOM alongside the SBOM for each release so new code arrives already inventoried.
- Request from suppliers: add CBOM or equivalent cryptographic disclosure to procurement for software and devices, alongside SBOM requests.
- Aggregate centrally: merge build CBOMs, host scans and network observations into one store keyed by service, using bom-ref identifiers and CPE strings to de-duplicate.
Where identity fits: keys and certificates as non-human identities
Every private key that signs a token, terminates TLS or authenticates over SSH is a credential for a non-human identity. Treating the inventory as an identity inventory changes what is recorded and who acts on it.
- Owner: every key and certificate needs a named service owner, not just a team mailbox, so rotation and revocation have someone accountable.
- Privilege: record what the key can do. A token signing key that every relying service trusts is equivalent to a domain-wide administrator credential.
- Lifetime: record creation and planned retirement dates and alert when a key outlives them. See the Cryptographic Key Management Guide.
- Offboarding: link keys to the people who could export them, so leaver processes trigger rotation.
- Certificates: issuance, renewal and revocation belong to certificate lifecycle management. See the Machine Identity, PKI and Certificate Lifecycle Guide.
Attackers target the same assets: MITRE ATT&CK lists T1552.004 Private Keys, T1649 Steal or Forge Authentication Certificates, T1606 Forge Web Credentials and T1600 Weaken Encryption. An inventory that knows where every signing key lives is also the list of places to watch for these techniques.
Prioritising what the inventory finds
NIST IR 8547 (initial public draft, November 2024) proposes that quantum-vulnerable public-key algorithms at 112-bit security (for example RSA-2048, ECDSA and finite-field or elliptic-curve Diffie-Hellman) are deprecated after 2030 and that all quantum-vulnerable signature and key establishment schemes are disallowed after 2035. Their replacements are FIPS 203 (ML-KEM), FIPS 204 (ML-DSA) and FIPS 205 (SLH-DSA). Combine those dates with what the inventory says about each asset.
| Finding | Priority | Typical action |
|---|---|---|
| Broken or legacy algorithm in use (SHA-1 signatures, RSA-1024, 3DES, RC4, TLS 1.0 or 1.1) | Immediate | Remediate now; this is a present-day weakness, not a quantum one |
| Signing key with no owner, no expiry or past its retirement date | Immediate | Assign owner, move into HSM or KMS, rotate |
| Key exchange protecting data that must stay confidential beyond about 2035 | High | Plan hybrid or ML-KEM key establishment first; harvest-now, decrypt-later applies |
| Long-lived trust anchors (root CAs, firmware and code signing roots, device identities) | High | Plan early because replacement cycles are long. See the Q-Day Planning Guide |
| Quantum-vulnerable signatures on short-lived certificates and tokens | Medium | Migrate with platform upgrades; ensure algorithms are configurable |
| Hard-coded algorithm choices in code | Medium | Refactor to configuration-driven selection. See the Crypto-Agility Guide |
Smaller organisations, which mostly consume cryptography through vendors and cloud services, can weight the inventory towards supplier questions and platform queries rather than running all four discovery techniques. Organisations that build software or operate their own PKI need the full pipeline and host coverage.
How to implement
- Set the purpose and owner: agree that the inventory serves weak-crypto remediation, key incident response and post-quantum planning, and give one team ownership of the data model (usually the PKI or cryptography team with security architecture).
- Harvest managed sources first: export CA issuance records, cloud KMS and HSM key listings, secrets manager metadata and certificate transparency results. These give dates and owners at low cost.
- Pilot one service end to end: run code, host, binary and network discovery on one business service, compare results and record what each technique missed.
- Choose the data model: adopt CycloneDX CBOM as the exchange format, decide mandatory fields (owner, location, expiry, data lifetime) and map each tool's output to it.
- Roll out in rings: start passive network sensors and platform queries estate-wide (low risk), then host agents in pilot rings, then CI/CD scanning in report-only mode before any build gating.
- Test and roll back safely: run host scanners in read-only mode, rate-limit active network scanning against fragile OT and legacy devices, and keep any pipeline gate in warn mode until false positives are understood; removing a gate or agent should not affect production.
- Close the loop: raise tickets to owners for immediate findings, feed prioritised data into the migration roadmap, and require a CBOM for new systems at design review and procurement.
- Re-scan and reconcile: schedule recurring scans and reconcile against the previous inventory so new keys, expired certificates and removed services are visible.
Detection and measurement
Monitor the assets the inventory exposes: alert on certificates presented on the network that are not in the inventory, keys used after their recorded retirement date, new uses of deprecated algorithms or protocol versions, and export or backup operations on high-value signing keys in HSM and KMS audit logs. Useful metrics:
- Coverage: percentage of business services with a current CBOM (updated within the last scan cycle).
- Ownership: percentage of keys and certificates with a named owner and recorded expiry.
- Unknowns: number of certificates or endpoints seen on the network but absent from the inventory, trending down.
- Legacy cryptography: count of services still using SHA-1 signatures, RSA below 2048 bits or TLS below 1.2.
- Quantum exposure: share of long-confidentiality data flows protected by quantum-vulnerable key exchange.
- Hardware protection: percentage of signing keys held in an HSM or managed KMS rather than files.
Framework mapping
| Framework | Reference | Relevance to cryptographic inventory |
|---|---|---|
| NIST CSF 2.0 | ID.AM-02, ID.AM-07, ID.AM-08, ID.RA-01, PR.DS-01, PR.DS-02 | Inventories of software and data, lifecycle management, recording weaknesses, protection of data at rest and in transit |
| NIST SP 800-53 Rev. 5 | CM-8, SC-12, SC-12(3), SC-13, SC-17, SA-4 | Component inventory, key establishment and management, asymmetric keys, cryptographic protection, PKI certificates, acquisition requirements for suppliers |
| CIS Controls v8.1 | Controls 1 and 2 (asset and software inventory), Safeguards 3.10 and 3.11 (encrypt data in transit and at rest) | Inventory foundations and the encryption the inventory verifies |
| ISO/IEC 27001:2022 Annex A | 5.9 Inventory of information and other associated assets; 8.24 Use of cryptography | Asset inventory and cryptographic key management rules |
| MITRE ATT&CK | T1552.004, T1649, T1606, T1600 | Techniques that target the keys, certificates and algorithms being inventoried |
Common failure patterns
- Treating the inventory as a one-off spreadsheet: it is out of date within a release cycle. Generate CBOMs in pipelines and reconcile scans on a schedule.
- Inventorying algorithms but not keys: knowing that a service uses RSA says nothing about where its private key lives or whether it should still be valid. In the Microsoft Storm-0558 key breach, a 2016 consumer signing key that should have been retired in 2021 stayed valid because manual rotation had stopped and nothing alerted on its age.
- No owner or offboarding link: in the Coupang signing key breach, a token signing key kept on developer machines was not rotated when the engineer who held it left, and was later used to forge tokens.
- Relying on one discovery technique: network-only discovery misses data at rest and internal library use; code-only discovery misses commercial software and runtime configuration.
- Counting provided algorithms as used: a library that implements dozens of algorithms inflates the findings; use
dependsOnevidence of actual use. - Ignoring long-life devices and suppliers: firmware, OT controllers and vendor appliances are slowest to change and are often left out of the first scan.
Practitioner checklist
- Name an owner for the cryptographic inventory and its data model.
- Export keys and certificates from every CA, HSM, cloud KMS and secrets manager, with owners and expiry dates.
- Pilot code, host, binary and network discovery on one business service and record the gaps.
- Adopt CycloneDX CBOM (1.6 or later) as the exchange format and define mandatory fields.
- Generate a CBOM for every release and request cryptographic disclosure from suppliers.
- Record data confidentiality lifetime per service to drive post-quantum prioritisation.
- Fix broken algorithms and ownerless or overdue signing keys immediately.
- Alert on unknown certificates, keys used past retirement and deprecated protocol use.
- Report coverage, ownership and legacy-crypto metrics each quarter.
Standards and references
- NIST NCCoE: SP 1800-38 Migration to Post-Quantum Cryptography (Volumes A, B and C preliminary drafts)
- NIST NCCoE: SP 1800-38B Quantum Readiness: Cryptographic Discovery
- OWASP CycloneDX: Cryptography Bill of Materials (CBOM)
- OWASP CycloneDX: Authoritative Guide to CBOM
- CISA: Strategy for Migrating to Automated Post-Quantum Cryptography Discovery and Inventory Tools
- NIST: IR 8547 Transition to Post-Quantum Cryptography Standards
- NCSC: Timelines for migration to post-quantum cryptography
- NIST: SP 800-57 Part 1 Rev. 5 Recommendation for Key Management
Related NHI Mgmt Group resources: Post-Quantum Cryptography Migration Guide · Crypto-Agility Guide · Cryptographic Key Management Guide · Machine Identity, PKI and Certificate Lifecycle Guide · Secrets Management Guide