What is a cryptographic inventory (CBOM) — and why is it step 1 for every regulator?

As of November 4, 2026, every major government framework for the post-quantum migration published since 2022 puts the same first step in writing: an inventory of where your cryptography lives. Five of five — OMB M-23-02 (2022-11-18), the CISA/NSA/NIST quantum-readiness factsheet (2023-08-21), the UK NCSC migration timelines (2025-03-20, full discovery by 2028), the EU coordinated roadmap (2025-06-23, inventories by 2026-12-31) and OMB M-26-15 (2026-06-24) — ask you to count before you buy. A CBOM — cryptographic bill of materials — is the machine-readable format for that inventory, an open standard since CycloneDX v1.6 (OWASP, 2024-04-09). The pressure behind it is dated mandates and data lifetimes, not attacks: the public record Rosetta Quantum tracks still shows 0 RSA-2048 keys broken by a quantum computer and 0 breaches attributed to a quantum attack, both re-verified 2026-11-04.

What is a cryptographic inventory — and what exactly is a CBOM?

A cryptographic inventory is a structured record of where cryptography is used across your estate: which algorithms and key lengths, in which protocols, libraries, certificates, devices and services, protecting which data, with which dependencies. The EU roadmap defines it in one line: "a structured overview of cryptographic assets" (EU NIS Cooperation Group, 2025-06-23). The UK's NCSC is explicit that this is not a formal asset register for its own sake — the discovery exercise should capture scale, version information, patch levels and the dependencies between components (NCSC, 2025-03-20).

A CBOM — cryptographic bill of materials — is the machine-readable version. It was developed by IBM Research and shipped as part of CycloneDX v1.6, an OWASP project, on 2024-04-09; Ecma TC54 took the format into international standardization. IBM's Michael Osborne calls it "the first open standard to describe an organizations' cryptographic assets inventory, and their dependencies" (OWASP, 2024-04-09). The stated motivation in the release is exactly this migration: identifying weak algorithms and laying "the groundwork for migration to quantum-safe systems and applications".

If you want to know what fields a real inventory carries, the most concrete public template is the one OMB imposed on US federal agencies in M-23-02 (2022-11-18). Each CRQC-vulnerable system entry must include: the algorithm, service and key length; the FIPS 199 impact category (Low/Moderate/High); the lifecycle of the data in the system — how long data and metadata need protection, the "time to live"; the FISMA system identifier; the high-value-asset identifier where applicable; software vendor details; operating system; hosting arrangement; and notes. Nine data items per system, submitted first by 2023-05-04 and annually thereafter until 2035 (OMB M-23-02).

Which frameworks ask for the inventory first — and when did each say so?

Five of five major frameworks published between 2022 and 2026, in three jurisdictions, put the inventory as the first technical step — and each one is dated:

The logic is arithmetic, not bureaucratic. The Mosca inequality — if your data's required secrecy lifetime (x) plus your migration time (y) exceeds the time to a cryptographically relevant quantum computer (z), you will have a gap — cannot even be evaluated without knowing where the vulnerable cryptography is and what data it protects. Rosetta covered the full worked inequality in the harvest-now-decrypt-later piece; the US executive order's own deadlines are in the EO 14412 letter-chica piece. The inventory is the x and part of the y of that inequality, written down.

