Methodology

What we check

For each domain we find up to 12 public hosts: the one you entered, the main domain, www, common names such as app, api and login, and names from public Certificate Transparency logs. Hosts that carry customer data (app, API, login and similar) count as the customer data path; the rest are the public web.

On each host, over port 443, we check which key exchange the server picks when a modern browser offers post-quantum key exchange (X25519MLKEM768, using ML-KEM from NIST FIPS 203), which post-quantum groups it supports, which TLS versions it accepts, and its certificate.

How grades work

The first rule that matches gives the grade. Hosts that didn't answer are left out.

  1. F: a customer data path host has a basic TLS problem, such as a certificate problem or a weak key.
  2. D: a public web host has such a problem, or no host uses post-quantum key exchange.
  3. A: every host uses post-quantum key exchange, and none accepts TLS 1.0 or 1.1.
  4. B: every host uses post-quantum key exchange but some still accept TLS 1.0 or 1.1; or every customer data path host does and some public web hosts don't.
  5. C: some hosts use post-quantum key exchange, but not the whole customer data path.

Certificates aren't graded: post-quantum certificates for public websites aren't generally available yet, so classical certificates are expected today. Where post-quantum key exchange comes from a CDN, we say so; it isn't penalised.

What we can't see

Traffic behind your edge, between your services, stored data, signatures on your software, and anything not on port 443. That's why answers say what the scan verified and what you declared.

Changes

Every change that can change a grade is listed here with its date. Changes that lower grades are announced 30 days ahead.