Building a Cryptographic Inventory (CBOM): A Practical Method

You cannot migrate cryptography you cannot see. A Cryptographic Bill of Materials (CBOM) is an inventory of the algorithms, key sizes, certificates, protocols and libraries that your systems actually use. It is the first deliverable in any post-quantum program, and it is useful on its own for finding weak or expired cryptography.

SBOM versus CBOM

A Software Bill of Materials lists the components in an application. A CBOM lists the cryptographic assets: for example "service X terminates TLS 1.2 with ECDHE-RSA-AES128-GCM using a 2048-bit RSA certificate from CA Y, via OpenSSL 1.1.1." The two overlap, since libraries appear in both, but a CBOM adds configuration and usage, which an SBOM does not capture. The CycloneDX specification includes a format for cryptographic assets, which makes the inventory machine-readable.

What to record

For each asset capture enough to decide what to do with it:

• Asset type: certificate, key, algorithm use, protocol, library
• Algorithm and parameters (RSA-2048, ECDSA P-256, AES-256-GCM, SHA-1, and so on)
• Where it is used and what data it protects
• Owner and system
• Library and version providing it
• Expiry or rotation date for certificates and keys
• Quantum-vulnerable? (RSA, ECDSA, EdDSA, DH, ECDH are; AES-256 and SHA-384 are not)

Four discovery methods

No single method is complete, so combine them.

1. Source and dependency scanning. Search code and configuration for crypto API calls and algorithm names: RSA, KeyPairGenerator, createHash('md5'), ECDH, X509. Dependency manifests show which crypto libraries are present. This finds what developers intended, and it also finds hardcoded keys (see Secrets Management).

2. Network scanning. Probe your own endpoints to see what they negotiate. Tools such as nmap --script ssl-enum-ciphers or sslyze report protocol versions, cipher suites and certificate chains for each host and port.

nmap --script ssl-enum-ciphers -p 443 internal-api.example.com

3. Certificate and key stores. Export from your PKI, cloud certificate manager, KMS and HSMs. Certificate transparency logs reveal public certificates issued for your domains, including ones nobody remembers.

4. Runtime and traffic observation. Logs from load balancers and proxies record negotiated TLS versions and groups. This shows what is really used, rather than what is configured.

Cloud and SaaS specifics

Cloud providers expose crypto settings as policy: TLS security policies on load balancers, KMS key specs (RSA versus symmetric), and database encryption options. Query these through the provider's APIs and record them. For SaaS, you usually cannot scan, so record the vendor, what data they hold, and their published PQC roadmap.

Turning the inventory into decisions

Once assets are listed, add two columns and sort: data lifetime and internet exposure. The top of the list is your first migration wave: quantum-vulnerable key exchange protecting long-lived data on externally reachable links. Next come weak legacy items that need fixing regardless of quantum risk: MD5 or SHA-1 usage, RSA-1024, TLS 1.0 or 1.1, expired certificates.

Keep it alive

A one-time spreadsheet goes stale within weeks. Three habits keep it current:

• Generate CBOM data in CI for each repository so new crypto usage shows up on every pull request.
• Re-scan network endpoints on a schedule and diff the results.
• Make "register the cryptography you use" part of your new-service checklist.

Even a partial inventory pays off quickly. Teams routinely find forgotten services, internal endpoints with outdated protocols, and certificates with no owner. Those findings are valuable even before post-quantum migration starts.