Post-quantum priority starts in the records retention schedule

The week

On August 13, 2024, the National Institute of Standards and Technology (NIST) released its first three finalized post-quantum cryptography standards. NIST is the federal agency that sets many of the technical standards American government and industry rely on. The new standards are encryption methods designed to resist attack by quantum computers as well as ordinary ones.

The problem they address is large. Almost everything private that travels across the internet today, from a wire instruction to a lab result to a tax return, is protected by encryption. Encryption is mathematics that scrambles information so that only someone holding the right key can read it. The most widely used kinds rely on math problems that ordinary computers cannot solve in any useful amount of time. A sufficiently powerful quantum computer, a different kind of machine that exploits the physics of very small particles, could in principle solve some of those problems. When that happens, a great deal of today’s protection stops working.

The three standards each have a formal number and a short name. FIPS 203, known as ML-KEM and derived from an algorithm called CRYSTALS-Kyber, covers key establishment: the handshake two computers use to agree on a secret key before they talk. FIPS 204 (ML-DSA, from CRYSTALS-Dilithium) and FIPS 205 (SLH-DSA, from SPHINCS+) cover digital signatures, the electronic equivalent of a tamper-proof seal that proves who sent something and that it has not been altered. A fourth, signature standard based on an algorithm called FALCON, to be named FN-DSA, was announced as still in development.

The letters FIPS matter to readers outside government. A Federal Information Processing Standard is binding on federal agencies for their non-national-security systems. It also travels well beyond them. Vendors who sell to government build to FIPS, regulated firms ask for FIPS-validated products in contracts, and auditors treat FIPS as a reasonable benchmark. A standard with that label tends to become the default setting in commercial software.

The two signature standards were not redundant. ML-DSA was the primary choice. SLH-DSA rests on a different kind of mathematics, based on hash functions, and NIST described it as a backup in case the approach behind ML-DSA proved vulnerable. That design choice, a primary and a fallback built on unrelated math, set the tone for what followed.

An eight-year contest

The release closed a long public contest. NIST had opened it with a call for submissions in 2016, inviting cryptographers worldwide to propose and then attack candidate algorithms. According to NIST, it received 82 algorithms from 25 countries. Successive rounds narrowed the field, and in July 2022 NIST named the four algorithms it would standardize: CRYSTALS-Kyber, CRYSTALS-Dilithium, SPHINCS+ and FALCON. Draft standards followed in 2023. NIST said the final versions contained no substantive changes from the drafts beyond renaming.

The contest also showed why caution was warranted. In 2022, two candidates that had reached the later rounds, the signature scheme Rainbow and the key-establishment scheme SIKE, were broken by researchers using ordinary computers. Neither had been chosen for standardization, but the breaks were a public reminder that new cryptography can fail in ways nobody anticipated.

NIST said that week that it was still evaluating two further sets of algorithms as possible backups. One was a small group of key-establishment candidates based on different math, from which it planned to pick one or two by the end of 2024. The other was a larger group of additional signature schemes, gathered through a separate call. NIST was explicit that these would be backups to the three new standards, and it urged organizations to begin migrating now rather than wait for further standards.

The policy frame already in place

The announcement did not arrive in a vacuum. National Security Memorandum 10, issued in May 2022, had already set a goal of mitigating quantum risk to federal systems by 2035. The National Security Agency’s CNSA 2.0 guidance had already set transition expectations for national security systems. In November 2022 the Office of Management and Budget issued memorandum M-23-02, directing agencies to inventory quantum-vulnerable cryptography on prioritized systems. The Quantum Computing Cybersecurity Preparedness Act followed in December 2022.

A month before the standards, in July 2024, OMB sent Congress a report under that Act. It projected that migrating prioritized federal systems between 2025 and 2035 would cost approximately $7.1 billion in 2024 dollars, excluding national security systems. The report’s prioritization criteria included systems holding data expected to remain mission-sensitive in 2035.

Some of the private sector had moved early too. Signal added a hybrid key agreement using Kyber in September 2023, and Apple announced a Kyber-based protocol for iMessage in February 2024. Both combined the new algorithm with a classical one, so an attacker would have to break both.

