The post-quantum conversation has been dominated by algorithm selection for several years, and that question is now closed.

ML-KEM is standardised. It is fast, it is implemented in every serious library, and it is running in TLS handshakes at scale on the public internet today. The signature story is equally settled. Anyone still deliberating over which key encapsulation mechanism to adopt is deliberating over a decision that has already been made for them.

What has not been settled is anything to do with operating the result.

The algorithms were the part of the problem that could be resolved by a standards process. Everything downstream of that has to be engineered, and it has to be engineered against conditions that a standards process does not describe.

The symmetric answer is not a workaround #

There is a persistent assumption that post-quantum security requires post-quantum asymmetric cryptography everywhere it touches, and that anything else is a compromise made by people who could not manage the real thing.

That assumption is wrong, and it is worth dismantling properly.

Symmetric cryptography was never the exposed surface. Shor's algorithm does not apply to it. Grover's algorithm offers a quadratic speedup at best, which leaves AES-256 with a security margin nobody is losing sleep over. The quantum threat to network traffic is specifically a threat to key establishment, and specifically to traffic being collected now against the possibility of decryption later.

Which means a sufficiently strong shared secret, mixed properly into key derivation, addresses the threat that actually applies.

This is not a fringe reading. RFC 8784 exists precisely to mix pre-shared keys into IKEv2 for post-quantum security, and it has been on the standards track since 2020. WireGuard's own documentation reaches the same place by a different route, recommending that a genuinely post-quantum handshake be run above the protocol with the resulting key inserted into the pre-shared key slot.

So the industry has a sanctioned answer.

What it does not have is an operational one.

What that answer is actually asking for #

"Insert the resulting key into the pre-shared key slot" is a single clause, and it is doing an enormous amount of work.

Unpack it against a real deployment. Every peer relationship needs its own key material, so the requirement is not one key but a number that scales with the topology, and in a mesh it scales faster than the device count. That material has to arrive at both ends. It has to be replaced on a schedule, because a shared secret that never changes reintroduces exactly the long-lived credential the exercise was meant to eliminate. It has to be revoked when a device is lost. It has to be stored somewhere at rest.

None of this appears in the cryptographic discussion, because from the perspective of the cryptography it is already solved. The key arrives by some means and the protocol proceeds.

The means is the entire problem.

It is also, unhelpfully, the part that gets costed last and discovered in the field.

Where distribution breaks #

The straightforward implementation is a central service that issues key material to endpoints over a post-quantum protected channel. It is easy to specify, it works well, and it holds up under exactly the conditions it will not encounter.

Three things break it.

The first is connectivity. If an endpoint cannot reach the distribution service, it cannot rotate. At that point the system either stops rotating, which quietly extends the window during which old material remains valid, or it drops the endpoint from the network. The first failure is invisible and the second is operationally unacceptable, which is how most deployments end up choosing the first without deciding to.

The second is scale. Rotation interval multiplied by relationship count multiplied by fleet size produces a distribution load that grows considerably faster than the planning assumptions behind it. An interval that is trivial across fifty endpoints becomes continuous background traffic across ten thousand, and on constrained links it competes directly with the payload it exists to protect.

The third is capture. A device holding current key material for each of its peers is a device that, when recovered by someone else, discloses the state of those relationships. Moving the post-quantum problem into the pre-shared key slot resolves a cryptographic question and creates a custody question in the same movement.

None of the three is exotic. All three are ordinary operating conditions outside a data centre.

Derivation instead of delivery #

The alternative to shipping keys is not shipping them.

If both ends of a relationship can compute the same key from a root secret and a set of shared inputs, the key itself never crosses the network. Bind the derivation to the peer identifiers, an epoch and a purpose, run it through HKDF, and each relationship gets material unique to that pair and that period, without a delivery step for each one.

Rotation then stops being a distribution event. It becomes an epoch advancing, which both ends can do independently and, critically, can do while disconnected. An endpoint that has been dark for a week does not need to catch up on a backlog of deliveries. It needs to know what time it is.

This does not make the problem disappear, and it would be dishonest to present it as though it did.

The root secret becomes the asset worth stealing, and it has to live somewhere. On server-class hardware that is a well understood question with well understood answers involving hardware security modules. At the edge it frequently is not, because a large proportion of the hardware people actually deploy has no secure element and no hardware root of trust worth relying on.

That constraint is industry-wide and it is not going away soon. The honest response to it is not to claim the root secret is protected. It is to bound what a captured device is worth: narrow the scope of what any single root covers, keep epochs short enough that recovered material ages out quickly, and ensure that possession of key material confers no standing authority to rejoin a network that has moved on.

A system designed on the assumption that devices will eventually be recovered by the wrong people makes different choices than one designed on the assumption that they will not. Only one of those assumptions has ever held.

Better questions than which KEM #

The question suppliers are usually asked is which key encapsulation mechanism they support. It does not discriminate between products, because every supplier will eventually answer ML-KEM and most of them will be telling the truth.

Four questions that do discriminate.

How does current key material reach an endpoint that has not been reachable for a week, and what happens to that endpoint in the meantime. What is the rotation interval, and what does it cost in bandwidth on the worst link in the deployment. What does a captured device disclose about relationships it is not itself part of. And what happens to rotation when the management service is unreachable, which is the condition under which it matters most.

The answers to those four separate serious products from demonstrations.

The standardisation of ML-KEM was widely treated as the end of the post-quantum problem. It was the end of the part that could be solved by committee, which is a smaller achievement than it was reported to be.

The remainder is distribution, rotation, revocation and custody, under intermittent connectivity, at scale, on hardware that will occasionally be in the wrong hands.

Choosing the algorithm was the part that could be standardised.

Delivering it is the part that has to be engineered.