When NIST published FIPS 203, 204 and 205 in August 2024, the algorithm question stalling post-quantum planning got an answer. The maths is done. So why is so little shipping? DigiCert’s latest outlook found 87% of organisations planning, testing or implementing post-quantum cryptography, while fewer than 7% have deployed quantum-safe or hybrid certificates at meaningful scale.
The pressure is now formal. OMB Memorandum M-26-15 makes a cryptographic inventory a filed deliverable within 120 days, and the ASD’s guidance presumes one exists by the end of 2026. IBM’s readiness index puts the average at 28 out of 100. Deadlines alone are not producing inventories. If the maths is settled, what has replaced it as the bottleneck? The answer sits in two operational properties: naming what you have, and changing it.
What is a cryptographic inventory, and what belongs in a first one you can finish?
A cryptographic inventory records every algorithm, key, certificate and protocol in use, and where each is used. It is not a list of certificates. Each entry maps a business system to its algorithm, key length, protocol version, provider, owner and expiry, and that mapping is what a migration sequence is built from.
The definition
The certificate-list mistake is worth naming. Certificates alone are not an inventory. Microsoft’s guidance is direct: you can’t protect or migrate what you can’t see. A certificate register tells you what expires, not that a service negotiates TLS 1.2 with an RSA-2048 certificate from an internal CA, or that a compiled-in library is doing the key exchange.
This is why every roadmap starts here: you cannot migrate an asset you cannot name, and you cannot defend a plan that says “roughly 400 services, we think.” The 120-day filing turns this into a deadline, and the ASD’s end-2026 transition plan presumes you can produce the list. Those are the deadlines that actually bind Australian organisations.
CBOM vs SBOM: what each answers
A cryptographic bill of materials, or CBOM, is where this mapping gets a machine-readable home. CycloneDX, ratified as ECMA-424, made the CBOM a standard shape rather than a spreadsheet. An SBOM tells you what components and versions are in a build; a CBOM tells you what cryptography is in use, where, and under whose control. Same format family, same supply-chain logic, different questions.
The minimum viable CBOM
The trap is treating a complete inventory as a prerequisite for action. The US government had a statutory deadline in 2023, yet its audit found only one agency in 24 with a complete inventory of its priority systems. Teams that insist on finishing first stall, or submit whatever their owners can type. Scope the first pass to what you can enumerate in weeks: internet-facing endpoints, identity and certificate authorities, key stores and HSMs, data stores with encryption at rest, and signing pipelines. Record a confidence level against every entry and assign an owner on your team, then widen it. A finished, imperfect inventory beats an aspirational complete one, because the deadline rewards a filed artefact. When you list those algorithms, this is what you will find.
Why your scanner won’t produce it
Vulnerability scanners find known-bad versions and exposed services; they don’t see which library is statically linked or which key is wrapped where. Keyfactor is explicit that threat and vulnerability tools were never designed to build this. Automated discovery supplies raw findings that still have to be turned into the mapping.
What does cryptographic agility mean, and should you build it or buy it?
Cryptographic agility is the ability to change an algorithm, primitive or provider without re-architecting the system. Measure it by elapsed time and change cost: time-to-swap. A system that needs a code change, a certificate reissue, a hardware refresh and a change-board negotiation is slow to swap, and that is the measure that matters.
Agility is time-to-swap
You can run the test on one system. Pick a service, decide on a primitive change, and time the whole path: code or configuration change, testing, certificate reissue, hardware lead time, change approval, production cutover. NIST’s agility guidance explains why the number stays high: the absence of abstraction between cryptographic operations and core system logic is what hampers agility. Cloudflare’s version of the target state: agility means the upgrade is a configuration change, not a re-architecture.
Where agility is won or lost
Time-to-swap stretches to weeks or months when cryptography is hidden in application code, hard-coded, or pinned. It stretches further when TLS termination sits in a single appliance, or when key material and roots of trust live in one HSM. The fixes sit at a provider boundary like OpenSSL 3.x or Java’s JCA, where a swap becomes a policy decision. For systems you cannot modify before the deadline, a crypto gateway, a bump-in-the-wire that terminates and re-establishes cryptography, is the fallback. It is not free: it concentrates traffic and must itself be inventoried.
Build or buy: which failure you can tolerate
The build-versus-buy question comes down to which failure you can tolerate. Buying a discovery platform gets you coverage and a CBOM export quickly, a commercial tool can surface outdated protocols and weak key strengths within hours, but you import the vendor’s asset model and still need evidence for embedded and vendor cryptography. Building gets fidelity to your architecture but usually stalls at the long tail of OT, embedded and legacy systems. The choice is an incomplete inventory delivered against a deadline, or a complete one delivered after the transition has started.
Why the readiness gap is an agility problem
This is where the gap shows up in the numbers. That 87% versus 7% split is what happens when you buy tools before deciding what you are migrating, and in what order. Ordering systems by the shelf life of the data they protect only helps if you can act on that order, which is what agility provides. Agility converts a plan into a sequence, and the migration plan into something executable and fundable.
The maths was settled first; the inventory and the swap are what remain. FIPS 203, 204 and 205 are published, yet most organisations can neither name their cryptography nor change it cheaply. A minimum viable CBOM turns vague estimates into a scoped, confidence-graded inventory you can file, and time-to-swap turns “we’re planning migration” into a number a board can hold someone to.
The sequence that produces readiness for your business is: name it first with a scoped CBOM, make it movable by measuring time-to-swap, then choose the failure you can tolerate. That sequence is what turns a roadmap into a deadline you can meet.
Frequently Asked Questions
Is a cryptographic inventory the same thing as a data classification exercise?
No. A data classification exercise asks how sensitive your information is; a cryptographic inventory asks which systems hold it and what cryptography protects it. They are different axes, and they become useful together: classification tells you which systems to migrate first, while the inventory tells you what to change and who owns it. Run them as separate workstreams that exchange answers, not as one combined project.
How long should a first cryptographic inventory take?
Weeks, not quarters, if you scope it to the minimum viable CBOM rather than a complete census. Pick the five or six categories you can enumerate now, assign an owner to each entry and record a confidence level, then publish. A first pass that covers your internet-facing estate and key management honestly is worth more than a perfect inventory that arrives after the filing date.
What happens if we cannot get information about a legacy system?
Record it as an explicit unknown with a low confidence rating and a named owner. An entry that says “cryptography unknown, no vendor contact, assumed RSA-2048” is a finding, not a failure, and it is far more defensible than leaving the system out. The gap then becomes a work item you can fund, staff or route around, rather than a surprise discovered mid-migration.
Do we really have to inventory cryptography that our cloud provider manages?
Yes, though the boundary differs. Under the shared responsibility model the provider secures the managed service internals, but you still own the configuration, the keys you bring, the certificates you issue and every integration that touches them. Record what the provider asserts, what you control and where the handover sits. An inventory that stops at the provider’s edge cannot tell you which workloads would break in a swap.
Is TLS 1.3 enough to make us post-quantum ready?
No. TLS 1.3 is a protocol version, not a quantum-safe guarantee, and many deployments still negotiate a classical key exchange inside it. Readiness depends on the group and the certificate in use, which is why hybrid key exchange such as X25519MLKEM768 is already appearing in browser traffic. The inventory has to record negotiated parameters, not just the protocol version on the configuration page.
How do we measure time-to-swap without migrating anything yet?
Rehearse it on one representative system. Take a single service, decide on a primitive change, and time the whole path: code or configuration change, testing, certificate reissue, hardware lead time, change approval and production cutover. The elapsed total is your time-to-swap. Do it for three systems and you have a distribution a board can reason about, which beats asking teams whether they feel agile.
Can we use our existing SBOM tooling to produce a CBOM?
Only partly. SBOM tooling is good at listing libraries and versions and often shares the CycloneDX format, so exports can be extended, but it cannot see negotiated cipher suites, key custody, certificate chains or ownership. Treat it as one input. The CBOM still needs configuration data, key store records and a named owner for each system, which is exactly the work scanners and build pipelines leave undone.
What is a crypto gateway, and when is it the right answer?
A crypto gateway is a bump-in-the-wire device or service that terminates and re-establishes cryptography on behalf of a system you cannot modify, such as a packaged appliance, a mainframe or a vendor product. It is the right answer when the source cannot be changed before the deadline. It is not free: it concentrates traffic, becomes a high-value target and must itself be inventoried.
Do systems that hold no sensitive data still need to be inventoried?
Yes, though their priority is lower. Signing keys, identity providers, build pipelines and monitoring agents rarely hold customer records, but compromising them compromises everything downstream, and their cryptography still has to change. Record them with the same fields and a lower migration priority, so the inventory answers “what would break our trust chain” as well as “what would expose our data”.
How should the inventory change the order in which we migrate?
It should replace instinct with a sequence. Pair every system with the shelf life of the data it protects: anything retained longer than the time to a cryptographically relevant quantum computer goes first, because archived traffic can be decrypted later. After that, prioritise long-lived signatures and identity, then the rest. That ordering is the point of the exercise, and agility is what lets you execute it.
Is post-quantum readiness now mostly a compliance problem?
Not really. Compliance asks for an artefact by a date; readiness asks whether the estate can actually change. Mandates such as OMB M-26-15 make the inventory a filed deliverable, which is useful pressure, but IBM’s average readiness score of 25 out of 100 shows that deadlines alone do not produce visibility or flexibility. Treat the filing as the minimum output and the migration sequence as the real deliverable.
Will post-quantum algorithms slow our systems down?
Rarely in compute, often in bytes. ML-KEM and ML-DSA are fast enough for most workloads, but their keys, ciphertexts and signatures are larger, which shows up in handshake size, bandwidth and the constrained corners of embedded and industrial systems. Measure on representative traffic rather than assuming, and let the numbers decide where hybrid or gateway approaches earn their place.
