Quantum risk is dated by how long your data must stay secret
NSM-10 set 2035 as a national goal, but for any given agency system the effective deadline is earlier: how long its data must stay confidential, plus how long migration will take, measured against when a capable machine might exist.
Looking Back revisits one week at a time, from January 2020 to today, and asks what it meant for the banks, health systems and public agencies we serve. The series was written in 2026, with the benefit of hindsight, and each article says which week it looks back on.
The week
On May 4, 2022, the White House issued National Security Memorandum 10, on promoting U.S. leadership in quantum computing while mitigating risks to vulnerable cryptographic systems. The President also signed an executive order placing the National Quantum Initiative Advisory Committee directly under the White House. The memorandum set a goal of mitigating as much quantum risk as feasible by 2035. It directed federal civilian agencies to inventory their cryptographic systems that a future quantum computer could break, with the first inventory due within a year and updates annually after that. OMB later implemented those requirements in memorandum M-23-02, issued in November 2022. Two months after the memo, in July 2022, NIST announced the first four algorithms it had selected for post-quantum standardization. No computer able to break widely used public-key cryptography existed then, and the memo did not suggest one did.
Most coverage of NSM-10 asked when a cryptographically relevant quantum computer would arrive. That question has no reliable answer, and for agency planners it is the wrong place to start. The threat that justifies acting early is usually called harvest now, decrypt later. An adversary records encrypted traffic or copies encrypted files today, then stores them until a machine can break the key exchange that protected them. Data is exposed from the moment it is captured, not from the moment the machine exists.
That turns the planning problem around. Add the years a system’s data must stay secret to the years its migration will take. If the total exceeds the years before a capable machine appears, the system is already late. Agencies cannot control the last number. They can measure the first two. So a usable plan rests on three estimates: how long each body of data must stay confidential, how long each system will take to change, and the priority order that falls out when the two are combined.
How long the data must stay secret
Agencies already know more about data lifetimes than they think. Records schedules approved by the National Archives say how long each category of record must be kept. Classification guides set declassification dates. Privacy and statutory rules protect tax returns, health records, criminal history and personnel files for the life of the person, and often longer. Those sources were written for retention, not cryptography, but they answer the same question: how long would disclosure still cause harm.
The work is to attach a confidentiality lifetime to each major data set and then to the systems and network paths that carry it. A benefits case file that must stay private for decades sits at one end. A public meeting calendar sits at the other. Most data falls in between, and the useful distinction is often coarse: under five years, five to twenty, and longer than twenty. Getting the bands roughly right matters more than precision.
Two complications deserve attention. First, data in transit and data at rest face different exposure. Traffic captured on a network is vulnerable through its key exchange. Stored backups are exposed if they are copied while encrypted under keys that rely on vulnerable public-key methods. Second, derived data inherits sensitivity. An analytics extract built from long-lived records carries their lifetime, even if the extract itself is meant to be temporary.
How long the system will take to change
The second estimate is migration time, and it varies far more than most plans assume. A public website behind a modern load balancer may change algorithms through a vendor update and a configuration switch. A case management system with cryptography built into custom code, or a field device with a fifteen-year service life and fixed firmware, may need a rebuild or a replacement.
Migration time has several components. Discovery: finding where public-key cryptography is used, which is what the NSM-10 inventory was meant to produce. Dependency: waiting for a vendor, a library or a protocol standard to support new algorithms. Testing: post-quantum keys and signatures are larger, which can break older network equipment and applications that assume fixed message sizes. Procurement and funding: the budget cycle for replacing a system may be longer than the engineering work. An honest estimate adds these together, and the procurement step is often the longest.
This is also where crypto agility earns its value. Systems that call cryptography through maintained libraries and negotiated protocols shorten every future migration, not just this one. Writing that property into requirements for new systems is cheap. Adding it later is not.
The priority order the two estimates produce
Put the two estimates side by side and a ranking emerges that differs from a simple risk score. At the top are systems with long-lived data and long migration times: encrypted links carrying intelligence, law enforcement or health records over networks an adversary could tap, and archives protected by vulnerable key exchange. These may already be too late to wait. Next come systems with long-lived data but short migration times, which can usually wait for vendor support and then move quickly. Systems with short-lived data are lower priority even if they are hard to change, because by the time a machine exists their data no longer matters.
The ranking changes what agencies ask for in the near term. For the top tier, it can justify interim steps: reducing the volume of long-lived data sent over exposed links, adding layers of symmetric encryption with pre-shared keys where the architecture allows, and shortening how long sensitive data is retained at all. Deleting data that no longer needs to exist is the cheapest post-quantum control available.
The ranking also gives program directors a defensible answer to the budget question. A migration funded because a long-lived data set crosses an exposed network is easier to explain than one funded because quantum computing is in the news. And it gives records officers, privacy officers and enterprise architects a shared role in a problem that is too often handed to a few cryptographers.
With hindsight
The policy track accelerated. Congress passed the Quantum Computing Cybersecurity Preparedness Act in December 2022, putting inventory and migration planning into law for federal agencies. NIST published its first three post-quantum standards, FIPS 203, 204 and 205, in August 2024, and later that year proposed deprecating today’s widely used public-key algorithms and disallowing them by 2035. Major browsers and messaging services deployed hybrid post-quantum key exchange, which protects new traffic against harvesting. An executive order signed on June 22, 2026 set earlier federal deadlines for high-value and high-impact systems, with post-quantum key establishment due by the end of 2030 and signatures by the end of 2031. Earlier key establishment fits the harvest argument, since captured traffic is the exposure that cannot be undone. The arrival date of a capable machine is still unknown. The agencies best placed in 2026 are those that tied cryptographic inventories to data lifetimes, so they knew which links to fix first.