Part II, Practitioner · Lesson 10
Cryptographic inventory: find it before you fix it
The short version
Before you can change all the locks in a building, you need a list of every door, window and cupboard that has one, including the ones nobody remembers. A cryptographic inventory is that list. Then you fix the doors guarding the most valuable things first.
You'll learn to
- Explain what a cryptographic inventory is and what each entry should record.
- Use several discovery methods (network, code, keys, vendors) and know what each one misses.
- Classify assets as quantum-vulnerable, fine, or needing a size check.
- Prioritize findings using data lifetime, harvest-now exposure and replacement lead time.
Every post-quantum plan starts with the same unglamorous step: finding out where you use cryptography. US federal agencies have been required to do it since 2023, the UK NCSC puts "full discovery" in its first milestone, and the EU roadmap starts there too. The reason is simple: you can't migrate what you can't find, and cryptography hides well.
What an inventory is
A cryptographic inventory is a record of where and how cryptography is used across your systems: which algorithms, which keys, protecting what, owned by whom. It isn't a list of certificates, though certificates are part of it. It also covers key exchange in protocols, encryption at rest, code signing, tokens, hardware security modules, embedded devices and the cryptography inside products you buy.
US OMB memo M-23-02 gives a useful template. For each system, agencies must report, among other things:
- each quantum-vulnerable algorithm in active use, the service it provides, and its key length;
- whether it's part of commercial, government or custom software, and the vendor;
- operating system and version, and where the system is hosted;
- how long the data needs protection: its time to live.
The memo also says something easy to overlook: a cryptographic system counts as "actively used" if it can be used during operation, even if it only runs to support legacy clients. Fallback settings count.
What to record
A workable inventory entry, whatever tool holds it, answers these questions:
| Field | Example | Why it matters |
|---|---|---|
| Asset and owner | Customer portal, web team | Someone has to fix it |
| Purpose | Key exchange, signature, encryption at rest, integrity | Decides urgency |
| Algorithm and size | ECDHE X25519; RSA-2048 certificate | Decides whether it's vulnerable |
| Implementation | OpenSSL 3.0 on a load balancer | Decides how it gets upgraded |
| Data lifetime | Medical records, 25 years | Drives harvest-now risk |
| Upgrade path | Vendor firmware, roadmap unknown | Drives lead time |
Industry is converging on machine-readable formats for this. CycloneDX version 1.6 (April 2024) added a Cryptography Bill of Materials (CBOM), which lists algorithms, keys, certificates and protocols as components in the same way a software bill of materials lists libraries. You don't need a CBOM to start, but asking vendors for one is a reasonable request.
How to find it
No single method sees everything. Combine several.
From the network
Scan your endpoints and observe traffic to see which TLS versions, key exchanges and certificates are actually negotiated. This is fast and finds things nobody documented, but it only sees what talks on the network, and only the outer layer.
From the code and builds
Search source code and dependencies for cryptographic libraries and calls, and use your software bill of materials to find bundled libraries such as OpenSSL versions. This finds hard-coded algorithm choices that network scans miss, the kind that make agility hard.
From the key stores
Certificate management systems, cloud key management services and hardware security modules (HSMs) know which keys exist, their algorithms and their expiry. Often this is the quickest high-quality source.
From the people and the paperwork
Some cryptography only shows up in a conversation: the partner file transfer set up years ago, the backup system's key wrapping, the smart cards in the badge readers. Vendor questionnaires cover products you can't inspect. Ask each supplier which algorithms their product uses and when it will support ML-KEM and ML-DSA.
The US Cybersecurity and Infrastructure Security Agency (CISA) published a strategy in 2024 for moving agencies toward automated cryptography discovery and inventory tools, while noting that the process still needs manual data collection alongside automation. Tools help; they don't finish the job.
Sort it: what's actually at risk
Once you have entries, classify them. The rule of thumb from the Foundations track does most of the work: public-key cryptography is quantum-vulnerable; symmetric cryptography and hashes mostly aren't. RSA, Diffie-Hellman, ECDH, ECDSA and Ed25519 all fall to Shor's algorithm. AES, SHA-2, SHA-3 and HMAC need at most a size check.
The traps are in the combinations. Try it on a hypothetical inventory:
Prioritize
An inventory usually produces more findings than anyone can fix at once. Three questions sort them.
1. Can it be harvested now?
Quantum-vulnerable key exchange or key transport protecting data in transit or at rest is exposed today. VPN tunnels, TLS between data centers, encrypted email and backups whose keys are wrapped with RSA all belong here. These go first.
2. How long must the data stay secret?
This is the X in Mosca's inequality. Health records, legal files, state secrets and long-term intellectual property can need protection for decades. Session cookies and one-time codes can't. OMB's inventory specifically targets data "expected to remain mission-sensitive in 2035".
3. How long will the fix take?
Anything with hardware in it (smart cards, HSMs, network appliances, embedded devices) or a long-lived trust anchor (root certificates, firmware signing keys) takes years to replace. Start those early even if the risk isn't immediate.
A simple scoring scheme works: rate each entry high, medium or low on all three questions and sort. The point isn't precision. It's making sure the long, hard jobs start first.
A worked example
Imagine a regional insurance company (hypothetical) that runs its first inventory. A network scan finds 140 TLS endpoints; the certificate manager lists 600 certificates; a code search finds four internal applications calling RSA directly; and interviews turn up a partner file-transfer link, a backup system and a fleet of branch-office VPN appliances.
Sorting by the three questions above:
- First: the VPN appliances and the partner file transfer (both key exchange carrying policyholder data with decades of retention), and the backups (AES data, RSA-wrapped keys, long retention).
- Second: the internal certificate authority and the smart cards used for staff login, which involve hardware and long-lived trust anchors.
- Third: public web TLS, which turns out to be mostly hybrid already because the CDN upgraded; the remaining work is the CDN-to-origin hop.
- Later: the four applications calling RSA directly, which get fixed as part of their next major release, with an abstraction layer added so the next change is cheaper.
Notice that the urgent items aren't the most numerous ones. Six hundred certificates feel like the big job, but they aren't where the harvest-now risk is.
Questions to ask every vendor
- Which cryptographic algorithms and key sizes does the product use, and where?
- Can the algorithms be configured, or are they fixed in code or hardware?
- When will the product support ML-KEM for key exchange and ML-DSA (or LMS/XMSS) for signatures?
- Will existing hardware get that support through an update, or does it need replacing?
- Can you provide a cryptography bill of materials?
Keep it alive
A one-off spreadsheet is out of date by the next release. Make the inventory part of normal processes:
- Add cryptography fields to architecture reviews and change requests.
- Re-scan on a schedule and diff the results.
- Require a crypto declaration (or CBOM) in procurement.
- Assign an owner for the inventory itself. OMB asked each agency to name a cryptographic inventory and migration lead within 30 days of the memo.
A living inventory is also the foundation of crypto-agility, the subject of the next lesson: when the next algorithm needs replacing, you'll know where it is in an afternoon, not a year.
Summary
- A cryptographic inventory records where cryptography is used, what algorithm and key size, for what purpose, owned by whom.
- Combine discovery methods: network scans, code and SBOMs, key stores and HSMs, and vendor questionnaires.
- Public-key algorithms (RSA, DH, ECDH, ECDSA, Ed25519) are quantum-vulnerable; AES, SHA-2 and HMAC mostly need only a size check.
- Watch for hybrids of risk, like AES-encrypted backups whose keys are wrapped with RSA.
- Prioritize by harvest-now exposure, data lifetime and replacement lead time.
- Keep the inventory alive through architecture reviews, scheduled scans and procurement requirements.
Questions
Get five of six right to mark the lesson complete. They also feed the final exam.
Sources
- OMB M-23-02: Migrating to Post-Quantum Cryptography (November 2022)
- CISA: Strategy for Migrating to Automated Post-Quantum Cryptography Discovery and Inventory Tools
- UK NCSC: Timelines for migration to post-quantum cryptography
- OWASP: CycloneDX v1.6 released, with Cryptographic Bill of Materials (April 2024)
- OpenSSH 10.0 release notes
- European Commission: Post-quantum cryptography policy page
