What is a cryptographic bill of materials (CBOM) and why does your organization need one before the post-quantum deadline?

A cryptographic bill of materials (CBOM) is a structured, machine-readable inventory of every cryptographic asset in your software and infrastructure: the algorithms you use, the keys, certificates, protocols, libraries, and the dependencies that carry them. Think of it as the SBOM's cryptographic sibling. Where an SBOM tells you what components ship inside an application, a CBOM tells you which of those components perform encryption, which algorithms they rely on, where the keys live, and how exposed those choices are to quantum-era attacks. As of August 2026, the CBOM has moved from a niche idea discussed by think tanks like the Foundation for Defense of Democracies into a practical compliance artifact driven by US executive orders mandating the transition to post-quantum cryptography (PQC), vendor offerings from Palo Alto Networks and Wiz, and enterprise deployments such as Citibank's selection of QuantumGenie for cryptographic discovery.

The Direct Answer: What a CBOM Actually Contains

Also worth reading: How should enterprises approach post-quantum algorithm benchmarking in 2026 to ensure secure and efficient migration? · How does a post-quantum cryptography testing framework function for AI product development in 2026? · What is the definitive post-quantum crypto implementation checklist for enterprise systems in 2026?

A CBOM documents four categories of information. First, algorithmic inventory: every instance of RSA, ECC, AES, SHA-2, TLS configuration, and any PQC algorithms such as ML-KEM (Kyber) or ML-DSA (Dilithium) already in use. Second, asset locations: which binaries, containers, firmware images, HSMs, or cloud services contain or invoke those algorithms. Third, key and certificate metadata: key lengths, expiry dates, rotation policies, and whether keys are quantum-vulnerable. Fourth, dependency relationships: which third-party libraries (OpenSSL, BoringSSL, wolfSSL) bring cryptography in transitively, often without the development team knowing.

The format matters less than the discipline. Some organizations express CBOMs as extensions to CycloneDX, which added native support for cryptographic properties; others maintain proprietary schemas tied to their discovery tooling. What matters is that the inventory is queryable: when NIST deprecates an algorithm or a vulnerability lands in a crypto library, you should be able to answer "where do we use this?" in minutes rather than months. Organizations that cannot answer that question today are, functionally, flying blind on roughly 30-40% of their attack surface, since most enterprises have no accurate count of their cryptographic endpoints.

Why Now: The Regulatory and Quantum Clock

Three forces converged between 2024 and 2026. NIST finalized its first post-quantum standards (FIPS 203, 204, 205) in August 2024, giving vendors concrete targets. US executive orders and federal strategy documents then mandated agency transitions to PQC, with OMB and NSA timelines pushing critical national security systems toward quantum-resistant algorithms well before 2030, and broader federal systems following through 2035. Compliance regimes like PCI DSS 4.0 and emerging EU requirements increasingly demand visibility into cryptographic posture, not just presence of encryption.

Meanwhile, the threat model sharpened. Adversaries are harvesting encrypted traffic now with the intent to decrypt later once cryptographically relevant quantum computers exist — the "harvest now, decrypt later" problem. Data with a confidentiality horizon beyond five to ten years is already at risk. And classical cryptography is failing faster than expected in places: South Korea certified a hybrid post-quantum encryption module in 2026 partly because AI-assisted cryptanalysis broke the HAWK lattice-based algorithm in roughly 60 hours, a reminder that "post-quantum" candidates themselves need scrutiny and that hybrid approaches (classical plus PQC) remain prudent during the transition. A CBOM is the prerequisite for any of this work: you cannot migrate algorithms you cannot find.

How CBOM Discovery Actually Works

Building a CBOM involves three technical approaches, usually combined. Static analysis scans source code and binaries for cryptographic API calls and constants — fast, broad, but blind to runtime configuration and easy to fool with obfuscation. Dynamic analysis instruments running applications to observe actual cipher negotiation, certificate exchange, and library loading — accurate but limited to what you can execute. Network observation inspects TLS handshakes and protocol metadata at gateways — excellent for external-facing traffic but invisible to internal service-to-service calls and anything encrypted end-to-end below the transport layer.

Mature programs layer all three. Discovery tooling from vendors like Wiz (whose post-quantum preparation guidance emphasizes cloud-native discovery), Palo Alto Networks (whose Quantum-Safe Security offering pairs network-level detection with enforcement), and specialists like QuantumGenie (selected by Citibank for enterprise cryptographic discovery) typically reports findings as CBOM-compatible inventories. Expect the first scan of a mid-size enterprise to surface thousands of distinct cryptographic assets, including legacy SSH configurations, forgotten internal PKI, embedded RSA-1024 in firmware, and MD5 usage in places nobody remembers approving. The shock factor is real: industry surveys consistently show organizations underestimate their cryptographic footprint by an order of magnitude.

