Cloud and CDN providers are starting to deploy ML-KEM and hybrid post-quantum TLS. That helps, but it does not prove your own domains, APIs, origins, SDKs or clients are ready. Use this guide to turn provider announcements into endpoint-level evidence.
Cloudflare documents post-quantum hybrid key agreement for TLS 1.3 and HTTP/3, including X25519MLKEM768.
A Cloudflare zone can still be blocked by settings, FIPS mode, origin behaviour, legacy client support or non-HTTP services.
Check the live hostname, browser/client support, TLS 1.3 negotiation and origin fallback paths.
AWS says it has deployed NIST-standardised post-quantum algorithms across several services, with hybrid ML-KEM key establishment in services such as KMS, S3, CloudFront and Secrets Manager clients.
Support depends on the AWS service, region, endpoint, client SDK/runtime and whether traffic is to AWS service APIs, CloudFront or your own origin.
Check service-specific docs, SDK versions, CloudTrail tlsDetails where available and application latency impact.
Fastly announced ML-KEM support across its global CDN fleet starting April 2025.
A public announcement does not prove every service, certificate path, origin connection or client segment is negotiating PQC today.
Test the live hostname, confirm TLS 1.3, ask Fastly for account-specific enablement status and document origin behaviour.
A CDN or cloud provider can support post-quantum cryptography while a specific customer workload still negotiates only classical key exchange. The gap can come from TLS version policy, FIPS mode, client capability, SDK version, origin routing, regional support or product-specific limitations.
The practical question is not "does our provider have a PQC blog post?" It is "which of our real user journeys and machine-to-machine calls negotiate a NIST-standardised hybrid key exchange, and where do they fall back?"
Treat provider documentation as supplier evidence, then pair it with live scans and application tests. That gives you a defensible cryptographic inventory rather than a general assumption.
Cloudflare documents post-quantum key agreement for TLS 1.3 and HTTP/3, with X25519MLKEM768 as the current hybrid key agreement. It also provides Radar tools for checking post-quantum adoption and browser support.
For a Cloudflare-protected hostname, confirm TLS 1.3 is enabled, test with a current browser or scanner, check whether FIPS mode changes behaviour, and make sure the origin cannot be reached through a weaker bypass path.
AWS documents NIST-standardised PQC deployment across several services, including hybrid ML-KEM key establishment for services such as KMS, S3, CloudFront and Secrets Manager clients. AWS documentation also notes that SDK, agent and runtime versions matter.
For AWS environments, separate public edge traffic from AWS service API calls. Test CloudFront hostnames separately from KMS or Secrets Manager clients, check SDK support, record service-region evidence and monitor latency or throughput changes during pilots.
Fastly announced ML-KEM support across its global CDN fleet starting April 2025. For customer evidence, that announcement should be paired with account-specific provider confirmation and live hostname testing.
Test the hostname served through Fastly, confirm TLS 1.3, check client behaviour, ask which services and regions are covered, and record whether origin connections are included or remain a separate migration item.
Not automatically. Cloudflare has strong public PQC support, but the live hostname, configuration, TLS version, client support, FIPS mode and origin paths still need to be verified.
No single AWS statement covers every path. AWS documents PQC support for specific services and clients, so teams must check the exact service, SDK, endpoint and region they use.
A provider announcement is useful background, but audit evidence should include a live scan, configuration evidence, supplier documentation and an owner-approved migration record.
Start with public customer-facing domains and APIs, then test service-to-service calls, managed cloud APIs, origin connections, mobile apps and partner integrations.
Provider-level PQC support is useful, but your migration plan needs hostname-level evidence. Start with a free external scan, then record provider settings and client compatibility in your inventory.
A PQC guide is more useful when it is attached to current evidence. Create a free account, add a public domain now or later, and keep a repeatable baseline for TLS, security headers and visible post-quantum readiness.
Prefer to scan first? Open the free quantum security scanner.