What Is a Cryptographic Bill of Materials (CBOM)?

Most security teams can list the open source libraries in their software. Far fewer can answer a simpler question: where is RSA running right now, and what breaks if we have to pull it out? That blind spot is now a federal problem. On June 22, 2026, the White House signed Executive Order 14412, and inside it is the first time the U.S. government has asked for a cryptographic bill of materials by name. A CBOM is the inventory that closes the gap. Here is what it is, what the order actually requires, and how to start building one before the guidance lands in 2027.

Key takeaways:

• A CBOM is a structured inventory of every cryptographic asset in a software system: the algorithms, key lengths, certificate configurations, hashing functions, protocol versions, and the libraries that implement them.
• Executive Order 14412, “Securing the Nation Against Advanced Cryptographic Attacks,” signed June 22, 2026, directs CISA and NIST to publish the minimum elements for a CBOM within 270 days. It is the first federal directive to name the cryptographic bill of materials as a defined artifact.
• A CBOM is built on the same foundation as an SBOM. Teams that already run a mature SBOM program have a real head start on cryptographic inventory.
• The window is tighter than it looks. CBOM guidance from CISA arrives around March 2027, discovery is the slowest part of the whole job, and there is no reason to wait for the final rule to start.

What Is a CBOM?

An SBOM tells you what software is in your system. A CBOM tells you how that software uses cryptography. Every RSA key, every AES-128 instance, every TLS version, every certificate, every signing algorithm: where it lives, which library implements it, and whether a quantum computer will eventually break it.

Cryptography hides in the places inventories tend to miss. It sits inside APIs, open source libraries, cloud services, applications, and third-party tools you did not write and cannot easily see into. A large enterprise can be running thousands of cryptographic assets, including certificate authorities and PKI that nobody on the current team set up or even remembers exists. A CBOM makes that layer visible so you can reason about it instead of guessing.

What a CBOM catalogs:

• The encryption algorithms in use (RSA, AES, ECC, and so on) and their key lengths
• Hashing functions such as SHA-1, SHA-256, and MD5, and where each one is applied
• TLS and other protocol versions running across your services and APIs
• Certificate configurations, expiration dates, and issuing authorities
• Cryptographic library names, versions, and implementation details
• Digital signature schemes and whether each is quantum-vulnerable

There is already a machine-readable format for this. The OWASP CycloneDX project added native CBOM support in version 1.6, published as the ECMA-424 standard in 2024. It sits in the same standard family teams already use for SBOMs, which matters more than it sounds like it should. More on that below.

Why CBOMs Matter Now: The June 2026 Executive Order

Cryptographic inventory used to be something mature security teams did on their own schedule. That changed on June 22, 2026, when the White House put a clock on it.

Executive Order 14412, “Securing the Nation Against Advanced Cryptographic Attacks,” accelerates the federal government’s move to post-quantum cryptography, and for the first time it names the cryptographic bill of materials as part of the work. Here is what the order actually says:

• EO 14412 was signed on June 22, 2026, and published in the Federal Register on June 25, 2026.
• Federal agencies must move high-value assets and high-impact systems to post-quantum key establishment by December 31, 2030.
• Post-quantum digital signatures are due by December 31, 2031.
• CISA, working with NIST, has 270 days from the signing date to publish the minimum elements for a CBOM. That deadline falls around March 19, 2027.
• A proposed Federal Acquisition Regulation (FAR) rule will require covered federal contractors to meet NIST’s FIPS, including the post-quantum standards, by December 31, 2030. That pulls the requirement out of the agencies and into anyone who sells to them.
• The order also tells each agency to name a PQC migration lead responsible for agency-wide cryptographic inventory. The discovery work is written into the mandate from day one.

The trap is reading March 2027 as the start date. Agencies and contractors that wait for the final CBOM guidance before doing anything will have a shorter runway to the 2030 deadline and a much bigger bill, because discovery is the phase that takes the longest. You do not inventory thousands of cryptographic assets across code, pipelines, and cloud in a single quarter.

There is a second reason this cannot wait for quantum computers to actually show up. The executive order calls out the risk in plain terms: adversaries are collecting encrypted data now so they can decrypt it later, once a large enough quantum computer exists. The shorthand for this is harvest now, decrypt later. Anything you encrypt today with RSA or ECC is already exposed if it still needs to stay secret in ten years, which means the clock on your most sensitive data started a while ago, not on the day a quantum computer arrives.

SBOM Is the Foundation. CBOM Is the Next Layer.

For any team that already runs an SBOM program, this is the point where that investment pays off a second time. An SBOM tells you what components are in your software, and a CBOM tells you what those components do with cryptography. You cannot answer the second question until you have answered the first, because a cryptographic implementation lives inside a library, and a library is a software component. That dependency runs one direction only, which is why the SBOM is not a companion to the CBOM but a prerequisite for it.

The progression is straightforward:

• An SBOM answers: what software components exist, and how do they depend on each other?
• A CBOM answers: which of those components implement cryptography, using which algorithms, at what key strengths?
• PQC migration answers: which of those cryptographic implementations are quantum-vulnerable, and in what order do we replace them?