What changed that week was that the destination was finally written down. Every bank, hospital and agency now knew what to migrate to. The open question, and the subject of this piece, was what to migrate first.

A thief who cannot open your safe today can still carry it away and wait. That threat is what makes post-quantum cryptography urgent, and it is why the August 2024 standards matter to people who will never read a line of code.

Most commentary on the release treated it as an algorithm story or a discovery story. The algorithm story asks which new methods to choose. The discovery story asks where, across thousands of systems, cryptography is actually used. Both matter. But for a regulated organization, the first real decision is sequencing: what to fix first, second and last. And the threat that justifies urgency also tells you how to sequence.

The threat has a name: “harvest now, decrypt later.” An adversary records encrypted traffic, or copies encrypted archives, today. They cannot read it yet. They store it and decrypt it once a capable quantum computer exists. Under that model, your exposure depends on two things only: when the data was captured, and how long it must stay confidential. Those two facts split every flow of data into three time classes that do not overlap and together cover everything. They are data already exposed before migration, data that will move while migration is under way, and data created after it. Each class calls for a different response, and only one of them is mainly a technology problem.

The sections below take the mechanics first, then each time class in turn, then the reasons the program needs senior ownership, the ways programs fail, and a sequence that puts the classes in order.

Two kinds of cryptography, and the handshake at risk

Modern secure communication uses two broad kinds of cryptography, and they play different roles.

Symmetric encryption uses a single shared key to lock and unlock data. It is fast and protects the bulk of data, whether it is moving across a network or sitting on a disk. Well-chosen symmetric encryption is generally considered far less exposed to quantum attack.

Public-key cryptography solves a harder problem: how two parties who have never met agree on that shared key in the first place, over a network anyone could be listening to. It uses a pair of keys, one public and one private. The public key works like a padlock you hand out freely: anyone can snap it shut on a box, but only you hold the key that opens it. Public-key methods also produce digital signatures, which prove that a message, a software update or an identity credential is genuine. The familiar public-key algorithms, such as RSA and elliptic-curve schemes, are the ones a large quantum computer could break.

So the data itself may be locked with a strong symmetric key. But if the key was handed over using a quantum-vulnerable handshake, an adversary who recorded the handshake can one day recover the key and open everything it protected. The new ML-KEM standard replaces that handshake. ML-DSA and SLH-DSA replace the signatures.

Why the symmetric layer is the lesser worry

The known quantum attack on symmetric ciphers gives a speed-up, not a collapse. It roughly halves the effective strength of a key, so the standard response is longer keys rather than new mathematics. That is why NSA’s CNSA 2.0 suite specifies AES with 256-bit keys, and why most organizations already running AES-256 have little symmetric work to do. The urgent work is on the public-key layer, where the math itself fails.

This distinction keeps budgets honest. A vendor pitch for “quantum-safe storage” that only re-encrypts data at rest with a longer symmetric key may be solving the smaller problem. The useful question is how that storage system’s keys are wrapped, exchanged and backed up.

Where the handshake hides in a regulated enterprise

Public-key key exchange is not confined to websites. In a typical bank, health system or agency it runs inside:

• Web and API traffic, through TLS, including the internal service-to-service calls between applications.
• Site-to-site and remote-access VPNs, which use their own key-exchange protocols to set up tunnels between data centers, branches and clinics.
• Secure file transfer, such as SFTP links to processors, clearinghouses, servicers and state systems.
• Email encryption, including the certificate-based secure messaging many health systems use to exchange clinical documents.
• Key management, where hardware security modules and cloud key services wrap the keys that encrypt databases and backups.
• Identity, where smart cards, certificates and single sign-on tokens rely on public-key signatures.

Each of these has a different owner, a different vendor and a different upgrade cycle. A browser update can move web traffic in a quarter. A VPN concentrator or a backup appliance may move only when it is replaced.

Two more terms come up in any meeting with a technology team. Hybrid key exchange runs a classical algorithm and ML-KEM together, so an attacker would have to break both: a belt-and-suspenders approach for a period when the new algorithms are still young. Crypto-agility is the ability to swap one algorithm for another through a setting or a vendor update rather than by rewriting software. Both return below.

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 be 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 useful, because it moves the response out of the server room and into a conversation every executive already understands. For historical exposure, the response is 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, meaning the documented, policy-based deletion of records once their required retention period has ended, 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. Those records may need to be kept. They may not need to be online, replicated widely or sent routinely across networks.