CBOM vs. SBOM vs. Manual Inventory: A Comparison

The honest takeaway: if you already run mature SBOM pipelines, extending them toward CBOM is incremental work. If your cryptographic inventory lives in a spreadsheet last touched in 2023, treat that document as fiction until proven otherwise.

Practical Steps to Build Your First CBOM

Start with scoping, not scanning. Define which business systems hold data whose confidentiality horizon exceeds seven years — customer PII, health records, intellectual property, long-lived credentials. Those systems get priority-one treatment. Next, pick discovery tooling appropriate to your stack: cloud-heavy estates benefit from agentless cloud security platforms with crypto modules; on-premise and embedded estates need binary analysis capability; network-heavy environments want passive TLS inspection.

Run the baseline scan and resist the urge to fix everything immediately. Triage instead using a simple risk formula: data sensitivity times exposure window times migration difficulty. RSA-2048 protecting a three-year retention database behind TLS 1.3 can wait; RSA-1024 signing firmware updates that will still be verified in 2035 cannot. Establish ownership — every cryptographic asset needs a named team responsible for its migration path. Then integrate CBOM generation into CI/CD so new code declares its crypto usage at build time, the same discipline that made SBOMs sustainable. Finally, set a review cadence tied to external events: new NIST guidance, vendor advisories on crypto libraries, and annual re-baselining at minimum.

Budget realistically. Tooling licenses for enterprise cryptographic discovery commonly run from tens of thousands annually for point solutions to several hundred thousand for platform-wide coverage. The larger cost is engineering time for remediation: migrating a single widely-used internal service off a deprecated algorithm typically consumes two to six engineer-weeks including testing, and enterprises routinely discover hundreds of such services.

Common Mistakes That Undermine CBOM Programs

The most frequent failure is treating the CBOM as a one-time audit artifact. Cryptography changes constantly — certificates rotate, libraries update, teams ship new services — so a snapshot from January is stale by March. Automation must be continuous or the inventory decays into noise.

Second mistake: ignoring transitive dependencies. Your application may declare OpenSSL directly, but dozens of nested packages may embed their own crypto stacks, and container base images frequently ship outdated crypto libraries that never appear in application manifests. Third: over-focusing on TLS while neglecting asymmetric signatures, code signing, VPNs, and hardware tokens — attackers and auditors look everywhere. Fourth: assuming PQC migration is purely a swap-in. Many PQC algorithms have larger key sizes and different performance profiles; ML-KEM public keys are over 1 KB versus 256 bytes for X25519, which breaks assumptions in handshake sizing, embedded devices, and some protocol implementations. Fifth: skipping hybrid modes during transition. Given episodes like the 60-hour AI-assisted break of HAWK, deploying pure PQC without a classical fallback is premature optimization with real downside risk.

Finally, do not let the perfect be the enemy of the done. A CBOM covering 85% of assets with continuous updates beats a 99%-accurate snapshot refreshed yearly. Coverage trends matter more than point-in-time completeness.

When to Act: Timelines and Thresholds

If you handle federal contracts, act now — agency mandates already bind many systems, with critical national security systems facing earlier deadlines and general federal systems targeted around 2030-2035 depending on classification. If you operate in payments, PCI DSS 4.0's expanded requirements make cryptographic visibility effectively mandatory, and acquirers are asking questions in 2026 audits. If you are a SaaS vendor selling to banks or healthcare, expect CBOM requests in procurement questionnaires within the next 12-18 months; early movers like Citibank signal that large buyers will demand cryptographic transparency from suppliers.

For everyone else, a reasonable threshold: any organization whose data must stay confidential past 2035, or which operates infrastructure with replacement cycles longer than five years (industrial control, automotive, medical devices), should begin discovery in 2026-2027. Migration itself takes years — industry consensus estimates two to five years for a large enterprise to complete a full PQC transition after discovery completes, and discovery alone takes six to eighteen months. Working backward from 2030-2035 deadlines means the decision window is essentially now.

Costs, Trade-offs, and an Honest Assessment

CBOM programs are not cheap, and honest writing requires saying so. Beyond licensing costs, there is organizational friction: security teams gain visibility, but application teams inherit remediation backlogs they did not budget for. Some discovered problems — embedded RSA-1024 in third-party medical devices, for instance — have no clean fix and require compensating controls or vendor pressure. Roughly 10-20% of discovered assets in typical enterprises fall into this "known, unfixable near-term" category.

