How it works

Public-key cryptography — the padlock in your browser — rests on math problems that classical computers cannot solve in any useful time. Shor's algorithm, running on a sufficiently large quantum computer, solves them efficiently. Every RSA key and every elliptic-curve key in use today falls to it.

The fix exists. NIST standardised it in August 2024: ML-KEM for key exchange (FIPS 203) and ML-DSA for signatures (FIPS 204). The problem is not the algorithms. The problem is that almost nobody knows where their cryptography is.

The replacement algorithms are built on lattices — grids of points in very high-dimensional space. Finding the point closest to a given position in such a grid is easy to state and, as far as anyone knows, brutally hard to compute, for classical and quantum machines alike. That is the hard problem ML-KEM stands on, in place of the factoring and discrete-log problems that Shor's algorithm dismantles.

The lattice is what your locks are about to be rebuilt on. This tool tells you which of them still aren't.

TLS uses cryptography for two different jobs, and they carry very different deadlines.

Key exchange establishes the secret that encrypts your session. An adversary can record that encrypted traffic today, store it, and decrypt it years later when a quantum computer arrives. This is called harvest now, decrypt later, and it means the damage is being done now, silently. This is the half you can fix today — hybrid ML-KEM is supported by every current major browser and by most CDNs.

Signatures prove the server is who it claims to be. A signature only has to resist forgery while it is still trusted; breaking it in 2032 does not retroactively compromise a handshake from 2026. It matters, but it is not urgent — and no publicly-trusted certificate authority issues post-quantum certificates yet, so there is nothing to migrate to.

Most vendors blur these together, because two deadlines are less frightening than one. LatticeScan reports them separately.

1. Discovery. Since 2018 every publicly-trusted certificate must be published to public Certificate Transparency logs. We read those logs to find the hostnames you have issued certificates for — including ones you may have forgotten.

2. Probing. We open a TLS 1.3 connection to each endpoint and offer it only post-quantum key exchange groups. If the handshake completes, the server supports ML-KEM. If it refuses, it does not. This is the same handshake your browser performs — nothing intrusive, nothing that touches your systems.

3. Inventory. Results are compiled into a cryptographic inventory, exportable as a CycloneDX CBOM — the format US Executive Order 14412 directs CISA to define minimum elements for.

The grade reflects post-quantum key exchange coverage across the endpoints we reached — the thing you can actually act on.

• A — every endpoint negotiates hybrid ML-KEM
• B — most endpoints do
• C — modern TLS, but classical key exchange
• D — some endpoints cannot do TLS 1.3 at all
• F — obsolete TLS, or nothing reachable

Most of the internet is a C today. That is not a scandal; it is the starting line.

This is an outside-in scan. It sees what the internet can see: your public endpoints and your public certificates. It cannot see cryptography inside your code, your internal services, your key stores, or your databases. A complete inventory needs that too — but the outside is where harvest-now-decrypt-later actually happens, and it is where you can start without giving anyone access to anything.