A lot of post-quantum discussion still starts in the wrong place. It starts with the algorithms. Which standard won? When do we replace X25519? Is ML-KEM enough? How long until signatures move too? Those questions are real, but they are not the first problem most organisations have to solve. The first problem is much less glamorous. They do not know where quantum-vulnerable public-key cryptography is actually in use, what systems depend on it, what would break if it changed, or how to prioritise the work.
That is why post-quantum migration is not primarily an algorithm problem. It is an inventory, discovery and readiness problem.
This is not an attempt to downplay the cryptography. The algorithms matter. The standards matter. Protocol support matters. But if an organisation cannot answer basic questions about where classical public-key cryptography is buried across its infrastructure, software and services, then the migration fails much earlier than the standards layer. It fails at visibility.
The current official guidance points in exactly that direction. The NCCoE Migration to PQC project does not frame the work as “wait for an algorithm and swap it in later.” It explicitly frames migration as action to understand the use of quantum-vulnerable public-key algorithms across hardware, software and services, and it gives Cryptographic Discovery its own workstream. The accompanying Quantum-Readiness Fact Sheet is just as clear: organisations should be building roadmaps, inventories, risk analysis and vendor engagement now.
That shift in emphasis matters. It means the real bottleneck is no longer “nobody knows what the post-quantum algorithms are.” The real bottleneck is that most environments are much less legible than their owners think they are.
The Standards Are Real, but They Are Not the Main Excuse Any More
For a while, it was reasonable to talk as though post-quantum migration was blocked on standardisation. That excuse has weakened significantly.
In 2024, NIST finalised its first three principal post-quantum standards in the form described in NIST Releases First 3 Finalized Post-Quantum Encryption Standards. That announcement formalised FIPS 203 for ML-KEM as the primary general encryption standard, FIPS 204 for ML-DSA as the primary digital signature standard, and FIPS 205 for SLH-DSA as a backup signature method. In 2025, NIST also selected HQC as a fifth algorithm for post-quantum encryption in NIST Selects HQC as Fifth Algorithm for Post-Quantum Encryption, reinforcing that the algorithm layer is still evolving at the edges even while practical migration has already begun.
That does not mean the standards story is finished. It does mean “we are still waiting for the standards” is no longer a serious answer to the broader migration problem.
The more useful question now is not whether the algorithms exist. It is whether the systems that need them can be found, understood and changed without breaking everything around them.
Why Inventory Comes First
The reason inventory comes first is simple. Public-key cryptography is rarely confined to the obvious places.
People think first about visible external protocols, TLS, SSH, VPNs, secure email, code signing, device provisioning, maybe a few certificates in an internal PKI. Those are only the surfaces they can already name. The deeper problem is everything else: old libraries, embedded dependencies, firmware tooling, build pipelines, signing workflows, service-to-service trust, pinned algorithms, hidden certificate stores, hardware constraints, middleboxes, vendor products and brittle compatibility assumptions that nobody has had to think about in years.
This is why the Quantum-Readiness Fact Sheet is more practical than a lot of public post-quantum commentary. It tells organisations to identify where quantum-vulnerable cryptography is used in network protocols, end-user systems, servers, software dependencies and CI/CD pipelines. That is not abstract guidance. It is a warning that the migration surface is much broader than the headline protocols.
The hard part is not merely that classical cryptography exists in many places. It is that different uses carry different consequences. Some are confidentiality problems with long-lived data. Some are future impersonation problems. Some are software supply-chain problems. Some are trust-anchor agility problems. Some are “this old thing nobody wants to touch will take eighteen months to replace” problems. Until those are inventoried and classified, the algorithm discussion sits on top of incomplete information.
That is the point. Post-quantum migration is not blocked by the absence of a standard nearly as often as it is blocked by the absence of a usable map.
TLS Is a Good Example, but Only a Partial One
TLS is a good place to see the shape of the larger problem because it is both important and misleading.
On the surface, the TLS story looks encouraging. The Post-Quantum Hybrid ECDHE-MLKEM Key Agreement for TLSv1.3 work has advanced to a late stage in the IETF process. Browser and platform vendors are already moving. In Advancing Our Amazing Bet on Asymmetric Cryptography, Chrome states plainly that its post-quantum strategy prioritises quantum-resistant key exchange in HTTPS and greater agility in certificates from the Web PKI. Cloudflare’s State of the Post-Quantum Internet in 2025 reports that the majority of human-initiated traffic it handles was already using post-quantum encryption by late October 2025, and it also notes broad support across major browsers, recent Apple operating systems, OpenSSL and Go.
That sounds like rapid progress, and it is. But it is also a good example of why surface progress is not the same thing as migration readiness.
Chrome’s write-up is especially useful here because it avoids the easy version of the story. It explicitly separates two threats to HTTPS: the threat to traffic being generated today, which is why key exchange matters urgently, and the threat to future traffic being impersonated once authentication breaks, which is why certificate and Web PKI agility matter too. It also says directly that the absence of PKI agility has contributed to delays in past cryptographic transitions and will continue to do so until the problem is addressed.
That distinction is important because it shows how quickly the phrase “TLS is moving” can hide the real architectural work. A stack can support hybrid key agreement and still be far from ready. You may still have certificate constraints, reverse proxy constraints, hardware module constraints, client compatibility constraints, internal PKI constraints or operational rollout constraints. In other words, even within TLS, readiness is not one thing.
And TLS is only one surface.
The Real Problem Is Interdependence
This is where a lot of post-quantum discussion becomes too flat. It talks as though the migration were a set of independent swaps. Replace this KEM here, replace this signature there, pilot some hybrid deployments and move on.
Real systems do not behave like that. They are interdependent.
A certificate choice affects handshake size, compatibility and issuance paths. A library update affects embedded products and build pipelines. A new signature scheme affects certificates, artefact distribution and verification environments. A change in one trust boundary can expose another system that still assumes classical primitives. A procurement decision made five years ago can quietly dictate what you can or cannot do next year.
This is why the NCCoE Migration to PQC project does not treat discovery as busywork. Discovery is what lets you turn a cryptographic transition into an engineering plan instead of a slogan. If you do not know what depends on what, the transition is not just delayed. It becomes irrational. You cannot prioritise well because you do not yet know what is connected to the thing you plan to change.
That is also why the migration conversation often feels detached from operators. It is easier to discuss algorithms than to discuss inventories, asset classification, dependency analysis, protocol boundaries and vendor constraints. But the latter is what determines whether the algorithms ever make it into production use safely.
Why “Support ML-KEM” Is Not a Migration Plan
One of the easiest ways to see the problem is to ask a deliberately narrow question.
Suppose a vendor tells you, truthfully, that it now supports ML-KEM or hybrid TLS. What does that actually settle?
It settles that one implementation has moved far enough to expose one post-quantum-capable path. It does not tell you:
- where in your estate that path is actually reachable
- whether the rest of the trust chain can follow it
- whether clients, certificates, libraries and monitoring all agree
- whether your older systems still pin the old assumptions
- whether your internal tooling can detect, report and prioritise the remaining classical exposure
- whether your highest-risk data or most brittle systems are even using that vendor surface
In other words, “support exists” is not the same thing as “migration is underway”, and it is very far from “migration is under control”.
That is why a lot of post-quantum readiness work looks boring. Inventory is boring. Classification is boring. Dependency tracing is boring. Vendor capability tracking is boring. But those are exactly the boring things that determine whether the transition can be executed deliberately instead of reactively.
The Real Migration Question
The wrong first question is: which post-quantum algorithm should we standardise on everywhere?
The right first question is: where is quantum-vulnerable public-key cryptography actually in use, what risks do those uses create, and what blocks us from changing them?
That question is less dramatic, but it is closer to the real engineering problem. It also produces a better sequence of work.
First, discover the cryptographic surfaces that exist. Then classify them by role, confidentiality lifetime, operational criticality and migration difficulty. Then identify the trust boundaries and dependencies around them. Then map vendor and standards support onto those realities. Only then does “which algorithm where, and when?” become a properly grounded decision.
That is not an argument against standards. It is an argument against pretending that standards remove the need for system understanding.
My View
I think the post-quantum migration conversation is still too eager to start where the standards documents start instead of where actual environments start.
The standards are necessary. Protocol support is necessary. Hybrid deployment is useful and, in some cases, already real. But they do not solve the first-order organisational problem, which is that most environments are not yet legible enough to migrate confidently.
That is also why I think inventory and readiness tooling deserve more attention than they often get. The bottleneck is not only “can this protocol negotiate a post-quantum-capable path?” It is also “can we tell where classical public-key cryptography still exists, what depends on it and how we should prioritise the migration work?” The second question is less fashionable, but it is what makes the first one operationally meaningful.
The Broader Lesson
A lot of engineering mistakes come from starting with the visible mechanism instead of the real constraint. In post-quantum migration, the visible mechanism is the algorithm. The real constraint is often visibility.
That does not make the algorithm unimportant. It makes the migration problem more honest. You can have the standards, the draft protocol support and the vendor announcements in place and still be unready because you do not yet know enough about the systems you are meant to protect. The organisations that handle this transition best are unlikely to be the ones with the loudest “we support PQC” claim. They are more likely to be the ones that can answer, with evidence, where their classical public-key cryptography is, why it matters and what comes next.
That is why post-quantum migration is not primarily an algorithm problem. It is, first, a visibility problem. This is also part of the problem I am building Surveyor around. Not post-quantum cryptography as theatre but the more immediate problem of discovery, inventory and readiness across real systems.