Cloudflare's post-quantum transition deadline: 2029 (Source: Cloudflare blog (September 29, 2026))
A stronger lock does not help if an intruder can talk both sides into using the old one. That is the point of a finding Cloudflare published on September 29. It concerns IPsec, a protocol that secures traffic between networks. Adding post-quantum encryption to a tunnel may not be enough. The reason is the compatibility that lets old and new equipment talk to each other.
What Cloudflare found
Cloudflare says it found a design flaw in IPsec several months ago. It calls this a rediscovery, because others had seen part of it before. Its analysis is that a quantum attacker could decrypt all traffic between two endpoints. That holds even when both ends support post-quantum protection.
Cloudflare helped the IETF, the internet's standards body, develop an extension that adds downgrade protection to IPsec. Cloudflare has released it in beta.
The attack is hard. It needs a quantum computation done live, during the handshake. Cloudflare does not know if or when that will be feasible. It points to a sharp fall in the estimated resources needed to attack public-key cryptography. That is why it moved its own transition deadline up to 2029.
How the attack works
Before IPsec encrypts traffic, the two endpoints run a handshake called IKEv2. The connecting side, the initiator, opens by listing the settings it supports. It also sends a Diffie-Hellman key share. This is the classical key-exchange value that a quantum computer could eventually break.
Post-quantum protection is an optional extra step. It uses an algorithm called ML-KEM. The step happens only if the initiator offers it and the other side, the responder, agrees.
That option keeps older devices working. It also gives an attacker something to change. Suppose an attacker sits between the two endpoints. The attacker rewrites the initiator's first message so it claims classical-only support. The responder then skips the post-quantum step. The attacker's quantum computer can recover the encryption key from the classical key shares.
A rewritten message should break the handshake. Each side signs what it sent, so the responder would see a mismatch. The second half of the flaw explains why that check fails.
Each party signs only its own outbound messages. It does not sign the whole conversation. So the responder never confirms which initiator it accepted. Say the attacker holds credentials the responder trusts. The attacker can then sign with those. The responder thinks it is talking to the attacker. The real initiator thinks it is talking to the responder. Both end up using a key the attacker knows.
Cloudflare notes that a 2016 paper had already seen this weakness in how IKEv2 signs messages. It adds that TLS 1.3 avoids the problem. In TLS 1.3, each side signs the entire handshake record.
Why the obvious fixes fall short
The simplest fix is to switch off classical-only connections. Cloudflare says this is easier said than done. An initiator often cannot know what its peer supports before it connects.
Another idea is to copy HSTS, a web feature where a client remembers which servers offered stronger security. That does not fit here. In IKEv2, the settings are agreed before the peer says who it is. The memory has nothing to attach to.
Who carries the risk
The lesson here is that migration itself opens a gap. Old and new equipment must work side by side for years. In that time, the weakest option both sides accept sets the real security level.
Adding new cryptography is only the first step. The next is to stop active attackers from steering connections back to the old kind.
The cost falls on whoever runs the tunnels. Cloudflare says its extension works only if both ends support it. Its beta covers Cloudflare WAN and Magic Transit. Access is by request: a customer's account manager must enable a setting named ipsec_downgrade_protection. Cloudflare hopes the wider IPsec world follows soon. Until then, protection depends on what sits at the far end of each link.
The type of credentials your tunnel uses, classical or post-quantum, does not close this gap. The simple downgrade needs an attacker to crack classical credentials. The deeper flaw does not. It applies whichever kind of credentials a tunnel uses.
Cloudflare adds some good news on authentication. It sees IPsec's move to post-quantum sign-in keeping pace with TLS, the protocol behind most web traffic. A pre-shared key, often used with IPsec, is already fully post-quantum. That speaks to authentication readiness. It is not a defence against this downgrade.
Two caveats apply. Cloudflare expects easier targets to fall to quantum computers before this one, because the attack needs live computation. Also, this is one vendor's analysis of its own protocol.
Questions for your network team
Which of our site-to-site tunnels use IKEv2? Which of them still accept classical-only key agreement? Which vendors run the far end of those tunnels? Do they support the IETF downgrade-protection extension?
If we use Cloudflare WAN or Magic Transit, have we asked for the beta setting? Has anyone assumed our authentication method protects us from downgrade? Cloudflare's analysis says it does not. Finally, who decides when classical-only connections are switched off, and by what date?
A post-quantum upgrade counts only when the old option can no longer be forced on you.
Produced by the WebPulse Newsroom with AI assistance from the original reporting credited below, and checked against that source by our editorial review. How we use AI.
Original reporting: Cloudflare.
