Every post-quantum programme starts with the same question, and it is not which algorithm to deploy. It is which cryptography you already have, where it runs, who owns the key, and what breaks when the algorithm changes. Until that list exists, a migration plan is a schedule for work nobody has scoped.
That is why the inventory comes first. It is also why so many inventories fail: they are produced once, by hand, for a steering committee, and they are out of date before the first migration wave begins.
The schedule now makes the inventory unavoidable
NIST published IR 8547, Transition to Post-Quantum Cryptography Standards, as a final report on 27 October 2026. Quantum-vulnerable public-key algorithms are deprecated after 2030 and disallowed under NIST standards after 2035. The report is explicit that this window does not move the earlier federal deadlines: key establishment by 31 December 2030 and signatures by 31 December 2031 for high value assets.
The obligation to know your own estate is older than that report. National Security Memorandum 10 and OMB M-23-02 both put cryptographic inventory ahead of migration. IR 8547 simply gives the inventory a deadline it can no longer be deferred past.
A deprecation date is not a switch that flips. It is the point after which an asset you have not enumerated becomes an unmanaged exception, and exceptions are what auditors ask about first.
What a CBOM actually contains
A cryptographic bill of materials describes the cryptographic assets in a system: algorithms, keys, certificates, and their relationships to the software components that use them. That definition comes from CycloneDX, which introduced the capability in version 1.6 on 9 April 2024. The format was developed by IBM Research and is now part of the CycloneDX specification maintained through Ecma Technical Committee 54.
The distinction from an SBOM matters. A software bill of materials tells you which components are present. A CBOM tells you which cryptography those components rely on, so that a deprecated algorithm or an expired certificate becomes a finding rather than a surprise during an incident.
Where the one-off inventory fails
Most CBOM programmes fail in the same four ways, and none of them is about the file format.
- Drift. The spreadsheet is correct on the day it is signed and wrong the next time a service is deployed. Nobody owns the refresh.
- No provenance. A row says an asset uses RSA-2048. It does not say which scanner produced that, at which version, over which scope, or when.
- No re-run. The next audit cannot reproduce the result, so the only defence is that the previous document existed.
- No scope boundary. The inventory does not say what it did not cover, so its silence is read as completeness.
What re-runnable means in practice
An inventory is evidence only if a second party can produce the same result from the same inputs. That requires more than a scanner. It requires stable asset identity across scans, a recorded scope, a scanner version, and a signed output that can be verified later.
Stable identity is the hard part. The same key appears in a code repository, a KMS, a certificate and a TLS endpoint. An inventory that creates four unrelated assets has described the tooling, not the estate. Normalising those into one asset with several observations is what makes the inventory usable for planning a migration wave.
Signature and provenance are the second half. If the findings are uploaded by a scoped identity and signed, an auditor can verify that the evidence came from a specific scanner acting within a specific tenant, rather than from a spreadsheet someone edited.
How QNSI produces one
QNSI treats discovery as a continuous input rather than a project. The CLI scans a repository locally for classical, PQC and hybrid cryptography usage, emits JSON or a local CBOM, and uploads signed findings through a scoped scanner identity. Source code stays in the customer environment; only normalised findings leave it.
Uploaded findings enter Crypto Inventory as code repository and code usage assets, and flow into discovery runs, posture, CBOM and audit evidence. Discovery covers 11 cloud-vendor connector families and 36 normalised inventory source types, all derived from the implementing source rather than from a marketing list.
The product reports 90 post-quantum algorithms across 14 families, with 27 key encapsulation mechanisms and 63 signature schemes, and publishes ACVP conformance evidence at /verify/conformance. Those numbers are the product's own published claims; the inventory is what tells you which of them your estate actually needs.
A first week that produces something usable
This sequence is deliberately unambitious. It produces a scoped, reproducible inventory instead of a comprehensive one that nobody trusts.
- Pick one system with a real deadline attached, not the whole estate. A payment path or an internet-facing endpoint is a better start than a data centre.
- Scan the source repositories that build it. Code-level discovery finds algorithm usage that infrastructure scanning cannot see.
- Add the key and certificate sources: KMS, HSM, certificate stores, TLS endpoints. Record which connector produced each finding.
- Reconcile duplicates into single assets with multiple observations. Decide who owns each asset before the list grows.
- Record the scope explicitly: what was scanned, what was not, and why. The gaps are part of the evidence.
- Schedule the re-run now, while the first result is fresh. An inventory with no refresh date is already history.
What a CBOM does not prove
It does not prove the absence of weak cryptography. Coverage depends on the connectors and repositories in scope, and a system that was never scanned cannot appear in the results.
It does not prove hardware qualification. Where a named HSM or cryptographic module is involved, qualification is provider, configuration and deployment specific, and a CBOM entry is not a certification.
And it does not decide the migration order. The inventory tells you what exists; prioritisation still depends on data lifetime, exposure and the deadlines that actually bind your organisation.
Start with the list you can defend
The useful question is not whether your CBOM is complete. It is whether the next auditor, engineer or regulator can re-run it and get the same answer. An inventory that survives that test is worth more than a larger one that does not.
If you want to see what the output looks like against your own repositories, the CLI is published with the SDK and the Free Forever tier includes Crypto Inventory. Bring a CBOM to a migration conversation and the scoping argument mostly settles itself.