Marin Ivezic
Where migration programs stall
Most post-quantum migration programs stall between the inventory and the first change window. A single corporate web session can cross three independent encryption layers, each with its own vendor, its own change process and its own test plan, and a program that tries to move all three at once often moves none of them. Traffic keeps flowing while the plan matures. An adversary running a harvest now, decrypt later campaign, usually shortened to HNDL, is content to wait: record the ciphertext today, store it, and decrypt it years from now once a cryptographically relevant quantum computer, or CRQC, can break the classical key exchange that protected it.
A better first question is which single layer protects the most traffic for the least work. That question has an answer, and the answer changes with the architecture. Below we work through six enterprise stacks and the reasoning that picks the first layer in each.
Why one layer can be enough
Take the web session above. The browser negotiates TLS to a security edge, the edge carries the session across its own tunnel to a point of presence, and the edge opens a second TLS session to the destination server. Three key exchanges, three sets of session keys, all nested.
Now suppose the middle tunnel uses ML-KEM, the key encapsulation mechanism specified in FIPS 203, while the other two still use elliptic-curve Diffie-Hellman. An adversary holding a stored capture and a working CRQC recovers the session keys for both classical layers. Then they reach the ML-KEM layer and stop, because Shor’s algorithm gives no advantage against a lattice-based key exchange. The payload stays encrypted. Nested confidentiality composes in the defender’s favor, and one quantum-safe layer is enough to keep the contents sealed.
Three limits come with that, and each one shapes what a first move can promise.
Confidentiality only. Authentication composes the opposite way. Every layer that authenticates with a public-key signature is an independent target, and a forged certificate at any one of them is a forged certificate. A quantum-safe signature at one layer protects that layer and nothing else.
Metadata follows the outermost layer. The layer an eavesdropper meets first determines what leaks about who is talking to whom, when, and in what volume. A quantum-safe layer wrapped inside a classical tunnel protects the contents and leaves the connection pattern in the open.
One layer is a starting position. Full migration is still the destination. The argument here is only that one layer deployed this quarter beats a comprehensive plan that reaches production in three years, because HNDL exposure accumulates every day in between.
Four questions that pick the layer
How centralized is the control? One configuration change at a proxy, a VPN concentrator or a service mesh control plane can cover thousands of sessions at once. A change that has to reach every laptop, handset or embedded controller is a program in its own right, and it makes a poor first move.
What does this layer actually hide? Migrating the outermost layer protects payload and metadata together. Migrating an inner layer protects the payload while leaving traffic patterns visible. Both are legitimate choices, and the right one depends on whether your threat model includes an adversary who cares about connection graphs.
Can you change it this quarter? Some layers belong to your team and move in weeks. Others wait on vendor firmware, protocol revisions, hardware refresh cycles or coordination with partners. The best first layer is frequently the one you can actually reach.
Is the layer even vulnerable to Shor? Shor’s algorithm breaks RSA, Diffie-Hellman and elliptic-curve cryptography outright. Grover’s algorithm only halves the effective strength of symmetric primitives, which leaves AES-256 and modern MACs and key derivation functions comfortable. AES-128 is the exception worth naming: Grover reduces it to roughly 64-bit effective security, which is close enough to classical feasibility that it shouldn’t be treated as safe by default. Layers built on public-key operations are the priority. Layers built on adequately sized symmetric keys can usually wait.
Six architectures
Proxied web traffic through a security service edge
A user device opens TLS to a security service edge, the edge carries the session over its own overlay tunnel, and the edge opens a fresh TLS session to the destination. All three legs typically use elliptic-curve key exchange.
The strongest first candidate is the client-to-edge leg, because both ends belong to you. Hybrid post-quantum key exchange runs a classical and a post-quantum algorithm together, with both contributing to the session key, so the connection stays interoperable and gains quantum protection at the same time. If the agent and the edge both support it, that segment becomes quantum-safe without asking anyone’s permission. The edge-to-origin leg is harder, since it needs the destination server to offer post-quantum key exchange too, and your provider can’t supply that unilaterally. Cloudflare has deployed hybrid ML-KEM key exchange to origins that support it, so coverage on that leg improves without any work on your side and outside your control.
Whatever stays classical still leaks metadata. Certificates on both sides of the edge remain RSA or ECDSA, which is an active-attack problem for later, not an HNDL problem for today.
East-west traffic in a service mesh
A service mesh manages mutual TLS, or mTLS, for service-to-service traffic, with both ends presenting certificates and the control plane issuing and rotating them. Hundreds of internal connections carry transaction records, customer data and internal API calls, all secured by the same negotiated cipher suites.
The control plane is the most effective point to change in the whole stack. One policy change to require hybrid post-quantum key exchange covers every sidecar proxy in the mesh, and closes HNDL exposure for east-west traffic that an attacker could capture from a compromised node or a permissive network policy. Ingress from external clients and connections to databases usually sit outside the mesh and need separate work.
Authentication is centralized here too, which helps, though it isn’t a single setting. Moving certificates to ML-DSA, the signature algorithm specified in FIPS 204, requires the mesh certificate authority, the certificate profiles, the validation stack and every data-plane proxy to support post-quantum certificates before the change is safe in production.
Remote access VPN
A standard WireGuard tunnel offers no post-quantum protection at all, because Curve25519 key exchange falls to Shor. IKEv2 with elliptic-curve Diffie-Hellman is in the same position. Capture the tunnel today, break it later, and the attacker sees browsing destinations, application payloads, session tokens and a map of the internal network.
Migrating the tunnel converts the VPN from the weakest link into the layer that protects everything inside it, and it happens at the concentrator rather than on every device. WireGuard offers an interim route: mixing a 256-bit pre-shared key, or PSK, into the handshake makes the derived session keys independent of the elliptic-curve exchange, so confidentiality survives even if Curve25519 does not. The cost is distributing and rotating those keys out of band. For IPsec, RFC 9370 defines multiple key exchanges in IKEv2, and ML-KEM profiles are moving through the IETF, so check what your existing platform already supports before planning a replacement.
Peer authentication stays classical in both cases, which leaves real-time impersonation on the table for a later phase.
OT and SCADA networks
Industrial protocols were mostly designed without cryptography. Modbus/TCP has a TLS-based security extension, DNP3 Secure Authentication uses HMAC-SHA-256, which is symmetric and therefore not a Shor target, and OPC UA defines fixed security profiles whose algorithm identifiers cannot be renegotiated without revising the specification. Post-quantum support in deployed PLC and RTU firmware is not generally available, and certification, interoperability and plant lifecycle constraints make protocol-layer migration a multi-year standards problem.
Start at the boundary instead. Distributed utility, manufacturing and pipeline environments commonly carry industrial traffic between sites inside an IPsec tunnel, and migrating that tunnel to hybrid post-quantum key exchange protects every encapsulated protocol underneath it. The controllers don’t change. The SCADA software doesn’t change. The gateway carries the protection for equipment that could never be upgraded directly, which is the composition rule doing its most useful work.
Authentication in OT is the hardest case in any sector, because device certificates are often baked into firmware that cannot be updated. Inventory it now, because the remediation timeline is measured in refresh cycles.
Email is a textbook HNDL target. Legal correspondence, deal discussions and clinical records captured in transit today stay sensitive for a decade or more, which is exactly the window an attacker is betting on.
The layer that protects contents end to end is application-layer encryption, S/MIME or OpenPGP, and it is also the layer with the least mature post-quantum tooling. Standards bodies have begun specifying ML-KEM and ML-DSA. Organizations running their own internal PKI for S/MIME can start issuing hybrid certificates for internal correspondence. For OpenPGP, post-quantum support is progressing but is not yet broadly interoperable. Across external counterparties, broad interoperability is not there for either.
The achievable move for most organizations is the transport layer: hybrid post-quantum key exchange for SMTP between mail servers, which you control if you run your own mail infrastructure. Be honest about what that buys. It protects the server-to-server hop and doesn’t help mail sitting at rest on either end. For genuinely high-sensitivity correspondence, it is a partial measure, and the application layer remains the real target.
Financial services API gateways
A mobile app or partner system reaches an API gateway over TLS, the gateway speaks mTLS to backend services, and a hardware security module, or HSM, a tamper-resistant device that stores keys and performs signing, sits behind all of it.
The gateway is the natural choke point, and most organizations run few of them. The complication is that inbound TLS needs both ends to offer post-quantum key exchange, so gateway support alone does not protect anything until clients send a post-quantum key share. For your own mobile apps that means a coordinated release. For partner integrations it means coordination across many organizations and a longer runway. AWS has enabled hybrid post-quantum TLS on KMS and several other service endpoints, and self-managed gateways inherit support from the underlying TLS library, with OpenSSL 3.5 and later offering the standardized algorithms natively.
HSMs are a separate workstream with its own timeline. Vendor roadmaps vary widely, refresh cycles are long, and no amount of transport-layer migration addresses a signing key that cannot be replaced with a post-quantum one. Ask your vendor for a delivery date in writing.
Authentication does not compose
One pattern repeats across all six architectures. Confidentiality accepts a shortcut and authentication refuses one.
The urgency profiles differ too. HNDL is a passive attack running today, which is why confidentiality migration is the one with a clock already ticking. Signature forgery needs a CRQC operating live during a connection, so it arrives later. That ordering is real, and it is also easy to over-read. Code signing certificates, firmware signing keys, root CA hierarchies and signed legal documents create trust that persists for years or decades after the signature, and certificate infrastructure takes the longest to move of anything in the stack. Less urgent than HNDL is not the same as safe to postpone.
Turning this into a first move
- Map the stack for each major data flow. List the cryptographic layers between source and destination, and mark which use public-key key exchange and which are symmetric. A cryptographic bill of materials, or CBOM, an inventory of algorithms and where they run, gives this a structure you can maintain rather than repeat.
- Find the most centralized point. One change, most traffic. Proxies, gateways, VPN concentrators and mesh control planes first. Anything requiring per-endpoint changes goes into the program, not the first move.
- Check vendor readiness before committing. Some platforms can enable hybrid key exchange with a configuration flag today. If your most centralized layer depends on a vendor who is not ready, take the next-best candidate instead of waiting.
- Deploy hybrid, then choose the next layer. Hybrid key exchange adds implementation complexity, and it is a transitional pattern rather than a permanent one, so evaluate it per protocol.
The methodology for sequencing what follows is set out at pqcframework.org, and the original analysis of the layer-selection problem on PostQuantum.com goes deeper on the composition argument itself.
The skill is the choosing
Deployment dates are already fixed by things other than quantum hardware. NIST IR 8547, the draft transition guidance, deprecates 112-bit-security public-key algorithms after 2030 and disallows them after 2035, NSA’s CNSA 2.0 schedule for national security systems runs ahead of that, and procurement questionnaires and insurance renewals are picking up quantum readiness questions well before either deadline.
What separates teams who ship a first layer from teams who are still scoping is not algorithm knowledge. It is the ability to read a protocol stack, identify where confidentiality is genuinely at risk, and defend a choice to the people funding the work. Quantum Academy’s post-quantum migration training is built around that decision, working through real architectures rather than algorithm specifications alone. Start at quantumacademy.com/.