Post-Quantum Cryptography Is Coming. Is Your Crypto Inventory Ready?

NIST has finalized its post-quantum cryptography standards and CERT-In has already expanded its BOM guidelines to cover it. Here's what CBOM and QBOM actually are, why they are becoming board-level priorities, and where to start.

Every certificate you issue today, every key you rotate, every TLS handshake your platform completes this quarter is being recorded by someone who cannot break it yet but is patient enough to wait until they can.

That is not a hypothetical. It has a name harvest-now-decrypt-later and it is the reason "post-quantum cryptography" stopped being a research topic and became a compliance line item in 2024 and 2025.

Security teams have spent the last decade building muscle memory around software inventories: know your components, know your versions, know your vulnerabilities. Post-quantum readiness asks a different, harder question: do you even know what cryptography your organisation is running, where, and for how much longer it will be trustworthy?

For most organisations, the honest answer is no. That is exactly the gap that two new entrants in the Bill of Materials family CBOM (Cryptographic Bill of Materials) and QBOM (Quantum Bill of Materials) are built to close.

Why 2024–2025 Changed Everything

Post-quantum cryptography has been a research agenda since 2016, when the U.S. National Institute of Standards and Technology (NIST) opened its public competition to find encryption algorithms that could survive an attack from a sufficiently powerful quantum computer. That competition produced a result on 13 August 2024, when NIST formally released its first three finalized post-quantum standards:

• FIPS 203 (ML-KEM) general-purpose encryption and key exchange, derived from CRYSTALS-Kyber
• FIPS 204 (ML-DSA) the primary digital signature standard, derived from CRYSTALS-Dilithium
• FIPS 205 (SLH-DSA) a structurally different, hash-based backup signature scheme, derived from SPHINCS+

NIST's own guidance was unambiguous: organisations should "start integrating them into their systems immediately," and there is "no need to wait for future standards." (NIST, August 2024)

The U.S. National Security Agency reinforced this with its CNSA 2.0 suite, which sets hard dates: quantum-resistant algorithms become required for new National Security Systems acquisitions by 2030, with classical RSA and ECC scheduled for phase-out by the early-to-mid 2030s (CSA / Entrust summaries of CNSA 2.0).

India moved almost as quickly. In July 2025, CERT-In released Version 2.0 of its Technical Guidelines on Software Bill of Materials explicitly extending the framework beyond SBOM to cover QBOM, CBOM, AIBOM, and HBOM as a connected family of bills of materials for the modern technology stack (azbpartners.com legal analysis of CERT-In v2.0).

Timeline showing NIST opening the PQC competition in 2016, FIPS 203/204/205 finalized in August 2024, CERT-In v2.0 adding QBOM and CBOM in July 2025, CNSA 2.0 required for new NSS acquisitions by 2030, and classical RSA/ECC phased out for NSS by 2033-35. The post-quantum migration clock: the milestones every crypto inventory now has to track.

That is three independent bodies a standards agency, a national security agency, and a national CERT converging on the same conclusion within twelve months: cryptographic visibility is no longer optional.

What Is a CBOM (Cryptographic Bill of Materials)?

A CBOM is the cryptographic equivalent of an SBOM. Where an SBOM inventories the open-source libraries and packages inside your software, a CBOM inventories the cryptography running inside it.

As OWASP's CycloneDX project which formally added cryptographic asset support in its v1.6 specification describes it, a CBOM lets cryptographic assets be documented and combined with other components, "unlocking the possibility of a cryptographic inventory" (OWASP CycloneDX blog).

A useful CBOM captures, at minimum:

• Algorithms in use RSA, ECC, AES, and their quantum-vulnerable or quantum-safe status
• Certificates and keys including expiry dates, rotation cadence, and issuing authority
• Protocol configurations TLS versions, IPsec, SSH ciphers actually negotiated in production
• Certification levels FIPS 140-3, Common Criteria, and similar attestations
• Relationships which applications, services, and libraries depend on which cryptographic primitive

Researchers at IBM and the OWASP Foundation have been formalising this standardisation work specifically because ad hoc, spreadsheet-based crypto inventories do not scale and cannot answer the one question that matters during a migration: "if this algorithm is deprecated tomorrow, what breaks?" (IBM Research, CycloneDX CBOM standardisation).

Put simply: a CBOM is what tells you where RSA and ECC are actually hiding in your estate today the exact starting point every post-quantum migration plan needs and almost never has.

What Is a QBOM (Quantum Bill of Materials) and How Is It Different?

This is where terminology gets murky, and it is worth being precise, because the two acronyms get used interchangeably in the market and they are not the same thing.

