Cryptography Bill of Materials (CBOM)

● standardA Cryptography Bill of Materials (CBOM) is a machine-readable inventory of every cryptographic asset — algorithms, keys, certificates, protocols and their configurations — and how they relate to software components. It extends the SBOM: the SBOM lists your software, the CBOM lists the cryptography inside it.

In the migration lifecycle it is Phase 2: discovery (Phase 1) feeds the CBOM, and risk scoring (Phase 3) consumes it. A bare list of algorithms isn't enough — the value is a CBOM you can query and rank.

◆ practitionerStart with a Minimum Viable CBOM: capture the fields you need to prioritise (algorithm, where it's used, what it protects, owner), not a perfect catalogue. Regulators are converging on the same expectation: the EU's NIS Cooperation Group roadmap (v1.1, 11 Jun 2025) sets an end-2026 milestone for Member States whose first steps include mature cryptographic asset management, saying they “should promote and support that useful cryptographic inventories are being created and maintained” and naming CBOM as a recommended format. It is guidance to Member States rather than a direct obligation on you — but it is what national rules will be built from.

● standardTwo BOM standards compete, with different stewards: CycloneDX (OWASP; standardized as ECMA-424, current spec v1.7) and SPDX (Linux Foundation; ISO/IEC 5962; v3.0.1).

The decider for a CBOM: SPDX 3.0.1 has no dedicated cryptography object model yet, so CycloneDX is the practical choice today. CycloneDX 1.7 adds a Cryptography Registry (consistent algorithm-family and curve naming) built for PQC-readiness reviews.

● standardThe PKI Consortium CBOM-Profiles Working Group (launched 8 Jun 2026) is building a neutral methodology so a CBOM profile maps onto both formats — the format-neutral future.

◆ practitioner“Ghost” crypto is every cryptographic use that isn't in any inventory — shadow-IT services, forgotten-but-live certs, hardcoded algorithms, embedded/OT crypto, default library crypto. A CBOM built only from known systems is falsely reassuring. You can't migrate what you can't find.

◆ practitionerReuse before you deploy. A new agent rollout is usually the real blocker. Pull from tools you already run as discovery sources — Qualys / Tenable / Rapid7 and on-host agents (which surface TLS endpoints, ciphers and certs), Venafi / Keyfactor / DigiCert for certificates — and scan net-new only where you are blind.

● standardNo single method finds it all — layer five: source code (sonar-cryptography / CBOMkit, IBM Quantum Safe Explorer), binary / container (CBOMkit-theia), network / traffic (passive handshake capture + active scanning), infrastructure / runtime (HSM/KMS, CLM, CT logs), and cloud (KMS/cert APIs + CSPM — no host to scan, provider-managed crypto, shared responsibility). Coverage = the union.

◆ practitionerFramework v2.1 Activity 1.3 defines 13 mandatory fields per cryptographic instance. Recording them consistently is what turns a raw discovery export into a queryable, risk-rankable backlog that Phase 3 can score and Phase 4 can sequence.

Minimum Viable CBOM shortcut: if full capture is too slow, start with Algorithm + Key Size + Owner + Control Posture. Those four fields alone let you produce a prioritized remediation queue and unblock Phase 3 scoring for your highest-risk systems.

◆ practitionerDiscovery finds artifacts; risk needs context. Attach to each key what it protects (+ confidentiality horizon = the HNDL input), its purpose (Track A vs B), location, owner, vendor-dependency, and active-vs-dormant. That enrichment turns an inventory into a risk-rankable backlog.

● standardTwo kinds of identifier. Assigned ids are local and don't correlate (PKCS#11 CKA_ID, KMIP Unique Identifier, KMS key-id, JWK kid). Content-derived ids do: the X.509 SKI / SPKI hash, KMIP Digest, JWK Thumbprint (RFC 7638), KCV for symmetric keys. Correlate “same key across HSM / cert / code / wire” on the SPKI fingerprint.

● standardAttestation proves a key's origin (generated in hardware, non-exportable) — HSM/TPM attestation, Android Key Attestation, FIDO2/WebAuthn; for PQC, attest generation in a FIPS 140-3-validated module. And record where the key is managed — software (exportable, sprawl-prone), HSM (non-exportable, attestable), or cloud KMS (API-mediated, envelope encryption) — it drives risk and migration feasibility.

◆ practitionerOne mechanism has many names. ECDSA-P256-SHA256 is CKM_ECDSA_SHA256 to an HSM, OID 1.2.840.10045.4.3.2 to a certificate, ES256 to a JWT, and 0x0403 to TLS 1.3 — and the curve alone is P-256 = secp256r1 = prime256v1. Six codification layers (spec, OID, protocol code point, key-mgmt enum, library string, CBOM) with no shared key.

● standardPQC makes it worse. Each parameter set is its own algorithm: ML-DSA chose one OID per parameter set, parameters absent (id-ml-dsa-44/65/87, RFC 9881), so OIDs proliferate. Hybrid KEMs (X25519MLKEM768) and composite signatures each get their own identifier — combination × nomenclature.

● standardThe answer is to map every source onto a canonical model (the CycloneDX Cryptography Registry) while never over-collapsing security-relevant parameters (mode, padding, curve, hash). The PKIC CBOM-Profiles WG is the neutral venue maintaining this as registries keep moving.

For the full family/curve reference and a hands-on normalizer, see the dedicated CycloneDX Cryptography Registry module.

● standardMachine-verifiable in practice = policy-as-code. CBOMkit runs an OPA/Rego check classifying each asset quantum-safe / quantum-vulnerable / na / unknown, queryable over a REST API. Normalized names (above) are what make the rules match reliably.

◆ practitionerSecure the CBOM. The CBOM plus the risk backlog is a map of your weakest cryptography — an attacker's shopping list. Protect it with access control and integrity, the way you would any sensitive asset inventory.