Suppose a regional bank discovers, during a records review, that it keeps every customer statement and correspondence file indefinitely, “just in case,” and copies the whole archive nightly to a second data center. Its legal obligation covers a fraction of that history. Every extra year of records it holds and moves is another year of material an adversary might already have captured, and might one day read. Applying the retention schedule it already has does nothing to undo past captures. It does shrink the pile that keeps being exposed, and it reduces what a future decryption could reveal about current and former customers.

Two numbers, not one

A retention schedule records how long a record must be kept. It does not record how long the record stays harmful if revealed. The two are different, and post-quantum planning needs both.

The retention period is set by law and policy. A bank keeps many Bank Secrecy Act records for five years. A broker-dealer keeps books and records under SEC Rule 17a-4 for periods that run to six years for some categories. HIPAA requires covered entities to keep their compliance documentation for six years, while state law usually governs how long the medical record itself is kept. A federal agency may destroy records only under a disposition schedule approved by the National Archives.

The sensitivity horizon is a judgment about harm. A card number loses most of its value when the card is reissued. A Social Security number, a diagnosis, a genome or the identity of a confidential informant can do damage for a lifetime. For post-quantum purposes, the second number drives priority, and the first decides what you can lawfully stop holding.

Putting both numbers on each data class, in one table, is a small piece of work with a large payoff. It shows records that are kept far past their legal period and still highly sensitive: the best candidates for disposition. It also shows records that must be kept a long time and stay sensitive throughout: the flows whose movement deserves the earliest protection.

What disposition takes

Deleting records sounds simple and is not. A defensible program needs a records owner for each class, a check against legal holds before anything is destroyed, and evidence that destruction happened. Litigation holds and regulatory investigations freeze disposition for the records they cover, and a security project must never override them.

Backups complicate the picture. Records deleted from production often survive in backup copies until those copies expire. Immutable backups, which many organizations adopted to resist ransomware, are designed to be hard to alter. The practical answer is usually to align backup retention with the records schedule going forward, not to edit old backups.

There is also a trade-off to state openly. Disposition reduces exposure, but it also removes records that analytics teams, fraud models or researchers may want. That is a legitimate business tension, and it belongs with the executive who owns the data, not with the security team.

The practical step is to put the records manager and the security architect in the same room. For each data class the question is how long it is kept, why, and whether it ever leaves the building encrypted under keys that a future adversary could attack. That conversation rarely happens on its own, because the two roles usually report to different leaders and speak different languages. A senior executive can make it happen with one calendar invitation.

Data that moves during migration: the window you can shorten

Here 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. Technology teams, reasonably enough, like to start with what is simple and visible. The risk lies elsewhere.

Card authorization traffic illustrates the gap. It is high-volume and highly visible, but its secrecy horizon is short. A stolen session key from 2024 is worth little in 2040, because the transaction it protected is long settled and the card long reissued. 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, backups shipped to cloud storage. A medical history or a mortgage file can still harm someone decades after it was sent. Those links deserve hybrid key exchange first, even if they run on older equipment and cost more to change.

Building the ranking, step by step

A workable ranking does not need a perfect inventory. It needs five facts about each significant flow of data:

1. What data it carries, by class, using the classification scheme the organization already has.
2. The sensitivity horizon of that class, from the table described above.
3. Volume and concentration. A link that carries an entire patient database nightly matters more than one that carries a few records an hour.
4. Where it travels. Traffic over the public internet is easiest to record, but private circuits and carrier networks are not immune to interception.
5. What it would take to change: a configuration setting, a vendor upgrade, or a hardware replacement.

The first four set the priority. The fifth sets the method and the cost. Keeping them separate stops the easy-to-change items from floating to the top for the wrong reason.

Most organizations can build a first version from sources they already have. These include the data-flow diagrams prepared for privacy assessments, the third-party inventory, the firewall rules that permit outbound file transfers, and the list of backup and replication jobs. The cryptographic inventory then fills in which algorithm each flow uses.

