SSLBoard reports whether the tested endpoints negotiate a recognized post-quantum key exchange and shows the observed group where available. This is a measurement of that TLS capability, not a certification that the whole application is quantum-safe.
Interpret readiness
A ready result indicates observed support for the relevant key-exchange capability. A not-ready result identifies a gap among endpoints with known results. Unknown or failed probes do not establish support or a confirmed lack of it; read the known-endpoint count with the percentage.
A hybrid group combines conventional key agreement with a post-quantum mechanism. Its name identifies the combination observed by the probe. That name does not describe the certificate’s signature algorithm or encryption of data stored by your application.
The readiness summary is High when at least 75% of known endpoints are ready, Medium from 40% to below 75%, and Low below 40%. With no known endpoints, the model uses Medium but has no readiness percentage; this is a lack of evidence, not a measured middle level of protection.
Reported group descriptions cover hybrid X25519+MLKEM768, P-256+MLKEM768, and P-384+MLKEM1024; the older X25519+Kyber768-draft00 name; and pure MLKEM512, MLKEM768, or MLKEM1024 groups. Preserve the actual group name when reviewing deployment. NIST defines ML-KEM in FIPS 203.
What this check does not establish
Support on a public TLS endpoint does not mean every client uses that group. Client support and negotiation choices matter. It also says nothing by itself about the connection from a CDN to an origin, internal services, backups, or other protocols.
An RSA or elliptic-curve certificate and a hybrid key exchange can coexist because certificate authentication and session key establishment are distinct. Read key analysis separately.
Plan and verify a change
Identify the TLS terminator and review which hybrid groups its current software or managed provider supports. Evaluate compatibility in that deployment before enabling or changing support.
After rollout, retest every affected endpoint and inspect both readiness and the reported group. If the public edge is ready but the origin connection is also in scope for your migration, assess that path separately. In SSLBoard’s score, this is one component of Future Readiness, not a substitute for fixing expired certificates or broken connections.