What belongs in a cryptographic inventory — and how to discover it
A cryptographic inventory maps every algorithm, key, certificate, protocol, and library you run, plus where each is used and what it protects. This is what to capture and the discovery methods that find it all.
You cannot migrate what you cannot see
A cryptographic inventory records every cryptographic asset — algorithms and parameters, keys and certificates, protocols, libraries and versions, and key stores — together with where each is used and what data it protects. It is the mandatory first phase of migration, and no single discovery method finds everything: combine source scanning, network scanning, certificate discovery, configuration analysis, and key-store review.
Every migration begins with the same uncomfortable question: where, exactly, is your quantum-vulnerable cryptography? Most organizations cannot answer it. The inventory is the artifact that turns that fog into a map. Its value is not the list of algorithms — it is the pairing of each algorithm with its context, because the same RSA key exchange is low-risk on an ephemeral internal session and a serious exposure in front of decades-sensitive records.
What to capture
- **Algorithms and parameters** — cipher suites, key-exchange and signature algorithms, key lengths, curves, and modes of operation.
- **Keys and certificates** — issuers, key sizes, expiry, and where private material actually lives.
- **Protocols and versions** — TLS, SSH, IPsec/VPN, and their negotiated versions and configurations.
- **Libraries and versions** — OpenSSL, BoringSSL, language runtimes, and the crypto pulled in transitively.
- **Key stores and HSMs** — hardware and software stores, and what they gate.
- **Usage and data context** — which system uses each asset and the shelf life of the data it protects.
That final item is what separates an inventory from a scan. Without it you can list your crypto but you cannot rank it, and ranking is the entire point of the next phase.
Discovery methods — use several
No single technique sees everything, so a credible inventory is assembled from complementary methods:
- **Source and dependency scanning** — static analysis of code and build manifests for cryptographic calls and imports; catches code-signing keys and library crypto that never appears on a network port.
- **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 configuration for the crypto it actually enables (as opposed to what is compiled in).
- **HSM and key-store review** — cataloguing hardware and software key stores and what each protects.
An inventory with unknown coverage manufactures false confidence
The dangerous failure is not the asset you found and mis-scored — it is the estate you never scanned. Shadow IT, vendor appliances, and embedded firmware crypto silently fall outside network and source scans. Track coverage explicitly and treat unscanned estate as unknown-risk, not zero-risk. An inventory that claims completeness it has not earned is worse than one that honestly flags its gaps.
Make it continuous, not a snapshot
A spreadsheet is obsolete the moment a new service ships. The output of discovery should consolidate into a machine-readable CBOM that is regenerated in CI, so the inventory is a living artifact rather than something reconstructed from scratch each audit cycle. This is also what lets the inventory feed the roadmap automatically: a newly discovered vulnerable asset becomes an unscheduled migration item without anyone re-typing it.