There is also hype to discount. Not every vendor claiming "quantum readiness" delivers genuine discovery depth; some bolt a crypto scanner onto existing products and call it a CBOM generator. Evaluate tools against whether they detect crypto in binaries, containers, and network traffic simultaneously, and whether output exports to open formats like CycloneDX rather than locking you into a proprietary schema. And keep perspective: for a small company with no long-horizon secrets and no regulated obligations, a lightweight open-source scan plus documentation discipline may deliver 80% of the value at 5% of the cost. Scale the program to your actual risk, not to conference-keynote anxiety.

That said, the asymmetry favors action. The cost of building a CBOM is bounded and known; the cost of discovering in 2031 that your archive backups, signed firmware, or long-term contracts rest on broken cryptography is unbounded. For product and innovation teams specifically — including teams using AI-driven concept generation platforms to design new software — specifying cryptographic requirements and CBOM compatibility at design time costs almost nothing and eliminates entire classes of retrofit pain later.

The Bottom Line

A cryptographic bill of materials answers a question every organization will be asked by 2027: "exactly what cryptography do you run, where, and when does it become obsolete?" The regulatory clock, the harvest-now-decrypt-later threat, and buyer procurement demands have converted this from best practice to table stakes for anyone handling sensitive or long-lived data. Start with discovery, triage by data sensitivity and exposure horizon, automate continuously, prefer hybrid PQC during transition, and scale investment to genuine risk. The organizations that built SBOM muscle early found compliance cheaper than their competitors; the same dynamic is now playing out with CBOMs, on a tighter timeline.", "faq": [ { "q": "Is a CBOM legally required in 2026?", "a": "For US federal agencies and contractors, yes in effect — executive orders and agency strategy mandate post-quantum transition planning, which presupposes cryptographic inventories. For private companies, CBOMs are not yet universally mandated by name, but PCI DSS 4.0 and growing procurement requirements make cryptographic visibility practically compulsory in regulated sectors.", "weight": null }, { "q": "How is a CBOM different from an SBOM?", "a": "An SBOM lists the software components in a product; a CBOM lists the cryptographic assets — algorithms, keys, certificates, protocols — across those components and infrastructure. They overlap since crypto libraries appear in both, but a CBOM adds key metadata, algorithm strength assessment, and quantum-vulnerability context that SBOMs lack.", "weight": null }, { "q": "What is 'harvest now, decrypt later' and why does it matter for CBOMs?", "a": "It is the practice of capturing encrypted traffic today to decrypt once quantum computers can break RSA and ECC, possibly in the 2030s. It matters because data with long confidentiality horizons is already compromised in principle, and a CBOM is how you identify which datasets and channels face that exposure.", "weight": null }, { "q": "Which post-quantum algorithms should appear in a modern CBOM?", "a": "NIST-standardized FIPS 203 (ML-KEM/Kyber) for key encapsulation, FIPS 204 (ML-DSA/Dilithium) and FIPS 205 (SLH-DSA/SPHINCS+) for signatures. During transition, hybrid combinations pairing these with classical algorithms like X25519 or Ed25519 are recommended, especially given incidents like the rapid AI-assisted break of the HAWK candidate.", "weight": null }, { "q": "How long does a full PQC migration take after building a CBOM?", "a": "Industry estimates range from two to five years for a large enterprise, depending on the number of assets, embedded system constraints, and vendor dependency. Discovery itself takes six to eighteen months, which is why organizations targeting 2030-2035 deadlines need to start in 2026-2027." } ], "quick_facts": [ { "label": "Category", "value": "Cryptographic asset management / post-quantum readiness" }, { "label": "Timeline", "value": "Discovery: 6-18 months; full PQC migration: 2-5 years; federal deadlines cluster 2030-2035" }, { "label": "Cost", "value": "$50k-$500k/year for enterprise discovery tooling; free/open-source options cover small orgs" }, { "label": "Best for", "value": "Enterprises with long-lived sensitive data, federal contractors, payment processors, SaaS vendors selling to regulated industries" }, { "label": "Key standard", "value": "NIST FIPS 203/204/205 (finalized Aug 2024); CycloneDX supports CBOM-style crypto properties" }, { "label": "Urgency driver", "value": "Harvest-now-decrypt-later attacks affect any data needing confidentiality past ~2035" } ], "sources": [ "https://www.fdd.org/analysis/2024/cryptography-bill-of-materials", "https://www.wiz.io/academy/preparing-for-post-quantum-cryptography", "https://www.skadden.com/insights/publications/new-executive-orders-and-government-strategy-advance-us-quantum-innovation", "https://www.thebeaconjournal.com/story/business/citibank-selects-quantumgenie", "https://www.paloaltonetworks.com/blog/quantum-safe-security", "https://www.techtimes.com/south-korea-certifies-hybrid-post-quantum-encryption-module" ], "follow_up_keyword": "post-quantum cryptography migration checklist"