Post-quantum readiness
Post-quantum migration splits into two problems with very different timelines. NoCert reports on the one you can act on today.
Key exchange is the part that matters now
Section titled “Key exchange is the part that matters now”Traffic captured today can be stored and decrypted later, once a quantum computer can break the key agreement that protected it. Anything long-lived you send over TLS is exposed to that, and the fix is available now: a hybrid key exchange such as X25519MLKEM768.
NoCert records the key-exchange group negotiated on every TLS observation and sorts your endpoints into three buckets:
| Bucket | Meaning |
|---|---|
| Negotiating post-quantum key exchange | The handshake used a hybrid group. |
| Not yet protected | The handshake completed on a classical group. A TLS 1.2 endpoint always lands here, since TLS 1.2 cannot negotiate ML-KEM. |
| Unknown | No completed handshake evidence: no TLS version was recorded. |
Find it on the Compliance page, under Upcoming requirements, in the Post-quantum readiness card. It is a Business feature, live during the trial. A CSV export of the same data sits beside it.
Unknown is never held against you.
Signatures are not your problem yet
Section titled “Signatures are not your problem yet”Your certificates use RSA, ECDSA or Ed25519, and that is expected. No public CA issues post-quantum certificates yet, so there is nothing to migrate to.
That is why NoCert does not flag your certificates as needing a post-quantum key. It would mark essentially every certificate you own with a warning you cannot act on.
Enabling post-quantum key exchange
Section titled “Enabling post-quantum key exchange”The least work is to terminate TLS at an edge that already does it. Most CDNs and load balancers have shipped support, so a fleet behind one may already be covered.
Per origin, upgrade to OpenSSL 3.5 or later. The hybrid group is in its default list, so many servers start negotiating it with no configuration change at all.
Only if you pin the group list yourself, put the hybrid first and keep the curve your certificates use, or those handshakes break. An ECDSA P-384 certificate needs secp384r1 left in the list.
ssl_ecdh_curve X25519MLKEM768:X25519:prime256v1;SSLOpenSSLConfCmd Curves X25519MLKEM768:X25519:P-256It also needs TLS 1.3. Reload, then check the endpoint in NoCert on the next scan to confirm the negotiation changed.
Certificates NoCert cannot read
Section titled “Certificates NoCert cannot read”An endpoint serving an ML-DSA or SLH-DSA certificate is recorded, but the certificate itself is not parsed. NoCert will not guess at a certificate whose algorithm it does not fully support.
The endpoint detail page names the algorithm family and marks it Unsupported algorithm. There is no fingerprint, no expiry date and no compliance verdict for that certificate, so it will not appear in your inventory or in expiry alerts.
The same handling applies to every algorithm NoCert does not read, not only the post-quantum ones: Brainpool, GOST, SM2, DSA and Ed448 land in the same place. ML-KEM as a key-exchange group is different and is fully supported, which is what the readiness card measures.
No policy requires post-quantum key exchange
Section titled “No policy requires post-quantum key exchange”None of the four TLS policies fails an endpoint for negotiating a classical TLS 1.3 group. Mozilla’s group check accepts X25519, P-256 and P-384 alongside the ML-KEM hybrids; P-521 and X448 draw a recommendation, which is advisory and does not change the verdict. BSI and NIST carry no group check at all.
ANSSI does flag DHE on TLS 1.2, but that is a forward-secrecy finding rather than a post-quantum one.