PQC
Why organizations need a cryptographic bill of materials for PQC migration
Before an organization can build a migration roadmap, it needs to know where its cryptography is, what algorithms are in use, and which dependencies are quantum-vulnerable.
Most organizations cannot answer these questions today. Cryptography is embedded in TLS configurations, application code, database encryption, certificate chains, VPN tunnels, and dozens of other systems. It is rarely inventoried as a first-class asset.
CycloneDX addresses this with its Cryptography Bill of Materials (CBOM) capability.
What is a CBOM?
A Cryptographic Bill of Materials is a structured, machine-readable inventory of cryptographic assets within a system or organization. Built on the CycloneDX standard (the same framework used for Software Bills of Materials), a CBOM goes beyond what an SBOM, CMDB, or certificate inventory captures by representing algorithms, parameters, key lifecycle metadata, and the relationships between them. A CBOM catalogs:
- Algorithms and parameters (RSA-2048, AES-256-GCM, ECDSA P-256, SHA-256, etc.)
- Certificates with chains, expiration dates, and signing algorithms
- Keys with lifecycle metadata: generation, storage, rotation, and destruction
- Protocols and versions (TLS 1.2, TLS 1.3, IKEv2, SSH)
- Libraries and versions providing cryptographic functionality
The output is a structured document (JSON or XML) that can be parsed, queried, and tracked over time. The CycloneDX schema supports querying by algorithm family or quantum-vulnerability status, which makes gap analysis scriptable rather than manual.
Why CBOMs matter for post-quantum migration
The NCSC's migration timelines set clear milestones: organizations should identify cryptographic services needing upgrades and build migration plans by 2028, execute high-priority upgrades by 2031, and complete full migration by 2035. A CBOM can serve as a durable, auditable artifact of that discovery work.
Harvest-now, decrypt-later is an active threat model
Adversaries may already be capturing data encrypted with quantum-vulnerable algorithms, planning to decrypt it once quantum computers are available. NCSC and NIST both treat this as a current planning risk, and U.S. national security guidance (including CNSA 2.0) reflects the same urgency. The sensitivity and retention period of your data determine how urgent your inventory needs to be.
You cannot prioritize without visibility
Not all cryptographic dependencies carry equal risk. A quantum-vulnerable key exchange in a public-facing TLS endpoint is more urgent than the same algorithm used in an internal test environment. A CBOM lets you prioritize based on exposure level and system sensitivity rather than manual memory or ad-hoc discovery.
Governance and audit trail
NCSC migration guidance and NIST IR 8547 (currently in draft) both treat discovery and inventory as foundational to transition planning. A CBOM provides an auditable record of what is in use, what is quantum-vulnerable, and how migration is being prioritized.
What goes in a CBOM
A useful CBOM captures four categories of information for each cryptographic dependency:
Identity: What algorithm, protocol, or library is in use? What version? What parameters (key length, curve, mode)?
Location: Where in the architecture does this dependency live? Which systems, services, or applications use it?
Risk profile: Is this algorithm quantum-vulnerable? What is the migration complexity? What is the business impact if this dependency is compromised?
Lifecycle: When was this deployed? When does it expire? What is the rotation schedule? Who owns it?
A CBOM entry for a TLS endpoint captures fields like these:
| Field | Value |
|---|---|
| Component | api.example.com TLS |
| Algorithm | ECDHE-ECDSA-AES256-GCM-SHA384 (TLS 1.2) |
| Key Exchange | ECDHE (P-256) |
| Signature | ECDSA (P-256) |
| Quantum Vulnerable | Key exchange: Yes. Signature: Yes. Symmetric: No. |
| Migration Priority | High (public-facing, sensitive data) |
From inventory to roadmap
A complete CBOM is the input to migration roadmap planning. Once you have the inventory, you can:
- Score risk for each dependency based on quantum vulnerability, exposure, and business impact
- Identify quick wins where migration is straightforward (e.g., updating a TLS configuration)
- Flag complex migrations that require architecture changes or vendor coordination
- Build a sequenced roadmap that prioritizes high-risk, high-exposure dependencies first
- Track progress as you migrate, updating the CBOM to reflect the current state
A structured post-quantum readiness assessment follows this same sequence: inventory first, risk scoring second, migration roadmap third.
Getting started
Start with a scoped pilot: pick one service boundary (a public API, a VPN gateway, or a certificate authority) and apply the CBOM schema there. A partial inventory scoped to your highest-exposure systems is more useful than waiting for a complete one.
The CycloneDX CBOM specification is open and well-documented. The PQC resources page collects relevant standards, tools, and libraries. See also the PQC Timeline for the full standardization history.