Post-quantum priority starts in the records retention schedule

The week

On August 13, 2024, the National Institute of Standards and Technology published its first three finalized post-quantum cryptography standards: FIPS 203 (ML-KEM, derived from CRYSTALS-Kyber) for key establishment, and FIPS 204 (ML-DSA, from CRYSTALS-Dilithium) and FIPS 205 (SLH-DSA, from SPHINCS+) for digital signatures. A further signature standard based on FALCON was announced as still in development. The release closed a public selection process NIST had started in 2016. NIST urged organizations to begin migrating rather than wait for further standards. The publication sat inside an existing federal policy frame: National Security Memorandum 10 (May 2022) set a goal of mitigating quantum risk to federal systems by 2035, and NSA’s CNSA 2.0 guidance had already set transition expectations for national security systems.

Most commentary on the August 2024 release treated it as an algorithm story or a discovery story: pick the new algorithms, then find every place cryptography is used. Both matter. But for a regulated organization the first decision is sequencing, and the threat model that justifies urgency also tells you how to sequence. The concern is “harvest now, decrypt later”: an adversary records encrypted traffic or copies encrypted archives today and decrypts them once a capable quantum computer exists. Under that model, exposure depends on two things only: when the data was captured, and how long it must stay confidential. That splits every data flow into three time classes, which do not overlap and together cover everything: data already exposed before migration, data that will move while migration is under way, and data created after it.

Data already exposed: a sunk risk that changes retention, not cryptography

Anything that crossed a network under classical key exchange before an organization migrates may already sit in an adversary’s store. Nothing done in 2024 or later re-protects it. Migration only shortens the window for data captured from here on.

This is uncomfortable, but it is useful. The response for historical exposure is therefore a records question. A health system that keeps decades of imaging and genomic results online, or a bank that retains full account histories far beyond its legal obligation, carries more harvestable value than it needs to. Defensible disposition under the existing retention schedule reduces what a future decryption could reveal. The same logic applies to agency investigative files and sealed records, where legal retention is long but access patterns are narrow.

The practical step is to put the records manager and the security architect in the same room. The question for each data class is: how long is it kept, why, and does it ever leave the building encrypted under keys that a future adversary could attack?

Data that moves during migration: the window you can shorten

This is where effort pays. Migrations of widely deployed cryptography take years, and every month a high-value flow stays on classical key exchange adds to the harvestable pool. The ranking criterion is the product of two numbers you already have: how sensitive the data is and how long it must stay secret.

Applied honestly, that ranking rarely matches the order in which systems are easiest to upgrade. Card authorization traffic is high-volume but its secrecy horizon is short; a stolen session key from 2024 is worth little in 2040. Other flows are lower-profile but carry data whose confidentiality must outlast any reasonable quantum estimate. Examples include bulk replication of clinical records to a disaster recovery site, loan files sent to a servicer and backups shipped to cloud storage. Those links deserve hybrid key exchange first, even if they run on older equipment and cost more to change.

Three controls make the window shorter without waiting for full migration. First, prefer hybrid key exchange, which combines a classical algorithm with ML-KEM, on any channel where both ends support it. Second, move bulk transfers of long-lived data onto a small number of well-governed links, so there are fewer channels to upgrade. Third, find where data at rest is encrypted with keys that are wrapped or exchanged using public-key cryptography. A backup encrypted with a symmetric key is only as safe as the way that key was exchanged.

Data created after migration: an agility problem, not a one-time swap

Once a flow is on post-quantum or hybrid cryptography, the risk does not disappear. It changes shape. The new algorithms are young, implementations will have bugs, and NIST itself planned additional and backup algorithms. Organizations that hard-code ML-KEM in 2025 will face the same rewrite again if a weakness emerges.

The durable property is crypto-agility: changing an algorithm through configuration and procurement rather than through code. That is mostly a contracting and architecture decision. Contracts can ask vendors to state which algorithms their products support, whether they are configurable, and how quickly a deprecated algorithm can be replaced. Architecture can route cryptography through a small set of shared services, such as a key management service, a certificate platform and a TLS termination layer, instead of letting each application carry its own libraries.

Signatures belong mostly in this third class. Their risk is forgery after a quantum computer exists, not retrospective decryption. That gives more time, but the work is slower: payment messaging, firmware signing and identity credentials require counterparties and hardware to change together. Planning can wait for the data flows; inventory of signing hardware should not.

Putting the classes in order

The three classes give a sequencing rule that a board can understand. Reduce what is already exposed by disposing of what you no longer need. Shorten the window on long-lived data in motion first, starting with replication, backup and bulk transfer links. Build agility so that the next change is cheaper than this one. A cryptographic inventory serves all three, but it is a means. The retention schedule tells you which part of the inventory to complete first.

With hindsight

Two years on, the time-class view has held up, with some useful dates attached. In November 2024 NIST released a draft transition plan (NIST IR 8547) proposing that today’s common public-key algorithms be deprecated after 2030 and disallowed after 2035. In March 2025 NIST selected HQC as a backup key-establishment algorithm to ML-KEM, which confirmed the case for agility over a one-time swap. In June 2025 the EU’s NIS Cooperation Group published a coordinated roadmap. It asked member states to have national plans by the end of 2026, migrate high-risk use cases by the end of 2030 and finish by 2035. Hybrid key exchange spread quickly through browsers, major cloud providers and mainstream libraries such as OpenSSL. As a result, much ordinary web traffic gained protection through updates. The links that stayed classical longest were the ones described here: replication, backup and partner file transfer, often on older appliances. Later articles in this series follow the inventory and vendor-roadmap work that came next.