TLS 1.3 support
TLS 1.3 is the baseline for modern transport security and practical hybrid post-quantum key exchange.
A website is not quantum-safe just because it has HTTPS. You need to check whether the endpoint is ready for post-quantum transport, whether hybrid key exchange is active, and whether older downgrade paths remain open.
TLS 1.3 is the baseline for modern transport security and practical hybrid post-quantum key exchange.
Look for an active post-quantum or hybrid group such as X25519MLKEM768. TLS 1.3 alone is readiness, not proof of active PQC.
TLS 1.0, TLS 1.1 and unmanaged TLS 1.2 fallbacks can keep older, non-PQC paths alive.
HSTS, CSP, X-Frame-Options and X-Content-Type-Options reduce avoidable browser and transport risk.
Classical RSA/ECDSA certificates are normal today, but long-term signing workflows need a separate PQC migration plan.
The public website is the fastest place to start because it is visible, measurable and often controlled by a CDN, hosting provider or load balancer that can enable modern TLS features before the rest of the estate is migrated.
A good external check should show whether TLS 1.3 is available, whether old protocol versions are still offered, whether a hybrid post-quantum key exchange is negotiated, and whether browser security headers are present.
"Ready" means the infrastructure has the foundation for post-quantum transport: modern TLS, sensible ciphers and controlled downgrade behaviour. "Active" means the connection actually negotiates a post-quantum or hybrid key exchange.
Many organisations will pass through a readiness phase first. That is useful, but it does not remove harvest-now-decrypt-later risk for traffic that still uses classical key exchange.
Read each result as evidence about the connection that was tested. Use the table to separate an urgent transport fix from a wider post-quantum migration task.
| Result | What it means | Next action |
|---|---|---|
| Hybrid PQC active | The tested path negotiated a hybrid key exchange such as X25519MLKEM768. | Check important subdomains, APIs and fallback paths, then record the result. |
| TLS 1.3 ready | The endpoint has a modern TLS foundation, but active PQC was not confirmed. | Ask the CDN or hosting provider how to enable hybrid ML-KEM key exchange. |
| Legacy fallback present | Older protocol paths may bypass the strongest available key exchange. | Confirm client requirements, then restrict obsolete protocols and retest. |
| Headers missing | Browser protections are incomplete, although this alone does not determine PQC status. | Add the recommended headers and keep PQC migration as a separate workstream. |
Run the free quantum security scanner to collect the public result, then use the cryptographic inventory guide to find risks that a website test cannot see.
No external website scanner can prove an organisation is fully quantum-safe. It cannot inspect private APIs, databases, backups, VPNs, code-signing workflows, identity tokens or supplier systems.
Treat the website result as a first signal. If it shows weak TLS or missing headers, fix those quickly. If it looks good, move to a cryptographic inventory and migration roadmap across the systems that protect long-lived sensitive data.
Run the free scanner, save the result in a free account, then rerun after fixing TLS, headers or provider settings.
Check whether the public endpoint supports TLS 1.3, negotiates a hybrid post-quantum key exchange such as X25519MLKEM768, blocks legacy protocol downgrades and uses essential browser security headers. An external check is only the first step because it cannot inspect private systems or stored data.
No. TLS 1.3 provides the modern foundation needed for many hybrid deployments, but the connection must also negotiate a post-quantum or hybrid key exchange to protect traffic against future quantum decryption.
X25519MLKEM768 is a hybrid key exchange that combines classical X25519 with the NIST-standardised ML-KEM-768 algorithm. Detecting it on the tested connection is evidence that hybrid post-quantum protection is active for that path.
No. A public scanner can assess visible TLS and security settings, but it cannot inspect private APIs, databases, backups, VPNs, signing systems or supplier dependencies. Those require a cryptographic inventory and migration assessment.
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.