Post-Quantum Cryptography Migration Starts With an Inventory
Post-quantum cryptography migration fails without a cryptographic inventory. How to build a CBOM, prioritize by data lifetime, and test hybrid ML-KEM safely.
Most organizations cannot answer a simple question: where does our RSA and elliptic-curve cryptography actually live? Post-quantum migration depends on that answer. You cannot replace cryptography you cannot see, and the parts you cannot see are usually the ones that break during rollout.
Why harvest now, decrypt later makes PQC migration urgent now
A cryptographically relevant quantum computer does not exist yet. That is not the relevant clock. An adversary can record encrypted traffic today and decrypt it once the capability arrives. This is the harvest now, decrypt later (HNDL) threat, and it means the exposure window for confidential data started when that data first crossed a network under RSA or ECDH key exchange.
A useful way to reason about it is Mosca’s inequality: if the number of years your data must stay confidential, plus the number of years your migration will take, exceeds the time until a quantum attack is practical, you are already late. Health records, trade secrets, legal material, long-term contracts, and identity data routinely have confidentiality lifetimes measured in decades. Large enterprise migrations have historically taken years.
The standards are no longer the bottleneck. NIST finalized FIPS 203 (ML-KEM), FIPS 204 (ML-DSA), and FIPS 205 (SLH-DSA) in August 2024, and the draft NIST IR 8547 proposes deprecating RSA and ECC after 2030 and disallowing them after 2035. The bottleneck is knowing what you have.
Why you can’t migrate what you can’t see
Cryptography is rarely where people expect it. A realistic cryptographic inventory has to look across several layers at once:
- Source code: direct calls to crypto APIs, hard-coded algorithm names, custom wrappers, and key sizes buried in constants.
- Libraries and dependencies: OpenSSL, BoringSSL, Bouncy Castle, language runtimes, and transitive dependencies that pull in their own crypto.
- Certificates and PKI: leaf, intermediate, and root certificates, code-signing keys, and internal CAs with long validity periods.
- Protocols: TLS versions and cipher suites, SSH, IPsec and VPN tunnels, S/MIME, and application-specific handshakes.
- Configuration: web server, load balancer, service mesh, and database settings that select algorithms at runtime.
- Hardware: HSMs, smart cards, TPMs, and embedded devices whose firmware fixes the algorithms they support.
- Vendor products: SaaS platforms, appliances, and commercial software where you depend on a supplier’s roadmap.
No single scanner sees all of this. Static analysis finds algorithm usage in code but not what is negotiated on the wire. Network observation sees negotiated suites but not the dormant fallback path in a library. Certificate discovery sees keys but not which business functions rely on them. A usable inventory correlates these sources instead of treating each as a separate spreadsheet.
Building a cryptographic inventory and a CycloneDX CBOM
A cryptographic bill of materials (CBOM) is the machine-readable form of that inventory. CycloneDX 1.6 added first-class support for cryptographic assets, so a CBOM can describe algorithms, certificates, keys, and protocols using the same format many teams already use for software bills of materials. A minimal entry for a quantum-vulnerable signature algorithm looks like this:
{
"type": "cryptographic-asset",
"bom-ref": "crypto/algorithm/rsa-2048",
"name": "RSA-2048",
"cryptoProperties": {
"assetType": "algorithm",
"algorithmProperties": {
"primitive": "signature",
"parameterSetIdentifier": "2048",
"cryptoFunctions": ["sign", "verify"],
"nistQuantumSecurityLevel": 0
}
}
}The format is the easy part. The value comes from three properties of the underlying data:
- Evidence: every entry should point to where it was found, such as a file path, certificate serial number, or observed handshake. Unanchored findings do not survive review.
- Relationships: an algorithm entry matters because of what depends on it. Link cryptographic assets to the libraries, services, and business functions that use them.
- Freshness: an inventory taken once decays. Regenerate it as part of your build and change processes.
Prioritizing post-quantum migration by data lifetime and mission impact
Sorting by algorithm tells you very little. Every RSA-2048 instance looks identical on an algorithm report, but an RSA key protecting a public marketing site and one protecting a long-lived archive of customer financial records are not the same risk.
Prioritize on at least three axes:
- Data lifetime: how long must the data protected by this key exchange remain confidential? Long-lived data is exposed to HNDL today.
- Business or mission impact: what fails, and who is affected, if this system is compromised or goes down during migration?
- Migration difficulty: is the fix a configuration change, a library upgrade, a hardware refresh, or a vendor dependency you do not control?
Key establishment protecting long-lived confidential data usually goes first, because that is where HNDL applies. Signatures matter too, but a forged signature requires a quantum attack at the time of use, so signature migration can often follow key establishment. Long-lived signing roots (firmware, code signing, root CAs) are the exception and need early planning.
Hybrid key exchange: X25519 + ML-KEM-768 as a transition step
Hybrid key exchange combines a classical algorithm with a post-quantum one, so the session stays secure as long as either holds. The combination of X25519 and ML-KEM-768 has become the common default in modern TLS 1.3 stacks and major browsers. It protects against HNDL now while hedging against implementation flaws in newer post-quantum code.
Hybrid is a transition step, not an end state. It requires TLS 1.3, so any system still pinned to TLS 1.2 has a prerequisite upgrade first. Be aware too that different regimes specify different parameter sets. The NSA’s CNSA 2.0 suite specifies ML-KEM-1024 for national security systems, so suppliers serving those customers should not assume the commercial default is sufficient.
What breaks during ML-KEM and ML-DSA migration
Post-quantum algorithms are not drop-in replacements at the byte level. ML-KEM computation is fast; the problems are mostly about size and compatibility.
| Area | What changes | What to check |
|---|---|---|
| Handshake size | ML-KEM-768 adds roughly 1 KB to the ClientHello and a similar amount to the server response | Clients and servers with fixed-size buffers |
| MTU and fragmentation | The ClientHello can exceed a single packet | Middleboxes, firewalls, and load balancers that assume a one-packet ClientHello |
| Middleboxes | Inspection devices may drop unfamiliar key share groups | TLS-inspecting proxies, IDS/IPS, legacy appliances |
| HSMs and firmware | Many devices need firmware or hardware updates for PQC algorithms | Vendor roadmaps and validated module status |
| Certificate chains | ML-DSA public keys and signatures are kilobytes, not bytes | Chain size, handshake round trips, constrained clients |
| Performance | CPU cost is modest; bandwidth and latency effects are more visible | High-volume endpoints, constrained or high-latency links |
Certificate chains deserve particular attention. An ML-DSA chain can be an order of magnitude larger than an ECDSA chain. On constrained devices and high-latency links, that can add round trips or exceed what embedded TLS stacks will accept.
Testing post-quantum migrations before rollout
Treat every migration step as a change with predictable failure modes. A practical sequence:
- Map the path: for each target service, identify every client, proxy, load balancer, and inspection device on the connection path.
- Forward-simulate: before changing anything, check each component against the new algorithm’s requirements (TLS 1.3, larger handshakes, new key share groups, firmware support).
- Validate behaviorally: run the candidate suite in a test environment with real clients, and confirm that handshakes complete, that fallback behaves as intended, and that no path silently downgrades.
- Roll out incrementally: enable hybrid key exchange on a subset of traffic, monitor handshake failures, and expand.
- Record evidence: update the CBOM with what changed and how it was verified.
Crypto agility: designing for the next migration
The RSA-to-PQC transition will not be the last algorithm change. Crypto agility means algorithms are selected by configuration and policy rather than hard-coded, libraries are centralized rather than duplicated, and the inventory stays current enough to answer “where is this algorithm used?” in hours rather than months. Organizations that build their inventory well for this migration will find the next one far cheaper.
How QuantumWorks approaches cryptographic inventory and PQC migration
Sentinel is our approach to this problem within cyber assurance. It assembles evidence from code, network protocols, infrastructure, and policy into a Crypto Asset Graph that connects cryptographic assets to the systems and functions that depend on them, scores risk by mission impact and HNDL exposure, and predicts which migration steps are likely to fail before anything changes. Candidate suites such as hybrid X25519 + ML-KEM-768 are validated in a liboqs-based harness, and findings are exported as a CycloneDX 1.6 CBOM anchored to their evidence.