Build a CBOM First: Step One of Post-Quantum Readiness

A CBOM, or cryptographic bill of materials, is an inventory of the cryptography your systems use: which algorithms, key sizes, certificates, libraries and protocols, and where each one lives. You can’t migrate to post-quantum cryptography until you know what you’re migrating, so building a CBOM is the first real step of PQC readiness.

Nobody’s breaking RSA this year. But the standards are final, the deadlines are published, and the inventory takes longer than anyone expects. This post covers the threat in plain terms, where NIST has landed, what a CBOM is, how to build one, and the order I’d tackle the rest in.

The quantum threat, in plain terms

Almost all the public key cryptography in use today (RSA, elliptic curve Diffie-Hellman, ECDSA) depends on math problems that are hard for classical computers: factoring large numbers and computing discrete logarithms. A large enough, reliable enough quantum computer running Shor’s algorithm could solve those problems efficiently. That would break the key exchange behind TLS and VPNs, and the signatures behind certificates, code signing and software updates.

Symmetric cryptography like AES and hash functions like SHA-256 are in much better shape. Quantum attacks weaken them, but larger key and output sizes handle that. The problem is public key crypto, which is exactly the part PKI is built on.

Nobody can tell you the date a cryptographically relevant quantum computer will exist. You don’t need that date to act, for two reasons.

Harvest now, decrypt later

An attacker who records encrypted traffic today can store it and decrypt it once the quantum capability exists. If the data still matters then (health records, state secrets, intellectual property, long-lived credentials), it’s already exposed. The question isn’t “when will quantum computers arrive?” It’s “how long does my data need to stay secret, and how long will migration take?” If the sum of those two numbers is longer than the time until a capable quantum computer, you’re already late.

Migration is slow

Every past cryptographic migration, SHA-1 to SHA-2 being the obvious example, took years longer than planned. This one touches more systems, including hardware and embedded devices that can’t be patched quickly.

NIST’s post-quantum standards

NIST ran a public competition for quantum-resistant algorithms starting in 2016. In August 2024 it published the first three final standards:

Standard	Algorithm	Based on	Use
FIPS 203	ML-KEM	CRYSTALS-Kyber	Key encapsulation (replacing RSA and ECDH key exchange)
FIPS 204	ML-DSA	CRYSTALS-Dilithium	Digital signatures (the general-purpose choice)
FIPS 205	SLH-DSA	SPHINCS+	Digital signatures (hash-based, a conservative backup)

In 2025 NIST selected HQC as an additional key encapsulation mechanism, based on different math from ML-KEM, so there’s a fallback if a weakness turns up in the lattice-based approach. A fourth signature standard, FN-DSA, based on FALCON, has also been in development.

The algorithms are not theoretical anymore. Major browsers and CDNs already negotiate hybrid post-quantum key exchange in TLS, combining a classical algorithm with ML-KEM. Some of your traffic is likely already protected that way, whether you planned it or not.

When RSA and ECC go away

NIST’s transition guidance, published as the draft NIST IR 8547 in late 2024, sets the direction: quantum-vulnerable algorithms like RSA and elliptic curve crypto are to be deprecated around 2030 and disallowed by 2035. Check the NIST Computer Security Resource Center for the current version, since guidance like this gets refined as it’s finalized. Government and regulated sectors may face earlier dates through their own requirements.

2035 sounds far away. It’s about two hardware refresh cycles for a data center, and a fraction of the service life of most OT equipment.

In practice: When teams line 2030 and 2035 up against their own asset lifecycles, the reaction is usually a quiet recalculation. Systems being bought now will still be running in 2035, and OT equipment installed this decade may outlive both dates by years. That turns PQC from a future research topic into a procurement question for the current budget cycle. My advice is to start there: anything you buy from now on should come with a documented PQC roadmap.

What is a CBOM (cryptographic bill of materials)?

You’ve probably heard of an SBOM, a software bill of materials that lists the components inside a piece of software. A CBOM does the same for cryptography. For each system or application, it records:

• Algorithms in use, and for what (key exchange, signatures, encryption, hashing)
• Key types and sizes, such as RSA-2048 or ECDSA P-256
• Certificates, with their issuer, signature algorithm, key and expiry
• Protocols and versions, such as TLS 1.2 versus 1.3, SSH, IPsec
• Libraries and providers, such as OpenSSL, BoringSSL, Java security providers, Windows CNG, HSMs
• Where the crypto lives: in code, in configuration, in hardware, in a third-party product

The format question has a good answer. CycloneDX, the OWASP bill-of-materials standard, added CBOM support in version 1.6. That means your crypto inventory can live in the same format, and often the same tooling, as your SBOMs. It also gives vendors a standard way to tell you what cryptography is inside their products, which is worth asking for in procurement.

A CBOM isn’t a one-time document. It’s an inventory you keep current, the same way you keep a CMDB or an asset list current (or at least try to).

