A New Bill of Materials Just Got a Federal Deadline. Does Your Team Know How to Build It?

October 30, 2026

Rodney Hall, COO— AI-assisted and reviewed prior to publication.

A cryptographic bill of materials, or CBOM, is a machine-readable inventory of every algorithm, key length, certificate, and protocol running inside your software and hardware. Executive Order 14412 just told CISA and NIST to define what one has to contain, and the teams who will actually build these documents mostly don't exist yet.

What is a cryptographic bill of materials, and why does it have a deadline now?

A CBOM is the cryptographic layer that sits on top of the software inventory work your organization may already be doing. Where a software bill of materials lists the libraries and dependencies inside an application, a CBOM lists the cryptographic assets those components actually use, down to the algorithm, the key size, and the certificate.

The deadline comes from Executive Order 14412, "Securing the Nation Against Advanced Cryptographic Attacks," signed June 22, 2026. Section 5(d) of the order directs CISA, working with NIST, to publish public guidance on the minimum elements of a CBOM within 270 days, putting that guidance on track for roughly mid-March 2027. The stated goal is guidance that will enable the automated assessment of the cryptographic assets utilized by a hardware or software element, rather than another spreadsheet nobody updates.

This isn't a standalone requirement. It rides on a broader migration timeline. The same order sets a December 31, 2030 deadline for federal agencies to move high-value assets and high-impact systems to post-quantum key establishment, and December 31, 2031 for post-quantum digital signatures, dates confirmed in Cloudflare's breakdown of the executive order. OMB Memorandum M-26-15, issued two days after the order, adds the CBOM as a new artifact contractors will have to produce alongside those migration milestones.

Who actually owns building a CBOM inside a typical security organization?

Right now, mostly nobody, which is the real problem. The split that's emerging in early guidance puts product and application security teams in charge of the CBOM for source code and application dependencies, while IT operations or a dedicated cryptographic governance function owns the broader inventory across PKI, network, cloud, and hardware. Those are two different skill sets, and most organizations have staffed for neither.

Application security teams that already run SBOM programs have tooling and process muscle memory. They know how to generate a component list in CI/CD, map it to a standard format, and feed it into vulnerability scanning. What they typically don't have is deep comfort with cryptographic primitives, that is, knowing a 2048-bit RSA key from a weak elliptic curve implementation, or understanding why a given TLS configuration is quantum-vulnerable while another isn't. Executive Order 14412 also requires agencies to support TLS 1.3 or a successor version no later than January 2, 2030, which is exactly the kind of protocol-level detail a CBOM has to capture and an SBOM never touches.

On the other side, network and systems teams who manage certificates, key vaults, and hardware security modules understand cryptography in the operational sense but rarely own structured, machine-readable asset inventories the way application security teams do. Building a usable CBOM means pulling both groups into the same inventory discipline, with someone accountable for reconciling what each group finds.

Why this is harder than extending an existing SBOM program

Treating a CBOM as "SBOM plus a few crypto fields" undersells the work involved. Cryptographic assets live in places source-code scanners never reach: hardware security modules, network appliance firmware, embedded certificates on IoT devices, and legacy systems where nobody remembers which library handles the handshake. NIST's draft IR 8547 timeline proposes deprecating RSA, ECDSA, ECDH, and finite-field Diffie-Hellman after 2030, which means a CBOM has to flag every instance of those algorithms wherever they sit, not just inside application code.

The federal SBOM program itself offers a cautionary note on how long this kind of work takes to mature. Even after CISA, NSA, and partners across 19 countries released a shared SBOM guidance document to improve adoption, software bills of materials remain inconsistent in practice across the industry years after their original 2021 mandate. A CBOM program starting from closer to zero, with a harder underlying problem, should not be expected to mature faster.

Here's a rough comparison of what each inventory type actually has to capture:

What this means for your certification and skills planning

If your team is going to own any part of a CBOM, cryptographic literacy stops being a specialty and becomes a baseline expectation for security architects, not just for the one PKI engineer everyone defers to. That shift shows up directly in how advanced security certifications are structured now. Enterprise security architecture material, the kind covered in CompTIA's SecurityX certification, goes deep on cryptographic protocols, key management, and the kind of hybrid and crypto-agile design decisions that OMB's own migration guidance recommends agencies evaluate carefully given the added complexity they introduce.

That matters for career positioning too. A PQC migration lead role, the kind EO 14412 requires agencies to appoint within 30 days of the order, is going to need people who can speak fluently about both inventory tooling and cryptographic risk, not one or the other. If you're building out that case for yourself or your team, it helps to look at a curriculum overview that maps which topics map to which job tasks before you commit study time, and Forge University's resources page is a reasonable place to start that comparison.

For practitioners further down the stack, this also touches vulnerability management and asset discovery work more broadly. A CBOM is, at its core, an asset inventory problem with a cryptographic lens, and that discipline overlaps heavily with the asset and vulnerability management domains tested in more general security certifications. If cryptography has always felt like the part of your study plan you rushed through to get to the scored sections, this is the moment that calculus changes. You can start training on the cryptographic fundamentals now, well before your organization hands you a CBOM project with a deadline attached.

The timeline gives you room, if you use it now

The practical deadlines aren't as close as the 2030 migration dates make them sound, which is exactly why this is the moment to build capability rather than wait for pressure. CISA and NIST don't have to publish CBOM minimum elements until roughly March 2027, and no document currently sets a submission date for anyone outside the federal government to actually produce one. That gap is the opportunity. Organizations and individuals who build cryptographic inventory discipline now, before a formal standard forces the issue, will be the ones evaluating vendor claims and shaping internal policy instead of scrambling to retrofit a program once the guidance lands. The underlying skill, being able to look at a system and say with confidence exactly what cryptography is running inside it, isn't going away regardless of which document format eventually wins.

The quiet signal in all of this is that cryptography is moving from a specialist's corner of security work back into the mainstream job description. Anyone who treats it as optional reading is going to find that assumption expensive in about eighteen months.

Start training free at Forge University