A QBOM, as CERT-In frames it, inventories quantum computing components themselves: quantum algorithms, quantum key distribution (QKD) protocols, quantum hardware elements, and the quantum-specific software dependencies inside systems that actually run quantum technology.

A CBOM, by contrast, is relevant to almost every organisation today it maps classical, quantum-vulnerable cryptography (RSA, ECC, Diffie-Hellman) wherever it is deployed. A QBOM is relevant to a much smaller set of organisations: those actively building, operating, or integrating quantum computing or quantum-secure communication hardware.

For the overwhelming majority of enterprises preparing for the post-quantum transition, the CBOM is the priority. Without it, prioritisation of what to migrate first is guesswork (postquantum.com, QBOM vs CBOM).

Side-by-side comparison: CBOM (Cryptographic Bill of Materials) documents algorithms, certificates, keys and TLS configuration in use today and is needed by nearly every organisation; QBOM (Quantum Bill of Materials) documents quantum algorithms, QKD protocols, quantum hardware and software dependencies and is needed by organisations deploying quantum computing directly. CBOM and QBOM answer different questions and most organisations need both, in this order.

CERT-In's decision to place both under one BOM umbrella alongside SBOM, HBOM, and AIBOM is deliberate: it signals that regulators now expect organisations to reason about every layer of composition software, hardware, AI models, cryptography, and quantum dependencies as a connected governance problem, not five separate spreadsheets.

The Regulatory Signal Is Not Going Away

It is tempting to treat this as another acronym cycle. The pattern says otherwise.

Notice the throughline: every one of these frameworks assumes an organisation can already answer "what cryptography do we have, and where?" That assumption fails in most organisations today, for the same reason SBOM adoption stalled for years teams have the intent but not the tooling.

Where Most Organisations Actually Are

Ask most CISOs whether they can produce, right now, a complete list of every TLS certificate, every cryptographic library version, and every algorithm negotiated in production across their estate and the honest answer is silence, followed by "we'd need a few weeks."

A few weeks is exactly what an active harvest-now-decrypt-later adversary is counting on. The gap between "we know it's a priority" and "we have a queryable inventory" is where post-quantum risk actually lives.

Closing that gap requires the same discipline SBOM programmes eventually learned the hard way:

1. Start with discovery, not policy. You cannot write a sensible PQC migration roadmap before you know where RSA-2048 and ECDSA are actually deployed. A CBOM generated from your real build artefacts, certificates, and TLS configuration is that starting point.

2. Treat it as living data, not a one-time audit. Certificates rotate, dependencies update, new services ship weekly. A CBOM snapshot from last quarter is already stale the same lesson CERT-In's SBOM guidelines drilled into the industry.

3. Prioritise by exposure, not by convenience. Internet-facing systems handling long-lived sensitive data are the harvest-now-decrypt-later targets that matter first, not whichever service is easiest to touch.

4. Build for crypto-agility. The point of cataloguing algorithms is being able to swap them quickly when FIPS 203/204/205 successors or CNSA 2.0 deadlines demand it.

5. Map QBOM only where it's actually relevant. If your organisation isn't operating quantum hardware or QKD infrastructure, don't let the acronym distract from the CBOM work that matters today.

Where IntelliXBOM Fits

This is precisely the visibility gap IntelliXBOM was built to close. In the same way IntelliXBOM continuously generates and validates SBOMs against CERT-In's 21 mandatory fields, it extends that same discipline into the cryptographic layer automatically cataloguing the cryptographic libraries, algorithms, certificates, and protocol configurations embedded across your software estate, and mapping them against CERT-In's CBOM expectations and the wider post-quantum timeline.

Instead of a manual crypto audit that's outdated the day it's finished, you get a living, continuously refreshed inventory one your security, compliance, and engineering teams can actually query when the next migration deadline lands.

Ready to see where your quantum-vulnerable cryptography actually lives?

Schedule Your CBOM Demo Today →

See a live CBOM generated from your own environment, mapped against CERT-In's guidelines and the NIST/CNSA 2.0 timeline no slideware, no spreadsheets.

The Bottom Line

Post-quantum cryptography stopped being theoretical the moment NIST published final standards and CERT-In folded QBOM and CBOM into its compliance framework. The organisations that will navigate this transition calmly are not the ones with the best slide deck on quantum risk they are the ones that already know, with evidence, exactly where their vulnerable cryptography lives.

An inventory sounds unglamorous next to "quantum computing." It is also the only thing standing between "we have a migration plan" and "we're guessing."