Every VPN tunnel, every SSH session, every encrypted handshake between two machines on the internet relies on mathematical problems that are hard for classical computers to solve. A sufficiently capable quantum computer would make many of those problems trivial, and the cryptography underpinning site-to-site IPsec connections and consumer VPN services alike would no longer offer real protection. The MLKEMProtocol initiative is working to close that gap by turning a newly finalized US government standard into practical, deployable code for the protocols that carry global traffic.
The starting point is ML-KEM, the module-lattice-based key encapsulation mechanism formalized by the National Institute of Standards and Technology as FIPS 203. Unlike the RSA and elliptic-curve systems that have secured internet traffic for decades, ML-KEM is built on lattice problems believed to resist attack even from large-scale quantum computers. Turning that mathematical foundation into something routers, firewalls, and VPN clients can actually use requires more than an algorithm on paper - it requires updates to the Internet Engineering Task Force standards that define how IPsec and related protocols negotiate encryption keys in the first place. That transition matters well beyond government networks; it shapes the everyday reality of anyone relying on encrypted tunnels to reach the open internet, including what VPN users in Iran run into when state-level filtering and surveillance make protocol resilience a matter of basic access rather than abstract security policy. what VPN users in Iran run into
Why Hybrid Handshakes Matter Now
No credible engineer is proposing to rip out existing cryptography overnight. The near-term approach favored across IETF working groups is hybrid key exchange: combining a traditional algorithm, such as elliptic-curve Diffie-Hellman, with ML-KEM in a single handshake. If either component holds, the connection remains secure. This hedges against two distinct risks - an unexpected weakness discovered in the new lattice-based math, and the slower-moving but more certain threat of quantum decryption capability arriving years from now. Intelligence agencies and security researchers have long warned about "harvest now, decrypt later" collection, in which encrypted traffic is captured today and stored for decryption once quantum hardware matures. For data with long confidentiality requirements - diplomatic cables, corporate trade secrets, medical records - that threat is already live, even though the hardware to exploit it does not yet exist at scale.
From Standard to Deployment
Publishing FIPS 203 was the easier half of the problem. The harder half is rewriting the negotiation logic inside IPsec's IKEv2 key exchange, WireGuard's handshake design, and TLS implementations so that hybrid or pure post-quantum modes can be offered, negotiated, and gracefully declined when one side does not support them. Larger key sizes and ciphertext overhead introduced by lattice-based schemes also affect bandwidth-sensitive backbone links, where every added byte in a handshake has measurable cost at scale. Reference implementations and interoperability testing, the kind of engineering work MLKEMProtocol is focused on, determine whether enterprise VPN vendors and backbone operators can adopt the new standards without breaking existing deployments.
What This Means for Ordinary Users
Consumers will not need to understand lattice mathematics to benefit from this shift, but they will eventually notice it in the form of updated VPN clients and router firmware. The broader lesson echoes earlier transitions in applied cryptography: protocols once considered unbreakable eventually give way, and the organizations that prepare early avoid scrambling later. For privacy-conscious users and the infrastructure operators who serve them, the practical choice is not whether post-quantum migration happens, but whether it happens through tested, standardized hybrid modes or through rushed, incompatible patches once the quantum threat becomes undeniable.