How to build a CBOM

There’s no single scanner that finds everything. A practical CBOM comes from several sources, merged.

1. Start with what you already have. Your certificate inventory from certificate lifecycle management already records key types and signature algorithms. That’s a CBOM seed for free.
2. Scan the network. Passive and active scanning of TLS, SSH and VPN endpoints shows which protocols, cipher suites and key types are negotiated in practice.
3. Scan code and binaries. Source and binary analysis tools can find cryptographic library calls, hard-coded algorithms and embedded keys. This is where you find the RSA-1024 someone wrote into an internal tool years ago.
4. Query your PKI. Every CA can tell you what it issues and with what keys. Your PKI is both a major source and a major subject of the CBOM.
5. Ask your vendors. For commercial products, appliances and OT equipment, you won’t see inside. Ask for a CBOM or, at minimum, their documented algorithms and their PQC roadmap.
6. Attach ownership and data sensitivity. A line that says “RSA-2048 on this API” is a fact. A line that also says “owned by payments, protects card data, needs to stay secret for seven years” is a priority.

Don’t aim for completeness on the first pass. Aim for coverage of the systems that protect long-lived sensitive data and the systems that are hardest to change. Those are where the risk and the lead time sit.

What this usually looks like: A first-pass inventory tends to surprise people less with the quantum-vulnerable algorithms, which everyone expects, and more with everything else: SHA-1 still signing internal certificates, TLS 1.0 on a management interface, RSA-1024 keys in a legacy tool, private keys sitting in source repositories. The other usual surprise is how much crypto lives inside vendor products, where the answer to “what algorithms does this use?” is a support ticket. Those findings are worth fixing on their own, quantum or not.

Crypto agility: the property you actually want

The CBOM tells you what you have. Crypto agility is the ability to change it without rewriting everything. A crypto-agile system can swap algorithms, key sizes or libraries through configuration or a library update, rather than a code change in fifty places.

Some signs you have it, and some signs you don’t:

• Agile: crypto is centralized in a few well-maintained libraries or services; certificates renew automatically; algorithms are configurable; you’ve changed an algorithm before and lived.
• Not agile: algorithms are hard-coded; certificates are installed by hand; devices can’t take firmware updates; the vendor’s answer is “next major version.”

Post-quantum algorithms make agility harder in one specific way: the keys and signatures are larger. ML-DSA signatures and public keys are much bigger than ECDSA ones, and that can break protocols, devices and message formats with fixed size limits. Constrained devices, including a lot of OT equipment, feel this first. Testing for size and performance is part of the work, not an afterthought.

A sequenced PQC readiness plan

This is how I’d order the work. The steps overlap, but the order matters.

Phase	What you do	Output
1. Inventory	Build the first CBOM, starting with certificates and network scans	A crypto inventory with owners
2. Prioritize	Rank systems by data lifetime, exposure to harvest-now-decrypt-later, and difficulty of change	A short list of high-risk, long-lead systems
3. Fix agility	Automate certificate renewal, centralize crypto libraries, get vendor roadmaps	Systems that can change algorithms on a schedule
4. Pilot	Test hybrid key exchange and PQC certificates in a lab and a few low-risk services	Known performance, size and compatibility issues
5. Migrate	Roll out by priority: key exchange first (it addresses harvest-now-decrypt-later), then signatures and PKI hierarchies	Quantum-vulnerable algorithms removed ahead of the deadlines
6. Sustain	Keep the CBOM current and make PQC support a procurement requirement	No new quantum-vulnerable crypto entering the estate

Two notes on that sequence. Key exchange comes before signatures because recorded traffic can be decrypted later, while a forged signature only matters once an attacker can forge it. And PKI hierarchies take the longest, because a new root has to be distributed to every relying party before it’s useful. If your OT devices trust a root you want to replace, that’s a project measured in years. See IEC 62443 for identity people for how those environments handle security requirements and change.

My advice: I’d scope the first 90 days around inventory and prioritization, not migration. The room needs the PKI owner, network and infrastructure, a couple of application architects, procurement, OT engineering if you have plants, and someone who can speak to data retention requirements. By day 90 you want a first CBOM covering certificates and network endpoints, a ranked list of long-lead systems, and vendor roadmap requests sent. Pilots come after that.

Where to start

PQC readiness gets talked about as a cryptography problem. In practice it’s an inventory problem followed by a change management problem. The algorithms are done. What isn’t done, in most organizations, is knowing where today’s algorithms are.

So build the CBOM first. Start with the certificate inventory you should already have, add network and code scanning, ask your vendors the awkward questions, and attach an owner to everything. Then fix crypto agility, because a CBOM you can’t act on is just a list of worries.

You don’t need to finish by next quarter. You do need to start before 2030 becomes a deadline you’re reading about in an incident report. More on the post-quantum transition is in the PQC hub.