The clock
Why does harvest now, decrypt later put a deadline on traffic you already sent?
Because the interception happens before the capability does. CISA, the NSA and NIST warn jointly that encrypted traffic captured today can be stored and decrypted once a cryptographically relevant quantum computer exists. That makes the arrival date the wrong thing to argue about.
01
The collection comes first
Encrypted traffic captured today keeps its value for whoever stores it. The decryption is deferred, not abandoned, which is why exposure starts at the moment of capture rather than at the moment the capability lands.
02
Mosca's rule replaces the date argument
Add how long your data must stay confidential to how long your migration takes. If the total runs past the point where a capable quantum computer exists, the data you send today is already outside its protection window. No date is needed to make the comparison useful.
03
What actually has to change
Only the key exchange and the signatures are at risk. NIST published ML-KEM (FIPS 203) for key establishment, ML-DSA (FIPS 204) and SLH-DSA (FIPS 205) for signatures in August 2024. The symmetric encryption protecting the session, AES-GCM, is not the concern.
04
Hybrid, so nothing regresses
During the transition a classical key exchange and a post-quantum one are negotiated together. If a flaw turns up in the newer algorithm the classical half still holds, and if a quantum computer arrives the post-quantum half already covers the traffic. ANSSI and BSI both treat hybrid as the target state; NIST permits it without requiring it.
Crypto-agility, the ability to change algorithm without re-architecting, is the wider discipline this belongs to. It also covers your certificate estate and your internal PKI, which sit outside this page.
The platform
Which parts of Cloudflare are already post-quantum?
Most of them, and the inbound leg has been for a while. Cloudflare announced in February 2026 that Cloudflare One supports modern post-quantum encryption across the platform, and states a target of full post-quantum coverage across its product suite by 2029. Here is what that means per component, and what each one still depends on.
Inbound TLS
Every site and API served over TLS 1.3 negotiates a hybrid X25519MLKEM768 key exchange, and has done since 2022. Two conditions apply: the client has to support it, and it only exists from TLS 1.3 upward. A zone still accepting TLS 1.2 has a segment where post-quantum key agreement cannot happen at all.
In practiceA browser released in the last two years negotiates it silently. A scripted client on an older TLS library does not.
WARP and the Cloudflare One client
Device traffic reaches the network over MASQUE, on TLS 1.3 with hybrid ML-KEM. A remote employee's tunnel is covered with nothing to configure on their machine, provided the client is current.
In practiceVersion drift is the failure mode here, not configuration.
Cloudflare Tunnel
Supports post-quantum key agreement, and is the practical way to cover the leg between the network and your origin without touching the TLS stack of each server.
In practiceThis is the recommended route for the origin gap covered in the next section.
Gateway (secure web gateway)
Covers HTTPS traffic leaving through the gateway. The outbound half still depends on the destination: a third-party origin that does not support post-quantum key agreement negotiates a classical one.
In practiceYour users are covered up to the point where someone else's server answers.
Browser-based access
Clientless access to internal applications is covered when the user's browser supports post-quantum key agreement, with no change to the application itself.
In practiceNo agent, no application rework, but the browser decides.
IPsec and WAN
Post-quantum encryption for Cloudflare IPsec is generally available using hybrid ML-KEM, with interoperability confirmed by Cloudflare with Cisco and Fortinet. Third-party devices depend on their support for RFC 9370, and the Cloudflare One Appliance carries it from version 2026.2.0.
In practiceThe only segment where the far end can refuse the negotiation outright.
The pattern is consistent: Cloudflare holds its own half of every negotiation. What decides your actual coverage is the other half, which is the subject of the next section. Application-layer protection is a separate concern, covered on the WAAP use case.
Your coverage
Which of your connections are actually post-quantum today?
Fewer than the platform page suggests, and the gaps are predictable. Cloudflare Radar puts post-quantum key exchange at 54% of human HTTPS requests in June 2026. Human is the operative word: machine clients lag well behind, and they are often the ones carrying your longest-lived data.
Four segments account for nearly every gap we find. None of them is a vulnerability in the strict sense. Each is simply a place where the negotiation settles on a classical key exchange, so harvested traffic on that leg keeps its future value.
Where traffic leaves the post-quantum perimeter
Tone reflects how much of the segment you control, not the severity of a defect. Each of these has a way to close it, covered in the rollout section below.
| Segment | What decides whether it is post-quantum | Today |
|---|---|---|
| Origin reached directly | The TLS stack on your own origin decides, and most origins answer with a classical key exchange. | Classical |
| Clients on TLS 1.2 | Post-quantum key agreement does not exist below TLS 1.3, so no negotiation can produce it. | Out of scope |
| API and machine clients | Their TLS library decides. SDKs, integration scripts, appliances and partner systems commonly predate ML-KEM. | Usually classical |
| IPsec peers | The peer's support for RFC 9370 decides, whatever Cloudflare offers on its side. | Peer decides |
You can check the first one yourself, in about two minutes
- Open a TLS 1.3 connection to one of your own hostnames with curl or openssl and read the negotiated group. If it comes back X25519MLKEM768, that segment is covered for that client.
- Cloudflare publishes a post-quantum test endpoint, and Radar reports the post-quantum share of traffic including the split between human and automated requests. Both are public, so nothing here rests on our word.
- Nothing in this section requires a tool from us. The measurement you cannot run alone is the one across all your clients over time, which is where an operated cadence earns its place.
A classical key exchange is not a protocol downgrade and not an incident. TLS 1.3 removed RSA key exchange entirely, so what you are seeing is X25519 or an elliptic-curve group being chosen instead of the hybrid one. The session is still encrypted. What differs is the future value of the captured handshake.
The assessment
What can you check today, without launching a cryptographic inventory project?
Three checks, all of them configuration rather than cryptography. They tell you where you stand well enough to decide what to do first.
01
What is routed, and what answers directly
List the hostnames that resolve outside the proxy, and the origins reachable from the internet. Anything answering directly sits outside every control configured at the edge, post-quantum included.
02
Which zone settings cap your coverage
Minimum TLS version and SSL/TLS mode decide whether a post-quantum negotiation is possible at all. This is where a configuration audit contributes: it covers zone hygiene, which is the precondition rather than the verdict.
03
Which clients you can measure, and which you cannot
Browsers are the easy half. Machine clients need to be listed, then split between the stacks you control and the ones a partner controls.
Three starting points, three different first steps. No visibility at all: begin with routing, not with cryptography. Cloudflare in place but the origin still exposed: close that leg with a tunnel before anything else. Both in hand: the remaining work is keeping versions current and documenting what you cannot control, which belongs in an operating cadence rather than a project.
A Cloudflare configuration audit covers the second check end to end.
Not sure which segments are still classical?
A Brixio engineer goes through your zone, your Cloudflare One components and your tunnels, and comes back with the list.
Talk to an expert- No inventory project
- Your own environment
- Cloudflare ASDP
The rollout
How do you turn on what is already there, without breaking production?
There is no cutover here. A hybrid key exchange means a post-quantum negotiation and a classical one run together, so nothing regresses and nothing has to be scheduled at midnight.
01
Inbound: nothing to deploy, everything to measure
TLS 1.3 and HTTP/3 already carry the hybrid exchange. The work is finding out what share of your traffic negotiates it, and who does not.
02
Cloudflare One: a version question, not a migration
Bring WARP, Gateway and the appliance to versions that carry ML-KEM. This is patch management, not a cryptographic project.
03
Origin: route it rather than re-engineer it
Cloudflare Tunnel in post-quantum mode covers the origin leg without touching the TLS stack of every server. Post-quantum signatures (ML-DSA) are already used for origin authentication.
04
IPsec: enable on one side, verify the other
Turn on the hybrid exchange on the Cloudflare side, then confirm firmware and RFC 9370 support on the peer. Cloudflare has confirmed interoperability with Cisco and Fortinet; anything else goes through a lab test first. Larger post-quantum key shares also put IKEv2 fragmentation and path MTU under pressure, so check that fragmented negotiation packets are not dropped before you switch a production tunnel.
The obligations
Which obligations put post-quantum on your roadmap?
None of the European frameworks name post-quantum cryptography as a requirement today. What they do require is a cryptographic policy and the ability to change algorithm as cryptanalysis moves, which is the same work seen from the compliance side.
NIS2, Article 21(2)(h)
Requires policies and procedures on the use of cryptography and, where appropriate, encryption. No post-quantum obligation, but a documented cryptographic posture.
DORA, Delegated Regulation (EU) 2024/1774, Articles 6 and 7
Financial entities must hold an encryption policy and provide for updating cryptographic technology as cryptanalysis develops, with mitigating measures where an update is not possible.
Commission Recommendation (EU) 2024/1101
Sets the coordinated European transition and explicitly calls for deployment through hybrid schemes. Its first deliverable, the NIS Cooperation Group roadmap of 23 June 2025, sets national plans, then high-risk use cases, then a general horizon.
NIST IR 8547 (draft)
Describes deprecation of RSA and elliptic-curve key establishment after 2030 and disallowance after 2035, alongside the FIPS 203, 204 and 205 standards published in August 2024.
ANSSI
Recommends hybrid deployment in three phases, and has announced that products without post-quantum cryptography will no longer be accepted for security qualification from 2027.
Details on both European frameworks sit on our NIS2 and DORA pages. For a regulated entity the useful reading is not a deadline to meet: it is that a cryptographic posture you cannot describe segment by segment is hard to evidence to an auditor, whichever framework applies.
The managed service
How does Brixio operate post-quantum readiness day to day?
Post-quantum coverage on Cloudflare is not deployed once. It drifts, because a component left several versions behind quietly stops carrying it. What we run is the cadence that keeps it in place, on the same control plane as the rest of your Cloudflare estate.
Configuration in the managed cadence
- Zone settings reviewed on a fixed schedule: SSL/TLS mode and minimum TLS version
- Hostnames answering outside the proxy listed and arbitrated
- Origins still reachable directly flagged for a tunnel
- Changes recorded, so the posture has a history rather than a snapshot
Versions kept current
- WARP, Gateway and appliance versions tracked as part of patch management
- Version drift treated as a coverage loss, because that is what it is
- Peer firmware checked before a tunnel configuration changes
- New Cloudflare post-quantum releases assessed as they ship, ASDP early access included
24/7 follow-the-sun operations
- Tunnel and access incidents handled around the clock, not queued to the next business day
- A named certified team rather than a rotating queue
- Response SLAs written into the engagement
- Escalation straight to the engineers who hold your configuration
A posture you can evidence
- What is in place, since when, on which segment
- The segments that stay classical, named, with the reason
- Documentation an assessor can read without a translation layer
- Reusable across NIS2, DORA and sector frameworks alike
Every segment converges on the same Cloudflare control plane. Cloudflare holds its half of the negotiation; what the other half offers decides the outcome, and Brixio keeps that outcome documented.
This runs on Brixio's standing security posture
Cloudflare
Authorized Service Delivery Partner (ASDP)
ISO 27001:2022
certified data handling
450+
delivered projects in regulated industries
4 hubs
Luxembourg · Paris · Dubai · Singapore, follow-the-sun
This sits on the same control plane as the SASE and Zero Trust architecture and our managed services. Talk to an expert to scope it on your own environment.
The boundary
What post-quantum readiness on Cloudflare does not cover.
Post-quantum work spreads far wider than the network, and most of it is not ours. Saying where this stops is part of the answer, and each boundary below has a proper owner.
Your internal PKI and certificate estate
Issuing, rotating and eventually re-signing certificates with post-quantum signatures is a programme of its own. It touches your certificate authority, your issuance workflows and everything that validates a chain. Nothing on this page moves it forward, and treating a post-quantum key exchange as if it had is the most common misreading of the subject.
Signature migration to ML-DSA
Key exchange and signatures are two separate transitions. The key exchange is largely done for you on the network; signatures depend on what public certificate authorities issue, and on your own code signing and device identity. That work sits ahead of the market, not behind a configuration switch.
Cryptography inside your applications
Database encryption, HSM-held keys, field-level encryption, secrets at rest: all of it lives above or behind the network layer. A cryptographic inventory of that estate is a legitimate project, and it is not what this use case delivers.
Anything not routed through Cloudflare
Internal applications reached without passing through the network, site-to-site links outside the WAN, and third-party services your users reach directly are outside the perimeter described here. The first check in the assessment section exists precisely to surface them.
The wider discipline covering all four is crypto-agility, and it belongs to your organisation rather than to a platform. What Cloudflare and Brixio close is the transport layer, which happens to be the segment carrying the traffic an interceptor can collect today.