How the ranking differs by organization

The method is the same everywhere, but the answers differ.

A regional bank tends to find its long-lived data in core-processor connections, loan servicing transfers, document imaging archives and offsite backups. Much of that runs through vendors, so the bank’s main tool is the contract: asking its core provider and servicers when they will support hybrid key exchange on the links it uses.

A credit union usually depends even more heavily on a core provider or a shared service organization. Its realistic plan is to know which vendor links carry member data, ask the right questions at renewal, and coordinate with peers who use the same provider.

A broker-dealer or wealth manager holds client records with long sensitivity horizons and retention obligations under SEC rules. Its archives, often held by a third-party archiving provider, are a natural early target for questions about how keys are protected in transit and at rest.

A health system has some of the longest horizons of all. Diagnoses, behavioral health notes and genomic data stay sensitive for life. Its priority flows are often replication of the electronic health record, imaging transfers to cloud archives, and exchanges with health information exchanges and payers.

An ambulatory network may run its electronic health record as a hosted service. Its priority list is short and vendor-dependent, which makes the contract and the vendor roadmap its main tools.

A federal agency already has a framework. M-23-02 required inventories of quantum-vulnerable cryptography on prioritized systems, and OMB’s 2024 report described priority for systems holding data expected to remain mission-sensitive in 2035. A county or city has no comparable mandate, but often exchanges long-lived data, such as court, health and child welfare records, with state systems it does not control.

Three controls that shorten the window now

Organizations do not have to wait for a full migration to reduce exposure. Three controls help immediately.

1. Prefer hybrid key exchange, which combines a classical algorithm with ML-KEM, on any channel where both ends support it. If the new algorithm turns out to have a flaw, the classical one still protects you against today’s attackers; if a quantum computer arrives, the new one protects you against tomorrow’s.
2. Consolidate bulk transfers. Move bulk transfers of long-lived data onto a small number of well-governed links, so there are fewer channels to upgrade. Ten partner file transfers set up by ten different teams over a decade are ten separate projects; one managed transfer service is one.
3. Follow the key as well as the data. 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.

Take a county health department. Its most sensitive data is not on the public website, which is easy to upgrade. It travels in a nightly replication job that copies clinical records to a backup site on an aging appliance nobody likes to touch. By the ranking above, that unglamorous link comes first. The website can wait.

The costs of hybrid, and where it breaks

Hybrid key exchange is not free. ML-KEM’s keys and ciphertexts are much larger than elliptic-curve ones: for the commonly used ML-KEM-768 setting, the public key is 1,184 bytes and the ciphertext 1,088 bytes. That makes the opening messages of a connection larger. Some older network devices that inspect or forward traffic mishandled the bigger messages when browsers first enabled hybrid modes.

TLS inspection deserves particular attention. Many banks and agencies decrypt outbound and inbound traffic at a proxy to scan it, then re-encrypt it. If the proxy supports only classical key exchange, one leg of every connection stays classical, whatever the endpoints support. The inspection layer can silently cap the organization’s protection at the old level.

Federal agencies and their suppliers face a further constraint. They generally need cryptographic modules validated under FIPS 140, and validation takes time. A product may support ML-KEM well before a validated version is available, which forces a choice between waiting and running unvalidated code on a sensitive link. Organizations in that position should check with counsel and their authorizing official before deciding.

These are not reasons to wait. They are reasons to test hybrid modes on priority links early, in a controlled way, before a deadline forces the change. A short pilot on one replication link, with the network, security and application owners watching together, will surface most of the device, inspection and validation problems an organization is likely to meet. It also produces something more useful than a slide: measured performance, a list of devices that failed, and a realistic estimate of the effort for the remaining links.

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. When an algorithm is compromised, an organization whose every application fitted its own cryptography faces months of work; one that runs cryptography from a few shared services changes a setting.

Crypto-agility is mostly a contracting and architecture decision, which is why it belongs with senior management. 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. (TLS is the protocol behind the padlock icon in a web browser; a “termination layer” is the shared front door where that protection is applied for many systems at once.)

What agility looks like in a contract

