Post-quantum cryptography for records that must last

Most cryptography in use today relies on problems that a large enough quantum computer could solve. Nobody can say when such a machine will exist. For records that must stay confidential or verifiable for decades, that uncertainty is already a planning problem.

This article is for security architects and records owners: the people who decide how long data must remain protected and how long a signature on a record must remain believable.

Two different risks

Confidentiality: harvest now, decrypt later. An adversary can record encrypted traffic or copy encrypted archives today and decrypt them once a capable quantum computer exists. Data whose sensitivity outlives that date is exposed now, even though the decryption happens later. NIST’s transition guidance describes this risk, in which adversaries collect encrypted data now with the goal of decrypting it later, as a reason to begin migrating key exchange early [3].

Integrity and evidence: signatures that must still verify. A signature on a record proves who issued it and that it has not changed. If the signature algorithm can be broken in future, a forged signature on an old record becomes indistinguishable from a real one. Records that serve as evidence, such as disclosure logs, audit trails, signed reports and contracts, need signatures that remain trustworthy for as long as the record is kept.

The standards and the timelines

In August 2024, NIST published the first three post-quantum standards: FIPS 203 (ML-KEM), a key-encapsulation mechanism for establishing keys; FIPS 204 (ML-DSA), a lattice-based signature scheme; and FIPS 205 (SLH-DSA), a hash-based signature scheme [1]. In March 2025 NIST selected HQC, a key-encapsulation algorithm based on different mathematics, to serve as a backup for ML-KEM [2]. Standards for carrying ML-DSA in X.509 certificates and in signed messages followed in 2025 [7].

Governments have set migration timelines. NIST’s transition guidance, finalized in October 2026, deprecates today’s quantum-vulnerable public-key algorithms, including RSA, ECDSA, EdDSA and elliptic-curve Diffie–Hellman, after 2030 and disallows them after 2035 [3]. The US National Security Agency’s CNSA 2.0 sets dates by category for national security systems, for example exclusive use of the new algorithms for software and firmware signing by 2030 and for web browsers, servers and cloud services by 2033, with all national security systems quantum-resistant by 2035 [4]. The UK National Cyber Security Centre’s timeline, published in March 2025, asks organizations to complete discovery and planning by 2028, the highest-priority migrations by 2031, and migration of all systems by 2035 [5].

Symmetric cryptography is far less affected. Quantum search roughly halves the effective strength of a symmetric key, so AES with 256-bit keys and hash functions with long outputs, such as SHA-384, remain appropriate.

Deciding what to do first

A common rule of thumb, often attributed to Michele Mosca, compares three durations: how long the data must stay protected (x), how long the migration will take (y), and how long until a capable quantum computer exists (z). If x + y is greater than z, the data is already at risk. Since z is unknown and y is usually measured in years, the practical conclusion is to prioritize by x: start with the data and records that must remain protected longest.

For most organizations, that points to three places: long-lived confidential archives and backups, the links that carry them, and the signatures on records that may be needed as evidence years from now.

Hybrid key exchange and dual signatures

The new algorithms are younger than the ones they replace, so the common approach during transition is to combine them rather than switch outright.

• Hybrid key exchange. A connection derives its key from both a classical exchange, such as X25519, and ML-KEM, so it stays secure if either survives. Hybrid key exchange of this kind, such as X25519MLKEM768, was standardized for TLS 1.3 in 2026 [6] and is already offered by default by Chrome and by Apple’s operating systems, among others.
• Dual signatures. A record can carry both a classical signature, such as ECDSA, and an ML-DSA signature. A verifier that understands only one can still check it, and the record remains verifiable if either algorithm is later broken.

The costs are mostly size. An ML-DSA-65 signature is 3,309 bytes and its public key 1,952 bytes, against 64 and 32 bytes for an Ed25519 signature and key; an ML-KEM-768 ciphertext is 1,088 bytes [1]. That matters for certificates, constrained links and very large numbers of small records, and rarely for documents.

Keeping old signatures trustworthy

A signature only proves something if the verifier can still trust the algorithm, the key and the time it was made. For long-lived records, three practices help. Timestamp signatures with a trusted timestamping service, so the time of signing is itself provable. Renew protection before an algorithm weakens, by adding a new timestamp or signature over the existing evidence with a stronger algorithm; long-term signature formats for documents and evidence records are designed for this. And keep records in formats whose signatures can be checked offline and independently, so that verification does not depend on the issuer still existing.

A practical order of work

1. Inventory where public-key cryptography is used: connections, stored data, signatures, certificates and keys held by suppliers.
2. For each, record how long the protected data or record must stay confidential or verifiable.
3. Enable hybrid key exchange on the connections that carry long-lived sensitive data, where both ends support it.
4. Add post-quantum signatures beside classical ones on records that serve as evidence, starting with the longest-retained.
5. Prefer designs that can change algorithms by configuration rather than by rewriting software.
6. Ask suppliers for their migration plans and dates, and write them into contracts.

Sources

1. NIST. FIPS 203, Module-Lattice-Based Key-Encapsulation Mechanism Standard; FIPS 204, Module-Lattice-Based Digital Signature Standard; FIPS 205, Stateless Hash-Based Digital Signature Standard. 13 August 2024. csrc.nist.gov
2. NIST. Selection of HQC for standardization. nist.gov
3. NIST IR 8547, Transition to Post-Quantum Cryptography Standards (final, October 2026). csrc.nist.gov
4. National Security Agency. The Commercial National Security Algorithm Suite 2.0 and Quantum Computing FAQ (April 2024). media.defense.gov
5. UK National Cyber Security Centre. Timelines for migration to post-quantum cryptography. ncsc.gov.uk
6. IETF. RFC 10024, Post-Quantum Traditional (PQ/T) Hybrid Key Agreement Mechanisms for TLS 1.3 (August 2026). rfc-editor.org
7. IETF. RFC 9881, ML-DSA in X.509 certificates, and RFC 9882, ML-DSA in the Cryptographic Message Syntax (October 2025). rfc-editor.org