The Cryptographic Bill of Materials (CBOM): What SBOM Teams Need to Know
| Interlynk
Executive Order 14412 put a clock on cryptographic inventory. This guide explains what a Cryptographic Bill of Materials (CBOM) is, how it differs from an SBOM, why it lives in the same CycloneDX standard your SBOM program already uses, who is affected, and how to take the first practical steps toward post-quantum readiness.
Overview
There is a new term about to show up on a lot of security roadmaps: the Cryptographic Bill of Materials, or CBOM. A US executive order named it directly in June 2026 and set a clock for federal guidance on it. If your reaction is that this sounds like one more inventory to build from scratch, the useful thing to know early is that it is not. A CBOM is the next layer on the standard your SBOMs already use.
This guide covers what a CBOM is, how it differs from an SBOM, where the executive order fits, and what you can do now without waiting for the final rules.
CBOM at a Glance
A Cryptographic Bill of Materials is a machine-readable inventory of the cryptographic assets inside a piece of software or a system: the algorithms in use, their key sizes and modes, the libraries that implement them, the certificates and keys, and the protocols that depend on them. An SBOM answers what components are in your software. A CBOM answers a narrower question on top of that: what cryptography those components use, and whether any of it is quantum-vulnerable. Executive Order 14412, signed June 22, 2026, directs CISA and NIST to publish minimum elements for a CBOM, and CycloneDX, the same standard that carries your SBOM, already supports it.
Legal Basis: Executive Order 14412
On June 22, 2026, the White House signed Executive Order 14412, "Securing the Nation Against Advanced Cryptographic Attacks," published in the Federal Register three days later. The order speeds up the federal move to post-quantum cryptography, and for the first time in US policy, it names the cryptographic bill of materials as part of that work.
Three dates are worth pinning down. CISA, working with NIST, has 270 days from the order to publish guidance on the minimum elements for a CBOM, which lands that guidance in early 2027. Federal agencies have until December 31, 2030 to move high-value assets and high-impact systems to post-quantum key establishment, and until December 31, 2031 for post-quantum digital signatures. A proposed Federal Acquisition Regulation rule pushes the underlying post-quantum requirements out to covered federal contractors.
On paper the order applies to US federal civilian agencies. In practice it travels further. Sell software to the government, or to a company that does, and the contractor requirements follow the supply chain to you. Cryptographic-inventory expectations also have a habit of moving from federal policy into regulated industries, which is exactly how SBOM requirements spread through healthcare, finance, and critical infrastructure after Executive Order 14028 in 2021.
SBOM vs CBOM
An SBOM and a CBOM describe the same software from two different angles.
An SBOM is a component inventory. It lists the libraries, frameworks, and dependencies an application is built from, with versions and identifiers, so you can match components against known vulnerabilities and license terms.
A CBOM zooms in on one property of those components: the cryptography they use. It records which algorithms, at what key sizes, through which libraries and protocols. And it is built for a different job. An SBOM feeds vulnerability management and compliance. A CBOM feeds cryptographic agility, the ability to find and swap out weak or quantum-vulnerable cryptography before it becomes a problem.
They work together. An SBOM tells you a component is present. A CBOM tells you that component leans on RSA-2048, which a capable quantum computer would eventually break. You need the first to build the second, which is why a team with a working SBOM practice is already halfway there.
One Standard, Two Layers
The detail that keeps this from being a from-scratch project: a CBOM is not a new file format or a rival standard. It is an extension of CycloneDX, the same specification many teams already run for SBOMs.
CBOM support came out of IBM Research and landed in CycloneDX version 1.6, released in April 2024 and ratified as the international standard ECMA-424, 1st Edition, that June. Version 1.7, released in October 2025 and adopted as ECMA-424, 2nd Edition, expanded it with standardized cryptographic algorithm families and elliptic-curve references aimed at post-quantum readiness.
Under the hood, a CBOM treats each cryptographic asset as a component in the CycloneDX schema and adds "uses" and "implements" links to the dependency graph. That lets you express a chain: an application uses a protocol, the protocol relies on an algorithm, a library implements it. Because it sits inside CycloneDX, a CBOM works with the tooling your SBOM workflow already depends on. If you are producing CycloneDX SBOMs today, you are already running the standard a CBOM is written in. For a refresher on how CycloneDX stacks up against the other main format, see our guide on CycloneDX vs SPDX.
Who Should Care Now
The order is federal. The audience is wider.
Federal contractors and subcontractors feel it first. Between the proposed FAR rule and the procurement pressure the order creates, post-quantum requirements, and the cryptographic inventory behind them, are heading toward anyone who sells software into the government.
Regulated industries are next. Healthcare, financial services, and energy already carry cryptographic obligations, and they were first in line to inherit SBOM expectations after 2021. The path is familiar by now: a requirement starts in federal policy, hardens into procurement language, then turns up in sector regulation. Teams in medical devices, industrial systems, and critical infrastructure have good reason to build the inventory before it is asked of them.
For everyone else, treat it as an early read on where things are going. Cryptographic agility is becoming a plain expectation of secure software, regulation or not, and the inventory is what makes it possible.
Harvest Now, Decrypt Later
The reason to inventory cryptography now, years before a large quantum computer exists, has a name: harvest now, decrypt later. An attacker copies encrypted data today, sits on it, and decrypts it once quantum capability arrives. For anything with a long confidentiality lifetime, patient records, financial data, state secrets, defense designs, the clock has already started. The data being captured now will still be sensitive on the day the cryptography protecting it can be broken.
That is why cryptographic inventory is time-sensitive rather than routine. You cannot migrate what you cannot see, and the migration needs to be well along before quantum capability lands, not scrambling to begin after.
From Inventory to Readiness
A CBOM is the first step toward post-quantum readiness, and it does not get you all the way there. An inventory shows where cryptography lives. Readiness means knowing which of it matters most, how hard each piece is to replace, what it interoperates with, and in what order to change things. Mapping and migrating are different jobs.
The inventory is what makes the rest possible, though. Cryptography hides deep in components, protocols, and libraries, often several layers down, right where SBOM tooling is already looking. A CBOM pulls that buried cryptographic footprint into something a tool can read, rank, and track as the software changes. Skip it, and a post-quantum migration is mostly guesswork.
Practical First Steps
You do not need the final CISA and NIST guidance to start. The minimum elements will tidy up the format. They will not change the underlying work of seeing your own cryptography.
Inventory your cryptographic footprint. Find the algorithms, key sizes, libraries, certificates, and protocols in use across your products, the same build-aware way you already generate SBOMs.
Flag the quantum-vulnerable pieces. RSA, elliptic-curve cryptography, Diffie-Hellman, and old hashes like MD5 and SHA-1 surface first. Knowing where they sit is the whole point.
Use the standard you already run. Produce the CBOM in CycloneDX so it lives next to your SBOMs and plugs into your existing tooling, instead of in a one-off spreadsheet.
Prioritize by data lifetime. Long-lived sensitive data is the harvest-now target. Start where the confidentiality window is longest.
Keep it current. Like an SBOM, a CBOM is only worth having if it matches what you actually ship. Regenerate it as the code changes.
The Bottom Line
Executive Order 14412 took cryptographic inventory from something mature teams did on their own schedule and put a federal clock on it. The minimum elements are still being written, but the direction is set, and it tracks the SBOM story closely enough that the takeaway is obvious.
A team already running an SBOM program is not starting from zero. You have the tooling, the standard, and the build-aware discovery a CBOM leans on. The next layer is cryptographic visibility, and the teams that add it now will be ready when the guidance lands and the procurement language catches up.
Interlynk helps teams build and maintain machine-readable inventories of what their software is made of, in CycloneDX and SPDX, across the full product lifecycle. As cryptographic transparency joins the same conversation, the foundation is the one you already need for SBOMs: accurate, build-aware, continuously updated component visibility. See our Cyber Resilience Act solution, or book a demo to talk through where SBOM and cryptographic inventory meet.
This guide reflects Executive Order 14412 and publicly available CycloneDX and NIST materials, and was written for accuracy at the time of publication. The CISA and NIST CBOM minimum-elements guidance is forthcoming and may refine these details. Confirm current requirements against official CISA, NIST, and CycloneDX sources. This article is informational and not legal advice.
References
Executive Order 14412, "Securing the Nation Against Advanced Cryptographic Attacks" (Federal Register): https://www.federalregister.gov/
CycloneDX v1.6 release, CBOM introduced: https://cyclonedx.org/news/cyclonedx-v1.6-released/
CycloneDX v1.7 release, expanded CBOM: https://cyclonedx.org/news/cyclonedx-v1.7-released/
NIST Post-Quantum Cryptography project: https://csrc.nist.gov/projects/post-quantum-cryptography