Harvest now, decrypt later
It isn't the flashiest quantum story. No one breaks in, nothing goes down, no ransom note. An adversary with patience and storage records your encrypted traffic today and files it away. The key exchange that protected it, the classical maths behind X25519, ECDHE and RSA, is the part a large enough quantum computer is expected to undo. When that day comes, the recording opens. Not tomorrow's traffic. The traffic you sent years earlier.
People wave this away with "quantum computers can't do that yet". Correct, and beside the point. The attack happens in two halves, and the expensive half, the collection, needs no quantum computer at all. It needs a tap and a hard drive. The maths comes later, on someone else's schedule.
Your real exposure is shelf life, not cipher strength
Ask most teams how their crypto is doing and you'll hear about TLS 1.3 and strong ciphers. All true. It measures the wrong thing. The question that matters for harvest-now-decrypt-later is simpler and more uncomfortable: how long does what you just sent need to stay secret, and will the key exchange protecting it still be standing that long?
A session that carries a chat message nobody cares about in a fortnight is a shrug. A session that carries backup replication, health records, source code, legal discovery, or credentials that get reused for a decade is a different animal. Same TLS. Wildly different risk. The cipher suite tells you almost nothing about which one you're looking at. The data's shelf life does, and that's the number almost nobody is tracking.
The clocks are already set
The standards bodies have stopped hedging. The migration has a shape and a set of dates, and they're closer than a decade-long backup horizon.
NIST finalises the first post-quantum standards. FIPS 203 (ML-KEM), FIPS 204 (ML-DSA) and FIPS 205 (SLH-DSA). The replacement algorithms exist and are approved. The excuse that there was nothing to move to is gone.
Know your estate and have a plan. The UK's NCSC puts discovery and planning in this window: you can't migrate what you haven't found.
Migrate the highest-priority systems. The things whose data has the longest shelf life go first, which is exactly the traffic being harvested for later.
Migration complete. The NCSC's stated finish line. Anything recorded between now and your own migration is recorded under the old maths.
Read those dates next to your data retention policy. If you keep anything for seven years and you migrate in five, you've got two years of harvestable traffic already, and the meter is running.
It reads the wire and grades the exposure
PQCExpose is a passive tool. Point it at a capture file or a mirror port and it watches TLS handshakes go by. For each service it works out the key exchange in play, sorts it into post-quantum, classical, or static, weighs that against how long the data likely needs to stay secret, and turns the whole estate into a ranked report with an honest A to F grade.
It never touches payload. It reads the handshake, the metadata, the shape of the conversation, and nothing inside it. No decryption, no keys, no content, so you can run it across production traffic without becoming the risk you're trying to measure.
Every number on the report can explain itself
- Class: is this session's key exchange post-quantum, classical, or static (RSA transport or static DH, the ones with no forward secrecy at all)?
- Shelf life: how long this service's data plausibly needs to stay secret. It ships with sensible defaults and lets you declare your own, because you know your estate better than any heuristic does.
- Exposure and grade: the two combined, weighted by traffic volume, so a vulnerable service carrying most of your bytes moves the grade more than a quiet one.
Start free, scale when it matters
pqcexpose CLI
One binary. Feed it a pcap, get a self-contained HTML report plus JSON, CBOM, SARIF and CSV. The source is open to read, so you can check the passive, no-payload claim for yourself rather than take my word for it.
PQCExpose Sentinel
The standing version on a mirror port. Continuous monitoring, history and trends, alerting when a service slips back to classical, a war-room wall for a big screen, and a fleet rollup across sites. Same engine as the CLI, so the free tool and the paid one agree on every number.
Run the free tool first. If the grade is fine, you've lost ten minutes.
If it isn't, you now know which services to move first and why, in language a board will sit still for. That's the whole idea. No fear, no countdown clock you can't act on, a ranked list and a number you can defend.
Every estate has one. Not the customer-facing service the team frets over, that's usually on modern TLS. It's the quiet internal thing nobody's touched in years: a legacy LDAP directory or an industrial gateway still pinned to static RSA over TLS 1.0, with no forward secrecy, happily authenticating half the building. It never shows up in the quarterly review because it never breaks. PQCExpose finds it because it doesn't care what breaks. It cares what's being recorded.
Sources: NIST post-quantum standards FIPS 203 / 204 / 205, finalised August 2024 (csrc.nist.gov). UK NCSC, "Timelines for migration to post-quantum cryptography", 2028 / 2031 / 2035 milestones (ncsc.gov.uk).