Contract language does not need to be exotic. Useful clauses ask the vendor to:

• Disclose the cryptographic algorithms, libraries and key lengths the product uses, and keep that disclosure current.
• State a roadmap for supporting the NIST post-quantum standards, including hybrid modes, with target dates.
• Commit to replacing a deprecated or broken algorithm within a defined period after NIST or another named authority withdraws it.
• Allow the customer to select or restrict algorithms through configuration.
• Notify the customer when a product update changes the cryptography it uses.

The disclosure clause matters most in year one. Some software bill of materials formats added fields for cryptographic assets around this time, so the request is becoming routine rather than unusual. For smaller institutions with little negotiating weight, joining peers or an industry association in asking the same vendor the same question is often more effective than negotiating alone.

Why signatures belong here

Signatures belong mostly in this third class. Their risk is forgery after a quantum computer exists, not retrospective decryption. A signature on a 2024 payment message cannot be harvested and abused in the same way as an encrypted record. By the time it could be forged, the message has long since been acted on. That gives more time.

But the work is slower. Payment messaging, firmware signing and identity credentials require counterparties and hardware to change together. A bank cannot change the signature scheme on payment messages alone; its counterparties must change too. A hospital cannot re-sign the firmware on infusion pumps without the manufacturer. Planning can wait for the data flows; an inventory of signing hardware should not, because hardware replacement cycles are long and procurement lead times are longer.

Two kinds of signature carry unusually long lives. Root certificates, the anchors of a public-key infrastructure, are often issued for decades. Hardware roots of trust, the keys burned into chips to verify that firmware is genuine, may last as long as the device. A medical device or a branch network appliance bought in 2025 may still be in service well into the 2030s. Its ability to accept a post-quantum signature is decided at purchase, which makes procurement the control point.

Agencies face the same issue with identity. Federal smart cards and the certificate systems behind physical and logical access depend on public-key signatures. Replacing them touches card stock, readers, door controllers and every application that checks a certificate. That kind of change is planned in budget cycles, not sprints.

A migration that cannot be delegated and forgotten

Post-quantum migration cannot be handed off as a technical upgrade, for four reasons.

The cost is front-loaded and the benefit is invisible. Done well, migration produces nothing anyone will notice: no new feature, no faster service. That makes it easy to defer in every budget cycle, and senior attention is often the only thing that keeps it funded. The scale is not trivial. OMB’s 2024 estimate of about $7.1 billion covered only prioritized federal civilian systems over a decade.

The harm, if it comes, is retrospective. A breach of harvested data would not look like a conventional breach. There would be no intrusion to detect at the time, only the eventual appearance of information that was thought to be safe. Customers, patients and citizens will not care that the data was stolen years before it was read; they will ask why it was kept and how it was protected.

Government has already set the frame. For federal systems, National Security Memorandum 10 set a 2035 goal, and CNSA 2.0 set expectations for national security systems. Suppliers to government, and regulated firms that look to federal standards, can expect those expectations to travel down supply chains.

It cuts across functions. The decisions that matter most here are how long records are kept, which vendors are chosen, what contracts require and which old appliances get replaced. Those decisions rest with records management, procurement, finance and business owners as much as with the security team. Someone senior has to join them up.

The case for waiting, and why it falls short

The strongest counter-argument deserves a fair hearing. Nobody knows when, or whether, a cryptographically relevant quantum computer will exist. The new algorithms are young, and two candidates from the same contest were broken on ordinary computers in 2022. Products, validations and protocols were still maturing in 2024. On that view, early movers pay more, debug immature code and may have to redo the work.

Each part of that argument has an answer. Hybrid key exchange protects against an immature algorithm, because the classical half still holds. Retention cleanup and data-flow ranking pay off whatever the quantum timeline, because they also shrink the damage from an ordinary breach. Crypto-agility makes any redo cheaper, which is the point of building it. And the long-lived data problem does not wait for certainty: data captured in 2024 is exposed whenever the machine arrives.

Where the argument does hold is in the details. Rewriting low-value systems in 2024, or replacing working hardware early only to install post-quantum features, would have been poor value. The sensible position was to move the long-lived flows early, demand agility at every renewal, and let the rest follow normal replacement cycles.

