The post-quantum cryptography standards are finished. Nobody has the inventory.
Standardising cryptography was the easy half; finding every place the old cryptography still runs is the part with no shortcut.
In August 2024 NIST published its first three post-quantum cryptography standards, FIPS 203 for key establishment and FIPS 204 and FIPS 205 for digital signatures.
The transition plan behind them, NIST IR 8547, describes how quantum vulnerable algorithms will be deprecated and eventually removed from those standards by 2035, with the systems carrying the most risk moving much earlier.
The NIST post-quantum project is direct about the other direction too, saying the new standards can and should be put into use now.
IR 8547 is still an initial public draft and the comments it attracted are published, which is a fair reminder that the timeline is a plan rather than a settled rule.
If the mechanics matter more than the schedule, the quantum computing concepts check is a short way to get the vocabulary straight.
Post-quantum cryptography migration is not blocked by mathematics; it is blocked by the fact that most organisations cannot say where cryptography runs, who owns it, or how long the data behind it has to stay secret.
That gap has teeth because encrypted traffic and files captured today can be decrypted later, which means the clock started when the data was recorded, not when a quantum computer arrives.
Nobody credible will name the year RSA breaks, and that uncertainty is the point: you plan against how long your secrets must stay secret, not against an attack date.
The 2035 date is a standards milestone. Your date is roughly the year your longest lived secret stops needing to be secret, minus the years it takes to find and change every system holding it.
Why post-quantum cryptography migration is an inventory problem
Ask a team where they use public key cryptography and you will usually get handed a certificate list, which is a small part of the answer.
The rest sits in load balancers that terminate TLS, in appliances whose keys nobody has rotated, in code signing keys, in firmware update verification, in database columns encrypted years ago, and in the internal clients your own developers wrote and forgot.
NIST's migration project at the National Cybersecurity Center of Excellence is working on exactly this, describing tools to find and prioritise vulnerable systems alongside guidance for the migration itself.
The common mistake is treating all of this as a TLS upgrade with a vendor patch attached. Vendors will ship quantum resistant versions of their products, and they will ship them on their own schedule, which is why the systems you cannot upgrade end up setting your timeline.
The standards also touch more than transport, since key establishment and digital signatures appear in code signing, device identity, secure boot and audit logs, all places where a quiet algorithm swap is harder to test.
1. Rank the data before you rank the systems.
Sort what you hold by how long it must stay confidential, because a session token and a patient record have very different useful lives to an attacker.
Once you know which data has to stay secret past your realistic migration window, you know which storage and transport paths to convert first, and you have an argument that survives a budget review.
Keep a second list of the places where you cannot change the algorithms at all, whether for contractual, firmware or vendor reasons, because those become named risks rather than surprises. If that list has to satisfy an auditor, the ISO 27000 series explained covers how the evidence is usually asked for.
2. Inventory everywhere cryptography hides, not where the certificate list points.
For each system, ask what key material it holds, which library performs the operation, and who can change that choice under pressure.
Treat any answer of the form "we use TLS" as unknown until someone shows you the negotiated cipher suite. Treat "the cloud provider handles it" as true only for the parts the provider genuinely terminates.
Pinned library versions, unmaintained open source dependencies and devices with years of field life are where this inventory stops being a spreadsheet and becomes a purchase order. When the transport layer is your starting point, the network security check covers the practical ground.
3. Build crypto agility before you swap algorithms.
Agility means the algorithm becomes a configuration decision rather than a code change, with key material behind an interface that carries its own algorithm identifier.
Teams that can turn a cipher suite on and off in a single release will run this migration as a rollout they can rehearse and reverse. Everyone else gets a project with a hard date and no rehearsal.
Expect the awkward parts to be interoperability, certificate handling and hardware modules that must agree on the new algorithms, so test early with the systems you actually run.
Falcon and HQC are still moving through standardisation as later options, and that is not a reason to wait for them, since the work in front of most teams is discovery rather than algorithm choice.
The old assumption was that cryptography is a design decision you make once, from whatever defaults your libraries happen to ship, and then stop thinking about.
The new reality is that cryptography is an operational lifecycle you have to be able to enumerate, change and verify on a schedule your own data retention sets.
If your CISO asked this week for a list of every system that would stop working the moment RSA and ECDSA were removed, could you produce it, and would two teams argue about who owns the same box?