Read this first
A cryptographic inventory maps every cryptographic asset you run — algorithms and key lengths, certificates, protocols, libraries and their versions, HSMs and keystores — and, crucially, where each is used and what data it protects. It is the mandatory first step of any post-quantum migration, because you cannot prioritize or replace what you cannot see. Build it as a continuous, machine-readable CBOM, not a one-off spreadsheet, and feed it straight into your migration roadmap.
Every post-quantum migration plan begins with the same uncomfortable question: where is your vulnerable cryptography, exactly? Most organizations cannot answer it. RSA and elliptic-curve keys are embedded in TLS terminators, VPN concentrators, code-signing pipelines, database drivers, IoT firmware, and third-party libraries that nobody has looked at in years. A cryptographic inventory is the artifact that turns that fog into a map — and without it, the rest of the migration is guesswork.
What a cryptographic inventory actually contains
An inventory is more than a list of algorithms. To be useful for migration planning it has to capture both the cryptographic asset and its context — because the same algorithm can be low-risk in one place and a serious exposure in another. A complete inventory records:
- **Algorithms and parameters** — cipher suites, key-exchange and signature algorithms, key lengths, and modes of operation.
- **Keys, certificates, and their lifecycles** — issuers, expiry, key sizes, and where the private material lives.
- **Protocols** — TLS, SSH, VPN/IPsec, and their negotiated versions and configurations.
- **Libraries and versions** — OpenSSL, BoringSSL, language runtimes, and the crypto they pull in transitively.
- **HSMs and keystores** — hardware and software key stores, and what they gate.
- **Usage and data context** — which system uses each asset and what data it protects, so you can reason about that data's shelf life.
That last item is what separates an inventory from a scan. Knowing a service still negotiates RSA key exchange matters far more if it protects data with a decades-long confidentiality lifetime — the shelf-life reasoning at the heart of harvest-now-decrypt-later.
Why it is the mandatory first step
The inventory is not optional governance paperwork — it is a prerequisite that policy and standards now assume you already have. In the US federal space, the federal inventory mandate (OMB M-23-02) directs agencies to compile and maintain prioritized inventories of quantum-vulnerable systems. More broadly, ISO 27001 A.8.24 frames cryptography as something an organization must govern deliberately, which is impossible without knowing what you run. The practical logic is simpler still: you cannot prioritize or migrate what you cannot see.
How to build one
A credible inventory is assembled from several complementary discovery methods, because no single technique sees everything:
- **Source-code and dependency scanning** — static analysis of code and build manifests for crypto calls; findings are naturally emitted as SARIF so they land in the same pipeline as your other security results.
- **Network and TLS scanning** — probing live endpoints for negotiated protocols, cipher suites, and certificate chains.
- **Certificate and key-store discovery** — enumerating certificates, key sizes, and expiry across CAs, load balancers, and secret stores.
- **Configuration analysis** — reading server, VPN, and application configs for the crypto they actually enable.
- **HSM and keystore review** — cataloguing hardware and software key stores and what they protect.
The output of all of this should be consolidated into a machine-readable CBOM — a cryptography bill of materials expressed in CycloneDX. A CBOM is diffable, queryable, and versionable, which is what lets the inventory be maintained continuously rather than reconstructed from scratch each audit cycle.
A point-in-time spreadsheet rots the day it is finished
The two failure modes are stale coverage and false confidence. A spreadsheet is obsolete the moment a new service ships, so the inventory must be continuous — CI-integrated and CBOM-based, updated on every build. Worse is a gap you don't know about: an inventory that silently misses shadow IT, vendor appliances, or embedded firmware crypto is arguably more dangerous than none, because it manufactures confidence you haven't earned. Track coverage explicitly, and treat unscanned estate as unknown-risk, not zero-risk.
What the inventory feeds
The inventory is a means, not an end. Its output drives the migration roadmap: every discovered asset is scored by the shelf life of the data it protects and by policy deadlines — CNSA 2.0's timelines and the migration windows in NIST IR 8547 — and sequenced accordingly. Long-lived secrets behind quantum-vulnerable key exchange rise to the top; short-lived, low-value sessions wait. That prioritization is only possible once the inventory exists.
How quantakrypto helps
We run the inventory as an engineering exercise, not a questionnaire. Our audit combines source, network, certificate, and keystore discovery into a single CBOM that we hand back queryable and CI-ready, so it stays current after we leave. From there we translate findings into a prioritized migration plan sequenced by data shelf life and policy deadlines. Start with the inventory — every downstream decision depends on the map it produces.