What an examiner or auditor will look for

In 2024, US banking and health regulators had no quantum-specific rule for most of the organizations they supervise. Examiners and auditors were more likely to approach the topic through existing expectations: information security programs, third-party risk management, asset inventories and board reporting. The evidence that answers those questions is predictable:

• A named executive owner and a charter for the program.
• An inventory of cryptography, scoped to priority systems first, with a date and an update process.
• The data-flow ranking, showing the criteria and who approved them.
• Vendor responses on post-quantum roadmaps, filed with the third-party risk records.
• Periodic reporting to a risk committee, showing progress against milestones.

Federal agencies have a more formal version of the same evidence, through their annual inventory submissions under M-23-02.

Where programs go wrong

A well-run program has an executive owner who can convene records, security, procurement and the business. It begins with a data-flow ranking based on sensitivity and secrecy lifetime, not a list of systems sorted by convenience. It uses the existing retention schedule as an early, low-cost lever. It sets a policy of hybrid key exchange where both ends support it, and writes algorithm configurability into new contracts as a matter of routine. It also keeps a living inventory of where cryptography is used, updated as systems change, rather than a one-time spreadsheet.

The failures are just as recognizable:

• Treating the inventory as the goal. A cryptographic inventory serves all three time classes, but it is a means. Programs that spend two years cataloguing every certificate before changing anything have protected nothing in the meantime.
• Starting with the easy, visible systems. Upgrading the public website first feels like progress. If the long-lived records travel over an old replication link, the exposure that matters has not moved.
• Hard-coding the new algorithms. Swapping RSA for ML-KEM inside application code simply recreates the original problem with a new name.
• Ignoring keys at rest. Assuming backups are safe because they are “encrypted,” without asking how the encryption keys were exchanged or wrapped.
• Keeping everything forever. Over-retention is a cost, a privacy risk and, under harvest now, decrypt later, a future decryption target.
• Leaving signatures until the end. Signature migration can follow the work on data in transit, but signing hardware has long lead times. Skipping the inventory now guarantees a scramble later.
• Forgetting the middle of the connection. Proxies, load balancers and inspection devices can strip post-quantum protection even when both endpoints support it.
• Running it as a one-off project. A program that disbands after its first milestone leaves nobody to handle the next algorithm change, which NIST’s own backup plans make likely.

Metrics that show movement

A small set of measures tells a board whether the program is working. Useful ones include the share of top-ranked data flows using hybrid key exchange and the volume of records still held past their retention period. Two more are the share of in-scope vendor contracts with cryptographic disclosure and replacement clauses, and the count of signing devices with a known replacement path. Each should have an owner and a target date. Counts of certificates catalogued, on their own, measure effort rather than reduced exposure.

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.

Translated into a calendar, a first pass might look like this for a mid-sized organization:

1. First quarter. Name an owner. Build the two-number table for data classes. List the replication, backup and bulk transfer flows. Send a standard cryptography questionnaire to the vendors behind those flows.
2. First year. Act on retention for the worst over-held data. Pilot hybrid key exchange on two or three priority links. Add disclosure and replacement clauses to every new and renewed contract. Start the inventory of signing hardware.
3. Years two to five. Move the remaining priority flows as vendors deliver support. Retire or isolate equipment that cannot be upgraded. Plan the signature migration with counterparties, card and device suppliers, and the certificate platform.

The calendar is illustrative, and each organization will compress or stretch it. The order is the part that should not change.

A cryptographic inventory serves all three, but it is a means. The retention schedule tells you which part of the inventory to complete first. The most useful first planning document for a quantum-era migration turns out to be the records retention schedule, not a technical architecture diagram. It is a document most organizations already have and few connect to cybersecurity.

Where the long-lived data travels

• Which of our data must stay confidential for ten years or more, and how does it travel between our sites, our backups and our partners?
• Are we keeping any records longer than our retention schedule requires, and who has authority to dispose of them?
• Which of our replication, backup and partner file-transfer links still use only classical key exchange, and what would it take to move them to hybrid key exchange?
• Do our vendor contracts say which algorithms products support, whether they are configurable, and how quickly a deprecated one can be replaced?
• Do we have an inventory of signing hardware, including payment, firmware and identity systems, and do we know which counterparties must move with us?

