Build a crypto inventory before choosing a post-quantum algorithm

Do not pick a post-quantum algorithm until you know where public-key cryptography lives in your estate. NIST released FIPS 203, 204 and 205 in August 2024 and says organisations should begin migrating now. The standards say what to move to. They say nothing about what you are running today, and finding that out is the slow part.

What the deadlines ask of you

NIST's project page says that under the transition timeline in NIST IR 8547, quantum-vulnerable algorithms will be deprecated and ultimately removed from its standards by 2035, with high-risk systems moving much earlier. The page for the draft of IR 8547 records that the final version replaced it on 27 October 2026. Our sources do not list the vulnerable standards or the earlier high-risk dates, so read those in NIST's own text.

The UK NCSC turns the timeline into milestones an IT team can budget against, in its guidance on PQC migration timelines:

The inventory feeds all three 2028 tasks. If it is thin, the other two are guesses.

What goes on the list

The target is anything that relies on asymmetric public-key cryptography, which the NCSC says quantum computers will be able to break. The NCSC's discovery section covers these areas:

• systems and services you operate, for internal users and for outsiders;
• products you make or use that have a cryptography, security, communications or data-processing function;
• software applications, and networking hardware such as routers, switches, gateways, VPNs and base stations;
• mobile devices, servers and workstations;
• IoT and ICS devices with a communications function, tokens issued to users, and devices and sensors installed in the field;
• the data you hold, its expected lifetime and its value to an adversary, and how it is protected in transit and at rest.

Certificates are not named in that list, though the NCSC has a separate section on enterprise PKI. Add public web certificates, internal CAs, client certificates and code-signing keys as their own rows; that is our judgement, not the NCSC's. Add managed providers too.

This is not a formal asset register. Record each system's nature, scale, version, patch level and dependencies; one row per system is enough.

Where inventories go wrong

Three places need a deliberate look, because none shows up in a certificate export or package list: keys hard-coded in application code or configuration, signing keys held in an HSM, and firmware in embedded and field devices, which you cannot update like a server. The NCSC flags long-lived hardware and infrequent replacement cycles as a constraint, and those devices are where it bites.

Listing it in a week

Start top-down, on core services and their interdependencies, then go bottom-up where that view runs out. A workable split for a small team:

1. Day one. List the key services and the data each handles, and mark data that must stay secret for years. Send the supplier email below the same day, since replies take longest.
2. Days two and three. Export certificate lists from every CA you run and ask each team that buys certificates for theirs. Add VPN and remote-access configurations. Collect SBOMs, lockfiles or package lists for software you build and run, and search them for cryptographic libraries and versions. Search repositories and configuration directories for committed private keys and certificates; every hit is a row, and a private key in a repository needs fixing anyway.
3. Day four. Run a TLS scanner against external and internal endpoints, and check the SSH host keys and VPN or IPsec proposals your gateways offer. Compare the results with your rows; scan output is a cross-check, not a substitute.
4. Day five. Merge, flag gaps, and write "unknown" where you could not confirm.

Supplier questions that fit in one email:

• Which of your products or services that we use rely on public-key cryptography, and which libraries and versions do they contain?
• What is your PQC migration plan, with dates?

The NCSC says to ensure managed providers carry out these assessments for the services they run for you. Asking in writing is our recommendation for how to do that.

Turning the list into a plan

For each row, choose one of the NCSC's strategies: in-place migration, re-platform, retire the service, run until end-of-life, or tolerate the risk. Systems with no public-key cryptography need no action.

Rank the rows by the lifetime and value of the data they protect, then by dependence on long-lived hardware.

Expect old and new to run side by side for a while. Prefer products with cryptographic agility, meaning they readily support alternative algorithm suites, and decide in advance when you will end traditional support.

Only then pick algorithms. NIST expects ML-KEM (FIPS 203) for key establishment, and ML-DSA (FIPS 204) and SLH-DSA (FIPS 205) for signatures, to be the foundation of most deployments. FIPS 203 carries a planning note about an issue to be corrected in a future revision, so check the errata before you implement from it. NIST is still standardising Falcon and HQC; its PQC project page is where to watch for changes.

For help with discovery, our consulting team runs assessments.

Where to start

1. Name an owner, book one week, and send the supplier email on day one.
2. Build one row per system: owner, purpose, where public-key cryptography is used, versions, dependencies, data lifetime, supplier, chosen strategy, target date.
3. Collect certificates, VPN configurations and SBOMs, then run the TLS, SSH and repository searches.
4. Check hard-coded keys, HSM-backed signing and embedded firmware by hand, and mark anything unconfirmed as "unknown".
5. Rank rows by data lifetime and hardware dependence, and give each an NCSC strategy and target date, so the sheet becomes your 2028 plan.
6. Read the final IR 8547 for high-risk deprecation dates and set internal dates earlier than 2035 where it requires.