Crypto Inventory Before Cryptography Change: A Practical Post-Quantum Migration Start

Most organisations that say they have started post-quantum planning have actually started reading about it. The gap between reading and doing is almost always the same gap: nobody can produce a list of where cryptography is used, which algorithms are in play, and which of those uses will still be alive when a cryptographically relevant quantum computer arrives.

Migration standards have moved faster than most internal programmes. NIST finalised the first post-quantum standards in August 2024: FIPS 203 (ML-KEM, derived from CRYSTALS-Kyber), FIPS 204 (ML-DSA, derived from CRYSTALS-Dilithium) and FIPS 205 (SLH-DSA, derived from SPHINCS+). FIPS 206 (FN-DSA, derived from FALCON) remains in development. Those documents tell you what to deploy. They do not tell you what you currently have.

Why the inventory is the hard part

Cryptography is rarely a single component. In a typical enterprise it appears in at least seven places:

TLS termination on load balancers, reverse proxies and API gateways
Application-level signing and encryption inside service code
Database column encryption and key management
Code signing and artefact signing in the build pipeline
VPN, SSH and device-management tunnels
Hardware security modules, smart cards and TPM-backed key storage
Long-lived data at rest, including backups and archives

The last item drives the timeline. A migration deadline is not set by when quantum computers arrive; it is set by when the data being protected stops needing protection. Data with a fifteen-year confidentiality requirement is already inside the harvest-now-decrypt-later window if it is protected only by classical key exchange.

A workable first pass

A crypto inventory does not need to be complete to be useful. It needs to be structured, repeatable and owned. A first pass that a small team can finish in weeks rather than quarters usually looks like this:

Enumerate externally reachable endpoints. Every TLS endpoint that terminates a connection from outside the network is a candidate for hybrid key exchange. Record the negotiated key exchange group, the certificate signature algorithm and the TLS version actually in use, not the version the configuration intends.
Enumerate internal trust anchors. Certificate authorities, internal PKI hierarchies, code-signing keys and root stores. These change slowly and break widely, so they need the longest lead time.
Enumerate long-lived data stores. For each, record the retention period and the encryption algorithm protecting it. Retention period is the field that determines urgency.
Enumerate protocol dependencies. SSH, IPsec, S/MIME, DNSSEC and anything with a hard-coded algorithm list. These are the places where a library upgrade is not enough.
Record the owner. An inventory row without an accountable team is a row that will not be migrated.

What to record per finding

A useful record is short. For each cryptographic use, capture:

Location: host, service, or repository path
Purpose: confidentiality, integrity, authentication, or key establishment
Algorithm and parameter set currently in use
Library and version providing it
Whether the algorithm is negotiated or hard-coded
Data lifetime or session lifetime
Migration owner

The distinction between negotiated and hard-coded matters more than any other field. Negotiated algorithms can often be upgraded by changing a configuration or a library version. Hard-coded algorithms require a code change and a release, which is a fundamentally different project.

Where the standards fit

Once the inventory exists, the mapping to standards becomes mechanical. ML-KEM (FIPS 203) replaces key establishment; ML-DSA (FIPS 204) replaces digital signatures where performance matters; SLH-DSA (FIPS 205) covers signatures where conservative security assumptions matter more than speed or signature size. Hybrid deployments, where a classical algorithm runs alongside a post-quantum one, are the common transitional pattern because they preserve security if either algorithm is later broken.

Two practical constraints shape sequencing. First, post-quantum signature and ciphertext sizes are larger than their classical equivalents, which affects certificate chains, TLS handshake sizes and any protocol with a fixed-size field. Second, some environments cannot be changed at all: embedded devices, long-lived industrial controllers and third-party appliances with no update path. Those need to be identified early because the mitigation is usually architectural, not cryptographic.

Common failure modes

Three patterns show up repeatedly in migration programmes that stall.

Treating the inventory as a scanning project. Scanners find TLS endpoints. They do not find application-level signing, hard-coded keys, or data-at-rest encryption. A scanner output is an input to the inventory, not the inventory.

Deferring because the timeline is uncertain. The uncertainty is about the deadline for quantum computers, not about the deadline for data with a long confidentiality requirement. Those are different clocks.

Starting with the hardest system. The first migration should be a system with a known owner, a modern library and a short change cycle. It produces the process that the harder systems will need.

A realistic sequence

A defensible order of work is: inventory first, then hybrid key exchange on externally reachable TLS, then internal PKI and code signing, then application-level cryptography, then the systems that cannot be changed at all. Each step produces information that makes the next one cheaper.

The inventory is the step that most organisations skip, and it is the step that determines whether the rest of the programme is a plan or a wish. It does not require new tooling. It requires deciding what to record, who owns each row, and accepting that the first version will be incomplete.