With hindsight

In November 2024 NIST released a draft transition plan (NIST IR 8547). It proposed that quantum-vulnerable public-key algorithms such as RSA and elliptic-curve schemes be disallowed after 2035, with their weaker 112-bit-strength versions deprecated after 2030. That turned a vague “someday” into a planning horizon: roughly a decade, with an earlier milestone for the weakest settings. Two years on, the time-class view has held up, and the calendar has filled in around it, faster than that decade suggested.

In March 2025 NIST selected HQC as a backup key-establishment algorithm to ML-KEM. HQC rests on error-correcting codes rather than the lattice mathematics behind ML-KEM, and NIST said a final standard was expected in 2027. That choice confirmed the case for agility over a one-time swap. Standards bodies were openly planning for the possibility that a new algorithm might need a stand-in. Organizations that had built the ability to switch by configuration were better placed than those that had hard-coded their first choice. In September 2025 NIST also finalized SP 800-227, its recommendations for using key-encapsulation mechanisms such as ML-KEM.

National timelines arrived from several directions. In March 2025 the UK’s National Cyber Security Centre set three milestones: discovery and an initial plan by 2028, highest-priority migrations by 2031, and full migration by 2035. 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 and to migrate high-risk use cases by the end of 2030. The target was to complete the transition for as many systems as practically feasible by 2035. Putting high-risk use cases first is close to the sequencing argued here: prioritize by consequence, not by convenience.

The financial sector got its own reference point. The G7 Cyber Expert Group, which brings together financial authorities from the G7 countries, published a roadmap for the sector’s transition. It pointed to 2035 as the common overall target and suggested addressing the most critical systems in 2030 to 2032. It also stressed third-party dependencies, especially for smaller institutions that rely heavily on vendors.

In the United States, Executive Order 14306 in June 2025 directed CISA to publish a list of product categories in which post-quantum support was widely available. It also required agencies to support TLS 1.3 or a successor by January 2, 2030. CISA’s list appeared in January 2026, after its December 2025 deadline. It named cloud platforms, collaboration software, web software and endpoint security as categories where support was widely available, and listed networking, identity and storage products among those still transitioning.

The biggest change came in June 2026. Executive Order 14412 and OMB memorandum M-26-15 set December 31, 2030 for agencies to move high value assets and high impact systems to post-quantum key establishment, and December 31, 2031 for signatures. The memorandum told agencies to prioritize systems holding data expected to remain mission-sensitive in 2030, five years earlier than the 2035 horizon used in OMB’s 2024 report. It also told agencies to fold post-quantum upgrades into cloud migrations and hardware refreshes, and to mark systems that cannot support the new cryptography for replacement. The order directed the FAR Council to propose a rule requiring covered contractors to comply with FIPS, including the post-quantum standards, by the end of 2030. It also asked CISA to define the minimum elements of a cryptographic bill of materials.

Hybrid key exchange spread quickly through browsers, major cloud providers and mainstream libraries such as OpenSSL, whose 3.5 release in April 2025 added the new NIST algorithms. OpenSSL is one of the most widely used building blocks for encryption on the internet, so its support carried the new methods into a great many products. Much ordinary web traffic gained protection through routine updates, without most organizations doing anything special.

That success had a revealing edge. The links that stayed classical longest were the ones described here: replication, backup and partner file transfer, often on older appliances. These are exactly the flows that carry long-lived data, and exactly the ones that do not update themselves. CISA’s own list placed networking, storage and identity products in the transitioning column. The industry solved the easy part of the problem; the important part remained each organization’s own job.

One part of this article’s framing aged less well. In 2024 it was natural to talk about a decade. For federal agencies and the contractors that serve them, the deadline for the most important systems is now 2030, and the private sector’s reference points have moved toward the same window. Organizations that used 2024 and 2025 to rank their flows and fix retention have a plan to execute. Those that waited for certainty have four years, not ten.

A quantum migration has turned out to be less about buying new technology than about knowing your data: what you keep, why, how long it must stay secret and how it moves.