PQC StatusHarvest now, decrypt later (HNDL) is a patient attack: capture encrypted traffic today, store it, and decrypt it years later, once the key agreement that protected it no longer holds. It needs no quantum computer today, only capture capability and disk space. The useful question for a security team is therefore not when a cryptographically relevant quantum computer will exist, but how long each flow of data has to stay confidential, and which systems carry the flows with the longest lifetime.
The threat model, stated precisely
Separate the adversary into two capabilities that are separated in time.
- Today: collection. Passive capture at a network tap, an upstream transit provider, a peering point, a compromised load balancer or middlebox, or the theft of an archive of already recorded sessions. The ciphertext is stored, not read.
- Later: computation. Recovery of a private key from a public key. Shor's algorithm, on a large enough quantum computer, breaks RSA, ECDH, finite field Diffie-Hellman, ECDSA, EdDSA and DSA, whatever the key size. Moving from RSA-2048 to RSA-4096, or from one elliptic curve to a larger one, does not change that.
Symmetric cryptography behaves differently. AES, SHA-2 and SHA-3 are not broken by Shor. Grover's algorithm offers a smaller, quadratic advantage against symmetric keys, and that is the reason AES-256 is preferred where data must stay confidential for a long time. A recorded session is not at risk because AES-GCM protected the payload. It is at risk because of the way the AES key was agreed.
Forward secrecy does not solve this
TLS 1.3 always uses an ephemeral key agreement, in practice ECDH over X25519 or a NIST curve. Forward secrecy means that stealing the server's long-term private key tomorrow does not reveal yesterday's sessions, because the session secret came from ephemeral shares. But those ephemeral public shares travel in the clear inside the handshake. A recorded handshake therefore contains everything needed to reconstruct the session secret, for anyone able to solve that single key agreement instance. Forward secrecy protects against key theft. It does not protect against later cryptanalysis of the key agreement itself. That gap is the whole of the HNDL problem.
Why key exchange migrates first and signatures later
A signature is verified at the moment of the connection. If a signature algorithm becomes forgeable in ten years, that does not let anyone read a session recorded today: the session keys were never derived from the certificate. What a broken signature buys is impersonation in the future, and forged artifacts that stay trusted for a long time.
Hence the ordering that every official roadmap follows. Hybrid post-quantum key agreement comes first, built on ML-KEM, the key encapsulation mechanism (KEM) standardized as NIST FIPS 203 on 13 August 2024 (FIPS 203). Post-quantum signatures such as ML-DSA (FIPS 204) follow, for certificate chains. The hybrid TLS groups X25519MLKEM768, SecP256r1MLKEM768 and SecP384r1MLKEM1024 are in the IANA TLS parameters registry, and RFC 10024 (August 2026) specifies post-quantum traditional (PQ/T) hybrid key agreement for TLS 1.3. Current Chrome, Edge and Firefox offer X25519MLKEM768 by default, so for many public endpoints this is a configuration change rather than a project.
Later does not mean never, and two classes of signature deserve early attention anyway:
- Signatures whose verification must still be trusted after a long delay: firmware and software update signing, secure boot roots of trust, archive and document signatures, timestamping.
- Certificates and credentials with long validity, where reissuance is expensive or physically awkward: embedded products, industrial equipment, smart cards.
NSA CNSA 2.0, which applies to US National Security Systems, reflects that split. It expects exclusive use of ML-KEM-1024 and ML-DSA-87 by the end of 2030 for software and firmware signing and for traditional networking equipment, and by the end of 2033 for web browsers and servers, cloud services and operating systems.
Which data has a confidentiality lifetime long enough to matter
Confidentiality lifetime is the period during which disclosure would still cause harm. It is a business and legal property of the data, not a property of the protocol, and it is the one input to HNDL prioritisation that you fully control. Orders of magnitude are enough to start.
| Data category | Why the lifetime is long or short | Order of magnitude |
|---|---|---|
| Health, genomic and biometric data | Identifies a person for life and cannot be reissued | Decades |
| Government, defence and diplomatic material | Classification periods are set by policy, not by technology | Decades |
| Trade secrets, formulas, designs, source code | Value follows the lifetime of the product line | Years to decades |
| Legal privilege, litigation files, board and transaction material | Remains sensitive long after the deal or the case closes | Years to decades |
| Credentials and key material in transit | Inherits the lifetime of whatever they unlock | Years |
| Personal data held under retention obligations | Harm persists as long as the records exist | Years |
| Real-time prices, short session tokens, operational telemetry | Value decays quickly after capture | Days to months |
Two corrections that most inventories need. First, short-lived data inside a long-lived tunnel inherits the tunnel: a site-to-site link that also carries database replication has the lifetime of the database. Second, secrets in transit have the lifetime of the systems they open, not the lifetime of the request that carried them.
How to rank systems by data shelf life
For each system, write down two numbers. X is the confidentiality lifetime of the data it carries. Y is how long a migration of that system would realistically take, including client compatibility, appliance firmware and change windows. There is a third quantity, the moment the relevant computation becomes feasible, and nobody can put a credible date on it, so treat it as unknown. The tractable rule is what remains: shrink Y, and spend it first where X is largest, because traffic already recorded cannot be recalled.
| Tier | Criteria | Action |
|---|---|---|
| Move now | Confidentiality lifetime beyond about ten years, or the flow carries keys and credentials, or it crosses networks you do not control | Enable hybrid ML-KEM key agreement on the transport, prefer TLS 1.3 only, prefer AES-256 where the stack allows it |
| Plan next | Lifetime of a few years, internal traffic that still transits provider or partner networks | Attach the change to the next platform or appliance upgrade, enable hybrid groups as clients support them |
| Follow the platform | Lifetime under a year, no secrets or long-lived identifiers | Inherit the defaults of the operating system, library and browser |
This ranking needs an inventory to sit on. PCI DSS v4.0.1 requirement 12.3.3, mandatory since 31 March 2025, already asks for a documented inventory of cipher suites and protocols in use, reviewed at least every 12 months, with monitoring of their continued viability. The DORA regulatory technical standards, Commission Delegated Regulation (EU) 2024/1774, require in Article 6 an encryption policy that includes provisions for updating or changing cryptographic technology based on developments in cryptanalysis, and in Article 7 key management across the lifecycle plus a register of certificates for assets supporting critical or important functions. NIS2 Article 21(2)(h) requires policies on the use of cryptography. None of those texts names a data shelf life column: adding one to the inventory you already maintain is our interpretation of a practical way to evidence prioritisation, not a literal requirement. This article is information, not legal advice.
What the official timelines have in common
The published timelines differ in status and in wording, and the hedges matter. The EU Coordinated Implementation Roadmap v1.1 (published 23 June 2025) is coordinated guidance for Member States, not a regulation binding companies: first steps including a cryptographic inventory and national roadmaps by the end of 2026, high-risk use cases migrated by the end of 2030, medium-risk by the end of 2035. UK NCSC guidance sets discovery and an initial plan by 2028, highest-priority migrations by 2031 and completion by 2035. BSI TR-02102-1 (version 2026-01) is a technical guideline: it recommends hybrid key agreement and considers classical key agreement used alone acceptable only until the end of 2031, or the end of 2030 for very high protection needs. NIST IR 8547 remains an initial public draft; it proposes deprecating quantum-vulnerable algorithms at 112-bit security after 2030 and disallowing quantum-vulnerable public-key algorithms after 2035. ANSSI makes hybridation mandatory inside its regulated scope and states that its post-quantum recommendations are not yet regulatory obligations elsewhere. Our page on post-quantum migration deadlines keeps the dated detail in one place.
The shared structure is more informative than any single date: a highest-priority group around 2030 to 2031, the remainder by 2035, and a selection criterion for the first group that is essentially long data lifetime. That is the HNDL argument, written into public policy.
Check what your handshakes actually negotiate
Measure before planning. With OpenSSL 3.5 or later, which is the minimum version providing the ML-KEM TLS groups, ask for a hybrid group explicitly and read back what was negotiated:
openssl s_client -connect example.com:443 -tls1_3 \
-groups X25519MLKEM768 </dev/null 2>&1 | grep -i groupFor administrative access, check the key agreement of an SSH session. OpenSSH 9.9 (19 September 2024) added mlkem768x25519-sha256, OpenSSH 10.0 (9 April 2025) made it the default key agreement, and OpenSSH 10.1 (6 October 2025) warns when a connection negotiates a non post-quantum key agreement, via WarnWeakCrypto, enabled by default. The release notes are published at openssh.com.
ssh -v -o KexAlgorithms=mlkem768x25519-sha256 user@host 2>&1 | grep -i kexOrder the hybrid group first and keep a classical fallback behind it, for example X25519MLKEM768 then X25519, so older clients still connect. Test in staging before production, and watch handshake sizes on constrained links and on appliances that inspect the ClientHello.
Your next step
Start with the two artifacts that make the rest mechanical: a data shelf life column added to your cryptographic inventory, and a measurement of what your external endpoints negotiate today. For the second one you can scan your domain with PQC Status for free: it reports the hybrid ML-KEM groups offered, the TLS versions and cipher suites, and the certificate chain. A scan describes the externally visible TLS configuration only, so treat it as evidence for your inventory, not as a certification or a compliance attestation. Then take the systems in your move-now tier and put hybrid key agreement on them, in that order.