Is Your Data Quantum-Safe End to End?
CyberRank Research
Only if every hop is. A data flow is as quantum-safe as its weakest connection: a browser can use hybrid post-quantum key exchange with a CDN while the CDN-to-origin leg, an internal API or a vendor's database link stays classical. CyberRank shows which vendors' public services negotiate post-quantum or hybrid key exchange (Beta); internal hops need your own checks.
TL;DR
- Each TLS session has its own key exchange, so one post-quantum connection says nothing about the next hop.
- Connections can fall back to classical key exchange without an alert when a middlebox or server lacks support.
- CyberRank checks vendors' public endpoints (Beta); CDN-to-origin and internal links stay outside its view.
Where can a quantum-safe path break?
At any hop that negotiates its own key exchange: the CDN-to-origin leg, internal service calls, vendor APIs, and the links vendors run to their own suppliers.
Cloudflare reports that more than 65 percent of human traffic to its network uses hybrid post-quantum key exchange, but the leg to the origin server is protected only if the origin supports it. The same pattern repeats deeper in the chain, which is why the main article treats post-quantum readiness as a third-party risk.
| Hop | What can go wrong | How to check | How CyberRank helps |
|---|---|---|---|
| User to CDN or website | What can go wrongOlder clients or settings negotiate classical-only key exchange | How to checkInspect the negotiated TLS group | How CyberRank helpsReports what the public service offers (Beta) |
| CDN or load balancer to origin | What can go wrongOrigin lacks ML-KEM, so the second session is classical | How to checkCheck origin TLS configuration and CDN settings | How CyberRank helpsNot visible unless the origin is publicly reachable |
| Your systems to a vendor API | What can go wrongThe vendor's endpoint offers only classical key exchange | How to checkTest the endpoint; ask the vendor | How CyberRank helpsChecks the vendor's public endpoints |
| Vendor to its own suppliers | What can go wrongDatabase host, HSM or certificate provider is not ready | How to checkQuestionnaire and contract terms | How CyberRank helpsNot visible: fourth-party internals |
| Middleboxes on any path | What can go wrongLarger handshakes fail and traffic silently falls back | How to checkMonitor negotiated groups, not only uptime | How CyberRank helpsShows regressions on public services over time |
Example: a payment page behind a CDN (fictional)
A fictional retailer moves its checkout behind a CDN that supports hybrid key exchange and assumes the job is done.
The browser-to-CDN session uses X25519MLKEM768. The origin, an older load balancer, supports only X25519, so card tokens cross a classical session on the second leg. The payment processor's API is hybrid-ready, but its database host is not. Dashboards show healthy, encrypted traffic at every step.
The fix is to test each hop separately, ask the processor about its suppliers, and add hop-level checks to monitoring. The vendor questions to use are in our list of AI and quantum questions for vendors, and the external part of the path is your vendors' attack surface.
How CyberRank helps: it shows which public endpoints of the CDN, retailer and processor negotiate hybrid key exchange, which narrows where the classical hops are. The full picture of vendor risk is in our guide to post-quantum third-party risk.
Where CyberRank does not help
CyberRank observes only internet-facing services. It cannot see private CDN-to-origin links, internal service meshes, VPN tunnels between companies or a vendor's connections to its own suppliers, and it does not monitor which group individual sessions negotiate. Use your own network telemetry and vendor commitments for those hops.
References
Frequently asked questions
Check your vendors' quantum exposure
See which vendor endpoints already negotiate post-quantum or hybrid key exchange, with the post-quantum cryptography assessment.
Check your vendors' quantum exposure