The formats line up too. Cycode already generates SBOMs in both SPDX and CycloneDX, and the CBOM standard is a CycloneDX extension. Teams that treat their software bill of materials as living inventory, refreshed as code changes rather than exported once a quarter for an audit, are most of the way to a cryptographic one already.

What Quantum-Vulnerable Cryptography Actually Looks Like

You do not need to understand Shor’s algorithm to run a CBOM. You need to recognize which algorithms sit on the wrong side of it. The dividing line is clean enough to hand to a scanner: one group of algorithms falls to a large quantum computer, and another group was designed to survive one. The awkward part is that most enterprise codebases still lean heavily on the first group and have barely started adopting the second.

Quantum-vulnerable, and common in enterprise software:

• RSA, at every key length. A large enough quantum computer running Shor’s algorithm breaks it.
• ECC, ECDSA, and ECDH. Same underlying math problem, same exposure.
• Diffie-Hellman key exchange.
• DSA.

The NIST-approved replacements, finalized in August 2024:

• ML-KEM (FIPS 203) for key establishment, replacing RSA and ECDH.
• ML-DSA (FIPS 204) for digital signatures, replacing RSA and ECDSA.
• SLH-DSA (FIPS 205), a hash-based signature scheme with more conservative security assumptions.

Finding these algorithms only helps if you can replace them without tearing your systems apart, and that ability has a name: crypto agility. It means you can swap one cryptographic algorithm for another without re-architecting the code that depends on it.

Most software fails this test today, because the algorithm is hard-wired into the application instead of pulled from a configuration layer. A CBOM shows you where your cryptographic dependencies are; crypto agility decides whether changing one is a config update or a six-month project. Building for it now is what turns the 2030 and 2031 deadlines into maintenance instead of a fire drill.

How to Build a CBOM: A Practical Starting Point

The hardest part of a CBOM is not the cryptography, it is the blank page. Most teams have no map of where their cryptography lives, and starting one from scratch is nobody’s idea of a good quarter. The useful thing to know is that you almost never have to start from scratch, because the raw material already sits inside inventories and scans your teams run for other reasons.

The six steps below turn that existing material into a cryptographic inventory rather than a standing start, roughly in the order you would actually work through them.

1. Start with your SBOM

If you already have a software component inventory, you know which libraries are in scope for cryptographic scanning. If you do not, that is step zero, and it starts with software composition analysis. Everything after this point assumes you can see your components, so this is the step that pays for itself.

2. Find the cryptographic libraries

Scan your component inventory for the usual names: OpenSSL, BouncyCastle, libsodium, the Java Cryptography Architecture, Python’s cryptography package, and whatever else is specific to your stack. This narrows a list of every dependency down to the ones that actually touch cryptography, which is a much shorter and more manageable set to reason about.

3. Map where the algorithms are actually used

For each cryptographic library, work out which algorithms get called and where, in the code and in the running infrastructure. Dependency scanning will not tell you this on its own, because a library being present is not the same as an algorithm being invoked. You need code-level analysis to see what actually runs, not just what is installed.

4. Classify each one by quantum risk

Tag every cryptographic primitive as quantum-vulnerable, post-quantum safe, or unclear, against the NIST classification. The “unclear” pile is usually bigger than teams expect, and it is where most of the real work hides. Getting an asset out of that pile and into one of the other two is often the single most valuable thing this exercise produces.

5. Rank the findings by what you would actually lose

Not every instance of RSA carries the same weight. A signing key protecting a decade of customer records matters far more than a TLS handshake on an internal dashboard that rotates every hour. Sort the inventory by how sensitive the protected data is and how long it has to stay secret, and let that ranking decide what moves first, which puts authentication systems and long-lived data at the top where they belong.

6. Treat the inventory as the beginning, not the deliverable

A CBOM tells you where you stand, and not much more than that. It does not tell you the order to fix things, how a single change will ripple through systems that share a certificate, or who owns the migration for each service. Work those questions while you build the inventory rather than after, because the migration is the expensive part and a good CBOM is what turns that migration into a plan instead of guesswork.

It is worth being straight about tooling here, because the market is still catching up to the standard itself. Cycode generates SBOMs today in SPDX and CycloneDX as part of its Agentic Development Security Platform, which gives you the component inventory the rest of this depends on.

Dedicated CBOM generation is not a settled product category yet, for Cycode or anyone else, because the minimum elements are still being defined under the 270-day NIST and CISA mandate. The teams in the best position when that guidance lands are the ones whose SBOM foundation is already solid.

Start where the compliance clock already points

The organizations that handle this well will not be the ones who move fastest in 2027. They will be the ones who already knew where their cryptography lived when the guidance dropped. That knowledge starts with an inventory of your software, which is the same inventory a CBOM extends. If your SBOM program is still a manual export you run once a quarter, that is the gap to close first.

As an Agentic Development Security Platform, Cycode generates SBOMs in SPDX and CycloneDX straight from your repositories and pipelines, keeps them current as your code changes, and correlates them with the rest of your findings on the Context Intelligence Graph, turning a raw inventory into risk you can prioritize and act on. That component visibility is the foundation a cryptographic inventory extends. See how Cycode delivers it across your supply chain security.