Cryptography Bill of Materials Guide and Template
A Cryptography Bill of Materials, or CBOM, records where cryptography exists inside software and systems. For post-quantum migration, it helps teams trace an application to the libraries, protocols, certificates, keys, services, and hardware that implement or depend on its cryptographic functions.
The useful word is trace. A spreadsheet that says only “payments uses RSA” cannot identify which service terminates TLS, which library negotiates it, which certificate authority issues the certificate, or whether a vendor controls the upgrade. A useful CBOM connects those components and preserves evidence.
Download the editable CBOM CSV template. It is a practical working file, not a certification artifact and not a complete implementation of the CycloneDX specification.
If you need to discover cryptography across an organization first, use the Cryptographic Inventory Guide. If you already have inventory rows and need to assign migration work, use the PQC Migration Plan Template.
CBOM versus a cryptographic inventory
The terms overlap, but they answer different operational questions.
| Artifact | Primary question | Useful scope |
|---|---|---|
| Cryptographic inventory | Where is cryptography used across the organization? | Systems, services, data flows, devices, vendors |
| CBOM | Which components provide or depend on cryptography in this product or application? | Component identity, crypto asset, dependency relationship, evidence |
| Migration plan | Who will replace which capability, how, and by when? | Ownership, target state, testing, rollout, rollback |
NIST’s NCCoE migration project emphasizes cryptographic discovery and comprehensive inventory as the basis for prioritization. Its current FAQ points readers to the CycloneDX Authoritative Guide to CBOM. CycloneDX defines machine-readable cryptographic asset types and dependency relationships. This template uses compatible concepts but remains deliberately flat so a team can start in a spreadsheet.
What belongs in a CBOM
A CBOM should identify both cryptographic assets and the components that use them.
Algorithms and primitives: RSA, ECDH, ECDSA, AES-GCM, SHA-256, ML-KEM, ML-DSA, and their exact parameters.
Certificates and keys: certificate subject, issuer, validity, signature algorithm, public-key algorithm, key identifier, lifecycle owner, storage location, and rotation process. Never put private key material in the CBOM.
Protocols: TLS, SSH, IPsec, S/MIME, code-signing formats, proprietary device protocols, and the negotiated suites or algorithms that matter.
Libraries and providers: OpenSSL, BoringSSL, Bouncy Castle, platform cryptographic APIs, language runtimes, firmware libraries, and versions.
Services and hardware: managed KMS, HSM, TPM, secure element, certificate authority, secrets service, load balancer, CDN, and external signing service.
Dependencies: which application calls the library, which service terminates a protocol, which certificate relies on a CA, and which vendor controls an upgrade.
Template fields
| Field | What to enter | Why it matters |
|---|---|---|
| Record ID | Stable unique identifier | Keeps references intact across exports |
| Application and environment | Product, service, production or test | Prevents lab capability being read as production support |
| Component name, type, version | Exact software, service, protocol, certificate, key store, or device | Defines the object being assessed |
| Supplier | Project, vendor, or internal owner | Locates external control |
| Cryptographic asset type | Algorithm, certificate, protocol, key, library, hardware, service | Supports filtering and exchange |
| Algorithm and parameters | Exact primitive, key size, curve, mode, or parameter set | Avoids generic labels such as “PQC” |
| Cryptographic function | Key establishment, signature, encryption, authentication, hashing, wrapping | Separates capabilities that migrate differently |
| Dependency and relationship | Record ID plus depends-on, provides, calls, terminates, signs, stores | Creates the traceable graph |
| Key or certificate location | KMS, HSM, file, device, keystore, CA | Identifies operational constraints |
| Exposure and data lifetime | Network reachability and confidentiality period | Supports risk prioritization |
| PQC relevance | Quantum-vulnerable, PQC, symmetric, hash, unknown | Establishes triage without claiming safety |
| Agility and replacement control | Configurable, code change, firmware, vendor controlled, unknown | Shows migration friction |
| Evidence | Scanner output, config, documentation, test, ticket | Makes the row auditable |
| Owner and last verified | Accountable team and review date | Prevents stale orphan records |
Use one row per cryptographic asset or dependency relationship when possible. A web service that uses TLS key establishment, certificate signatures, JWT signatures, and database encryption should not be compressed into one “uses cryptography” row.
How to use the downloadable template
1. Choose a bounded application
Start with one service and one environment. Record its externally visible protocols, repositories, images, libraries, certificates, key stores, cloud services, build pipeline, and upstream or downstream dependencies. A portfolio-wide blank sheet is harder to validate than one complete application graph.
2. Import automated findings
Static analysis, dependency analysis, TLS or SSH scanning, certificate discovery, runtime observation, cloud configuration, and code search all provide partial evidence. Preserve the tool, version, scan time, and artifact location. A scanner finding is evidence that deserves review, not proof that the code path is active in production.
The NCCoE FAQ currently lists examples including CodeQL, pqcscan, sslscan, certificate transparency search, and collaborator tools. The list is not an endorsement or a guarantee of complete coverage.
3. Normalize names without losing raw evidence
Normalize rsaEncryption, RSA 2048, and a library-specific identifier into a consistent algorithm field, but keep the raw scanner result in evidence or notes. Record exact variants such as ML-KEM-768 or ML-DSA-65. “Quantum safe” is not an algorithm name.
4. Add relationships
The dependency fields are what distinguish a CBOM from a loose asset list. Link an application to the TLS library it calls, the endpoint that terminates its connection, the certificate presented, the CA that signs it, and the HSM or KMS that stores the key.
If a CSV becomes difficult to maintain, move to CycloneDX JSON or XML and use the specification’s native components, cryptographic assets, and dependency graph. Do not claim a spreadsheet is CycloneDX-compliant without validating a generated CycloneDX document against the official schema.
5. Review unknowns
Unknown fields are useful. They reveal where evidence is missing. Assign an owner and follow-up date instead of guessing. Vendor-controlled dependencies should point to the PQC Vendor Questionnaire and vendor support matrix.
PQC prioritization without a fake score
Do not calculate a universal readiness score from CBOM row counts. Ten internal test certificates do not necessarily outweigh one internet-facing connection protecting long-lived sensitive data.
Prioritize records using:
- quantum-vulnerable public-key function;
- required confidentiality or signature-verification lifetime;
- exposure and capture opportunity;
- number of dependent systems;
- inability to change the algorithm;
- vendor or hardware replacement lead time;
- operational consequence of failure;
- available standardized replacement and protocol support.
FIPS 203, 204, and 205 standardize ML-KEM, ML-DSA, and SLH-DSA. That does not mean every protocol, product, HSM, client, or certificate workflow supports them. Track standards status separately from implementation availability.
Quality controls
A usable CBOM process has explicit checks:
- Every production application has an owner.
- Every row identifies its evidence and verification date.
- Private keys and secrets are excluded.
- Algorithms include parameters, not family names alone.
- Production and test capabilities remain separate.
- Dependency references resolve to another record or an identified external supplier.
- Unknowns have assigned follow-up work.
- Changes in builds, images, certificates, firmware, and cloud configurations trigger review.
Store the CBOM according to its sensitivity. It can reveal software versions, endpoints, certificate relationships, security hardware, and critical dependencies. Access controls and retention should reflect that risk.
From CBOM to migration work
A CBOM establishes evidence and dependency structure. The PQC readiness assessment evaluates whether the organization can act on that evidence. The migration checklist provides program sequencing. The migration plan template converts selected records into owned implementation work with tests and rollback.
Do not mark the CBOM “complete.” Define coverage, such as all production internet endpoints and Tier 1 applications, and report unknowns. Refresh records through build and asset-management workflows rather than relying on an annual spreadsheet exercise.
Practical takeaway
Use the CSV to map one application completely. Capture exact cryptographic functions, component versions, relationships, evidence, and ownership. Then test whether the map can answer: which systems depend on this algorithm, certificate, library, CA, KMS, or vendor? If it cannot, add the missing relationship before scaling collection.
FAQ
Is a CBOM the same as an SBOM?
No. An SBOM inventories software components. A CBOM describes cryptographic assets and their use or dependency relationships. CycloneDX can represent both in a related machine-readable model.
Is the downloadable CSV CycloneDX compliant?
No. It is a flat working template informed by CycloneDX concepts. Use the official CycloneDX schemas and validators when producing a conforming JSON or XML document.
Should keys be included in a CBOM?
Include identifiers, type, algorithm, owner, lifecycle status, and storage location when appropriate. Never include private key material or secret values.
How often should a CBOM be updated?
Update it when software, infrastructure, certificates, keys, firmware, or vendor capabilities change. Automate collection where possible and retain a last-verified date.
Does a complete CBOM make a system quantum safe?
No. It provides visibility. Migration still requires supported algorithms and protocols, interoperability testing, rollout, monitoring, and rollback.