One more date will matter: under EO 14412 §5(d), CISA and NIST will have to publish guidance on the minimum elements of a CBOM by approximately 2027-03-19 (date calculated from the order's 270-day clock; marked ≈ because the order states the interval, not the calendar date). When that guide will land, "what goes in a CBOM" will stop being a vendor conversation and will become a checklist with a federal seal.

Can a tool build the inventory for you?

Not on its own — and the most honest statement of that limit comes from the agency promoting the tools. CISA's Strategy for Migrating to Automated PQC Discovery and Inventory Tools (2024-08-15) examined the nine inventory data items of M-23-02 against what automated cryptographic discovery and inventory (ACDI) tools can do, and found that only three of the nine — algorithm, service and key length; software package details; operating system — "may be collected" by ACDI tools or the federal CDM program. Most of the rest — FIPS 199 category, data lifecycle, hosting model, system identifiers — "cannot be detected or collected using currently available automated tools" (CISA, 2024-08-15).

The same document flags the harder residue: software with embedded cryptography, customized applications and certain operating systems "may not be discoverable using automated tools", and CISA had not confirmed whether tools can detect algorithms inside custom or government-developed software. The 2023 factsheet's answer to that gap is procedural, not technical: ask every vendor for a list of the embedded cryptography in their products (CISA/NSA/NIST, 2023-08-21).

The decision frame for a security leader: ACDI tools accelerate the discovery of cryptography in transit and at rest — network, file-system, database and software-package scans. What they will not tell you is what the data is worth, how long it must stay secret, or who owns the system. Those columns are filled by people. A tool purchase is not an inventory; by CISA's own count, it is at most three columns out of nine.

What does the public record measure today?

The migration is real and measurable, and the inventory practice lags it. On the measured side: ≈70% of browser-generated HTTPS traffic on Cloudflare's network already negotiates post-quantum key agreement, and ≈15% of scanned origin servers support it (Cloudflare, 2026-09-29). On the same measured side sit the zeros that Rosetta re-verifies every run: 0 RSA-2048 keys broken by a quantum computer and 0 public breaches attributed to a quantum attack (documentary review, 2026-11-04); the public factoring record remains classical — RSA-896, by GNFS on GPUs (S. Weis, 2026-09-19).

Against that, the only published audit of inventory practice at scale: GAO's public report GAO-27-108740 (October 2026) found that none of the 24 selected US federal agencies fully addressed the three preparation practices GAO assessed — this, four years after M-23-02 made inventories mandatory — and its recommendation is verbatim about this post's subject: agencies should "establish and implement processes to develop inventories of vulnerable cryptography". GAO issued 89 recommendations to 23 agencies (GAO, October 2026; audit data as of September 2025, its own declared limit).

The board this engine maintains, with the latest dated reading per indicator:

What does a security leader do with this?

Four moves, all of them cheap relative to what they inform. First, do not design the spreadsheet from scratch: the nine fields of M-23-02 are a free, field-tested template for any organization, not just US agencies — algorithm, service, key length, impact category, data time-to-live, system identifier, vendor, OS, hosting. Second, prioritize by data lifetime, not by system count: the inequality that converts your inventory into a calendar needs the "time to live" column first, because data that must stay secret into the 2030s will be the first place where x + y will exceed anyone's z. Third, send the vendor letters now — the CISA/NSA/NIST factsheet tells you to ask suppliers for the embedded cryptography their products carry, which is the part no scanner will find for you. Fourth, put the dated deliverables in your calendar: EU First Steps 2026-12-31, the CISA+NIST CBOM minimum-elements guide ≈2027-03-19, NCSC discovery 2028, NIST deprecation 2030 and disallowance 2035.

For the clock on the other side of the inequality: the house's own Q-Day estimate — RQ-PRED-QDAY-001, floor 2031, window 2033–2039 — is a sealed, refutable judgment, not a measurement, and the full reasoning is public. Note what the table above already shows: several regulatory deadlines (2028, 2030, 2030-12-31) will arrive at or before that judgment's floor. Whoever waits for a broken key to start counting will have skipped the only step every framework agrees on.

What we don't know

What the CISA+NIST CBOM minimum-elements guide will require — the ≈2027-03-19 date is calculated from EO 14412's 270-day interval and could slip; the content is not drafted in public. What GAO's three assessed practices are, verbatim — the public highlights name the framework but do not enumerate the practices; the full sensitive report (September 2025) is not public. How many of the M-26-15 migration plans due 2026-10-22 were actually submitted — no public tally existed at our 2026-11-04 scan, and the memo itself does not require one. How mature ACDI tools actually are — CISA describes them as "in various stages of development across industry" and we found no neutral, methodology-declared benchmark of discovery coverage. How many private-sector organizations hold a cryptographic inventory today — we found no survey with declared methodology (n, dates, funder) worth citing. Whether EU member states will hit the 2026-12-31 First Steps milestone — the NIS CG ran a survey (2025-08-11 to 2025-09-29) and published feedback on 2026-09-02, but no per-state compliance table.

Rosetta Quantum publishes verdicts with raw, reproducible data. This is educational content, not security or legal advice and not a product claim; Rosetta recommends no vendor. The future appears here only in future tense.