Quantum risk is dated by how long your data must stay secret

The week

Almost everything an agency sends across a network, from a tax return to a sealed court filing, is protected by mathematics that a sufficiently powerful quantum computer could one day undo. In the first week of May 2022, the White House decided it was time to start planning for that day.

On May 4, 2022, it issued National Security Memorandum 10, on promoting U.S. leadership in quantum computing while mitigating risks to vulnerable cryptographic systems. A national security memorandum is a formal presidential directive to the executive branch; this one did two jobs at once. It encouraged the country to stay ahead in quantum research, and it told agencies to prepare for the damage that research could eventually do to today’s encryption.

Some quick definitions help. Cryptography is the science of scrambling information so only the intended recipient can read it. Public-key cryptography is the variety that lets two parties who have never met agree on a secret key over an open network; it is what puts the padlock in a browser’s address bar. A quantum computer uses the physics of very small particles to tackle certain math problems in a fundamentally different way from ordinary computers, and some of those problems happen to be the ones public-key cryptography relies on.

The same day, the President also signed an executive order placing the National Quantum Initiative Advisory Committee directly under the White House, raising the profile of the experts who advise on the field.

The memorandum also explained its own urgency in terms planners could use. It noted that the first post-quantum standards from NIST and the National Security Agency were expected to be released publicly by 2024. It treated cryptographic agility, the ability to swap algorithms without rebuilding the systems around them, as an imperative across all sectors of the economy. And it set a goal of moving the maximum number of systems off vulnerable cryptography within a decade of the first standards being published.

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. The Office of Management and Budget, which oversees how agencies run, later implemented those requirements in memorandum M-23-02, issued in November 2022.

What the memo asked of whom

The directives were specific and staggered. Within 90 days, NIST was to start a Migration to Post-Quantum Cryptography project at its National Cybersecurity Center of Excellence, working with industry on tools to find and replace vulnerable cryptography. NIST was also to convene an open working group with industry and critical infrastructure operators. Within 180 days, OMB was to set the rules for how agencies would inventory their cryptographic systems. The Cybersecurity and Infrastructure Security Agency, CISA, was to engage critical infrastructure owners and state, local, tribal and territorial governments on the risk.

Agency inventories were to emphasize High Value Assets and high impact systems. High Value Assets are the systems an agency has designated as most critical to its mission. A high impact system is one where losing confidentiality, integrity or availability would be severe. The National Cyber Director was to report each year on migration progress, including the funding agencies would need.

National security systems, the classified and military networks overseen by the NSA, ran on a separate track. Their owners had to document their vulnerable cryptography within a year. By the end of 2023 they also had to add symmetric-key protections where appropriate, an interim measure that does not depend on the public-key methods at risk.

One instruction cut against intuition. Until NIST finished its first standards, civilian agencies were told not to buy commercial quantum-resistant products for their enterprise and mission systems. They could test such products for interoperability. The aim was to avoid locking agencies into early, unstandardized algorithms that might later prove weak or incompatible.

The National Institute of Standards and Technology sets technical standards that federal agencies must follow. Two months after the memo, in July 2022, it announced the first four algorithms it had selected for post-quantum standardization. These are new mathematical methods designed to resist quantum attack.

The four were CRYSTALS-Kyber, for key establishment, and three signature schemes: CRYSTALS-Dilithium, FALCON and SPHINCS+. NIST also moved four further key establishment candidates into another round of study. Those names matter less than the timing. In the first week of May 2022, agencies were told to plan a migration to algorithms that had not yet been chosen.

The memo was careful about what it did not say. No computer able to break widely used public-key cryptography existed then, and the memo did not suggest one did. It was a planning document for a threat with no fixed arrival date.

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. The loss happens on the day of capture, even if nobody reads the data for years.

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.

Cryptographers have used this framing for years, usually written as a simple inequality: shelf life plus migration time against time to threat. Each term carries uncertainty. Shelf life depends on legal and mission judgments. Migration time depends on vendors and budgets. Time to threat depends on physics and engineering no agency controls. The method works because it puts effort where agencies have knowledge, and treats the unknowable term as a range to test against rather than a date to wait for.

The framing also travels across levels of government. A federal agency under NSM-10 has explicit instructions. A state revenue department or a county health agency has none from this memo, but it holds data with lifetimes just as long. The arithmetic applies to both. Only the reporting differs.

The key exchange is the weak point

When two computers start a secure conversation, they usually do two things. First, they use public-key cryptography to agree on a fresh secret key, a step called key exchange. Then they use that shared key with a faster method, called symmetric encryption, to scramble the actual data. Public-key methods are also used for digital signatures, which prove that a message or a software update really came from who it claims to.

Key exchange works like a lockbox handed across a crowded room: it is the clever trick by which two people agree on a combination while everyone else is listening, without anyone else being able to work it out. Symmetric encryption is the lockbox itself, opened with that combination.

The quantum concern falls mainly on the clever trick. The public-key methods in wide use today rest on math problems that ordinary computers cannot solve in any practical time, but that a large enough quantum computer is expected to solve efficiently. If an adversary has recorded the conversation, including the key exchange, a future machine could work out the combination and open every box sent under it. Symmetric encryption, by contrast, is generally regarded as much more resilient, especially with longer keys.

A common misunderstanding concerns forward secrecy. Modern protocols generate a fresh, temporary key pair for each session, so stealing a server’s long-term key later does not unlock past sessions. That protects against a classical attacker who breaks into the server. It does not protect against a quantum attacker who recorded the handshake. The temporary keys were exchanged with the same vulnerable mathematics, and a capable machine could recover each session’s secret from the recording alone. Traffic that engineers regarded as well protected in 2022 was exposed to harvesting all the same.

That is why the harvest threat is so specific. Not everything encrypted is equally exposed; the risk falls on anything protected by today’s public-key key exchange and captured along the way, which may become readable later. Signatures face a different kind of risk: a forged signature only matters once a machine exists, so the urgency there is about being ready in time rather than about data already lost.

Why symmetric encryption holds up

Quantum algorithms do threaten symmetric encryption, but far less. The best known quantum attack on a symmetric cipher roughly halves its effective key length. A 256-bit key under that attack still offers a margin generally regarded as ample. That is why post-quantum guidance tends to favor 256-bit symmetric keys rather than replacing symmetric algorithms altogether.

The practical consequence is that data encrypted at rest with a symmetric key, where that key never traveled over a quantum-vulnerable exchange, is in a much better position. The weakness usually lies in how keys are delivered and wrapped. A backup encrypted with a strong symmetric key, but whose key is itself protected by an RSA key held in a key management system, inherits the RSA key’s exposure.

Signatures run on a different clock

Signature risk is about future forgery, but some signatures have long lives of their own. A root certificate authority may be valid for twenty years. Firmware in a field device may trust a signing key burned in at manufacture for the device’s whole service life. Documents such as land records or court orders may need verifiable signatures for decades. If a capable machine arrives while those keys are still trusted, an adversary could forge updates or documents that systems accept as genuine.

So signatures also need a lifetime estimate, measured differently. The question is how long systems will go on trusting a key, rather than how long data must stay secret. For devices that cannot be updated, that period is set on the day of purchase.

The fix is to replace vulnerable public-key methods with post-quantum ones, new algorithms built on math problems believed to be hard even for quantum computers. That is what the NIST selection in July 2022 began to provide. The hard part is not choosing the algorithms. It is finding every place the old ones are used and changing them without breaking anything.

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 lies at one end. A public meeting calendar lies 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.

Sources agencies already hold

Most agencies can assemble a first pass from documents they already maintain:

• The National Archives’ General Records Schedules, which cover records common to all agencies, such as personnel and financial records.
• Agency-specific records schedules approved by the National Archives for mission records.
• Security classification guides, which set the duration of classification for national security information.
• Statutes that protect particular data, such as the confidentiality provisions for federal tax returns and the Privacy Act for records about individuals.
• The impact categorizations agencies assign to each system under FIPS 199, which already record how serious a loss of confidentiality would be.

No single source states a confidentiality lifetime directly. A retention period says how long a record must be kept, which can be shorter or longer than how long disclosure would cause harm. A personnel file may be destroyed after a set period, yet the medical details in it would harm the employee for life if exposed. Planners have to translate, and the translation needs records and privacy officers, as well as engineers.

Metadata counts too

Content is not the only thing worth harvesting. Records of who communicated with whom, when and how often can be as sensitive as the messages themselves. An informant’s contact pattern with an investigator, or the fact that a person applied for a particular benefit, can do harm for years. Network captures preserve that metadata along with the payload. A data lifetime assessment that covers only document contents will understate the exposure of systems that carry sensitive relationships.

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.

A third complication is data that leaves the agency. Benefits agencies exchange records with other agencies, states and contractors under data sharing agreements. Each exchange is a network path the originating agency may not control, protected by whatever cryptography the two ends negotiated. The data’s lifetime travels with it. An agency that ranks only its own systems will miss the links over which its most sensitive records reach partners, and those agreements are where requirements for post-quantum protection eventually need to appear.

Take a county social services department. Its case files on children in foster care must stay confidential for the lifetime of those children and beyond. Every night, a copy of those files travels over a leased network line to a backup site. That nightly transfer is precisely the kind of traffic an adversary could record now and attack later. The county’s public library catalog, which runs on similar technology, carries nothing that matters in five years. The two systems may look identical to a network engineer. To a records officer, one must stay confidential for a lifetime and the other for almost no time at all.

Public health offers another contrast. A state immunization registry holds health information about nearly every child in the state, which must remain protected for decades. The same department’s published dashboard of weekly case counts carries nothing confidential. Both run on web servers with the same certificates and the same key exchange. Only the data lifetime separates them, and only the people who manage the data can say what that lifetime is.

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, a piece of equipment that sits in front of web servers and handles incoming connections, 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. Firmware is the software permanently built into a device; if it cannot be updated, neither can the cryptography inside it.

Migration time has several components:

• Discovery: finding where public-key cryptography is used, which is what the NSM-10 inventory was meant to produce. This is harder than it sounds, because cryptography is often buried inside purchased products, libraries and network gear.
• 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. A system that engineers could fix in six months may take three years to fund, contract and deploy.

This is also where crypto agility earns its value. Crypto agility means designing a system so its cryptographic methods can be swapped without rewriting the application. Systems that call cryptography through maintained libraries and negotiated protocols shorten this migration and every one after it. Writing that property into requirements for new systems is cheap, and far cheaper than adding it to a system already in service.

Where public-key cryptography hides

Discovery is slow because public-key cryptography is everywhere and mostly invisible. A typical agency will find it in at least these places:

• Web servers, load balancers and API gateways that terminate encrypted connections.
• Virtual private network concentrators and remote access gateways.
• The agency’s public key infrastructure, including the smart card credentials employees use to log on and sign documents.
• Hardware security modules and key management services that protect other keys.
• Secure shell keys used by administrators and automated jobs.
• Code signing for software the agency builds and firmware signing in devices it buys.
• Software-as-a-service applications, where the cryptography belongs to the vendor.
• Operational technology, such as water treatment controls or building systems, often with long service lives.

Network scanning finds the first two quickly. The rest require asking vendors, reading configuration and code, and checking procurement records. Credentials deserve special attention. Smart cards carry keys generated on the card, and replacing them means reissuing cards to every employee and contractor on a multi-year cycle.

Bigger keys, real consequences

The size problem is concrete. An elliptic-curve public key used in key exchange today is 32 bytes. The post-quantum replacement at its commonly used security level is more than a kilobyte. Post-quantum signatures run to a few kilobytes, against well under a hundred bytes for elliptic-curve signatures. Most modern networks absorb that easily. Older middleboxes, constrained radios, smart cards and protocols with fixed message sizes may not. Testing those components early is how an agency learns whether a system needs a configuration change or a replacement.

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.

Return to the county. Its foster care backup link carries data with a lifetime measured in decades and runs on older network equipment the county cannot easily replace. It belongs at the top of the list. The county’s employee portal handles personnel records, also long-lived, but it is a commercial cloud product whose vendor is likely to add post-quantum support in a routine update. It can wait and move fast. The parking permit system is ancient and awkward to change, but the data is worthless within a year. It can go last.

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.

Testing the ranking against different threat dates

The third number, time to threat, cannot be estimated with any confidence, but it can be varied. A planning group can run its ranking three times: assuming a capable machine in ten years, in fifteen, and in twenty-five. Systems that rank at the top under all three assumptions are the firm priorities, and no forecast will change them. Systems that move sharply between scenarios deserve a second look, often because their migration time is uncertain or their data lifetime is borderline.

This approach also defuses an unproductive argument. Experts disagreed in 2022, and still disagree, about when such a machine might exist. A ranking that holds across a wide range of dates does not need that argument settled. Leaders can fund the top of the list while the debate continues, and revisit the middle of the list as estimates change.

Interim measures and their trade-offs

Each interim step carries a cost. Pre-shared symmetric keys avoid vulnerable key exchange, but someone has to distribute and rotate them securely, which scales poorly beyond a few fixed links. NSM-10 asked national security system owners to add symmetric-key protections by the end of 2023, a sign the approach is credible for high-value links. For a county with one backup circuit, the same idea may mean a vendor-supported option on its network encryptors.

Hybrid key exchange, which runs a classical and a post-quantum method together, protects new traffic once both ends support it. Before standards were final, agencies could only test it. Shortening retention protects data most cheaply of all, but it requires records officers to update schedules and program owners to accept the change, and it can collide with litigation holds and audit needs. Each measure supplements migration rather than replacing it. They buy time for the systems at the top of the list.

How the work runs inside an agency

In practice, turning these ideas into a plan is less about cryptography than about bringing three existing lists together.

The first is the cryptographic inventory NSM-10 called for. Security teams build it by scanning networks for the protocols and certificates in use, asking vendors what their products rely on, and reviewing custom code. The result is a list of systems and the public-key methods each one depends on. On its own, it is long and flat: thousands of entries with no sense of which matter.

The second is the records inventory, maintained by the agency’s records officer, which maps data categories to retention periods under schedules approved by the National Archives. The third is the system inventory kept by the chief information officer’s team, showing what each system does, what data it holds, when its contract renews and when it is due for replacement.

Joining the three is the core task. For each system, the planning group asks four things. What data does it carry, and how long must that data stay secret? Which public-key methods protect it in transit and at rest? And when is the next natural opportunity to change it, such as a contract renewal or a planned upgrade? A simple spreadsheet often does the job at first. The point is the conversation it forces between people who rarely talk: records officers, privacy officers, security architects, procurement staff and program owners.

A practical rhythm is to start with the highest bands. Rather than trying to rank every system at once, the group identifies everything that carries data needing protection for more than twenty years, then traces the network paths that data travels. That shorter list is where interim measures and early funding requests should focus. The rest of the inventory can be refined over the annual update cycle the memo established.

Federal, state and local agencies start from different places

The obligations differ sharply by level of government. Federal civilian agencies were bound by NSM-10 and, from November 2022, by OMB’s implementing memo. Owners of national security systems answered to the NSA, which published its own quantum-resistant algorithm suite for those systems in September 2022. State and local agencies had no comparable mandate from the memo. CISA was told to engage them, which offered guidance rather than requirements.

That did not leave states and counties untouched. Many of their systems handle federal data under federal security rules. The FBI’s security policy for criminal justice information requires encryption that meets federal standards. The IRS imposes safeguards on state agencies that receive federal tax information. As federal standards change, those requirements are likely to follow, and the agencies subject to them inherit the timeline. A county sheriff’s office or a state tax department should expect quantum-safe requirements to arrive through those channels.

Capacity differs too. A cabinet department can fund a cryptography program office. A small county may have one security officer and depend almost entirely on vendors. For the county, the most useful step is often contractual: requiring vendors to disclose their cryptography, publish a migration roadmap and support current standards. The data lifetime work still matters, because no vendor can tell the county which of its records must stay secret longest.

The output is a ranked list with a short rationale for each entry, written so a budget officer or an oversight body can follow it. That document turns a compliance exercise into a plan.

Roles and the evidence trail

The roles map onto positions agencies already have. The chief information officer owns the system inventory and the migration schedule. The chief information security officer owns the cryptographic inventory and the technical standards. The records officer supplies retention periods and translates them into confidentiality bands. The senior agency official for privacy identifies data whose disclosure would harm individuals for life. The chief financial officer and procurement staff decide when changes can be funded and contracted. Program owners confirm what their systems actually carry.

An inspector general reviewing the program would expect to see a few documents. The joined inventory, with a stated method for assigning data lifetimes. The ranking and its rationale. The contract clauses used in new procurements. Minutes or decisions showing that leaders reviewed the ranking and funded the top of it. And a record of progress against the measures the program set itself. An agency that can produce those has a program it can defend, whatever the reporting format of the year.

Budgets, breaches and better data governance

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.

The stakes are concrete. For an agency, the harm from harvested data is a breach that happens silently and is discovered, if at all, years later. Citizens whose tax, health or criminal justice records are exposed do not care that the decryption occurred in the 2030s; they care that the agency sent the data across an exposed link in the 2020s. Inspectors general and legislators are likely to ask the same question.

There is also a cost argument. Migrations folded into normal technology refresh cycles are far cheaper than emergency replacements. An agency that knows which systems carry long-lived data can make sure the next contract for each one requires post-quantum support and crypto agility, at little extra cost. An agency that does not know will discover the need late and pay a premium for urgency.

Fitting migration into refresh cycles

Most agency technology turns over on predictable cycles. Network equipment is often replaced every five to seven years, laptops more often, core applications far less often. A purchase made in 2022 may still be running in 2030. That means procurement decisions made the year NSM-10 was signed already fixed part of the migration problem for the decade that followed.

The practical step is to tag each system in the joined inventory with its next refresh or renewal date, then compare that date with its place in the ranking. Where a high-priority system’s next natural refresh comes in time, the agency can write requirements into that refresh and avoid a separate project. Where it comes too late, the agency has to either accelerate the refresh or fund an interim measure. Making that comparison explicit turns a vague risk into a few specific budget decisions.

Finally, the work is a forcing function for good data governance generally. An agency that maps how long each data set must stay secret, and where it flows, will find more than its cryptography. It will turn up data it no longer needs, copies it did not know existed, and links that should not carry sensitive records at all. Those discoveries pay off regardless of when a quantum computer arrives.

The case for waiting

Sceptics in 2022 had real arguments. Nobody could say when a capable machine would exist, and some credible researchers thought it might be decades away or never. The new algorithms were young. Indeed, within weeks of NIST’s July 2022 announcement, one of the candidates it had advanced for further study, SIKE, was broken by researchers using an ordinary computer. Early adopters risked spending money on methods that might not last. And much of the migration would arrive anyway through routine vendor updates, at no special cost.

Those arguments justify caution about what to buy, which is why NSM-10 itself told agencies not to purchase commercial quantum-resistant products before standards existed. They do not justify delaying the inventory, the data lifetime work or the contract language. Those steps cost little, depend on no particular algorithm and pay off in better data governance even if the threat never materializes. The harvest argument also cuts the other way. If a machine is decades off, data with a lifetime of decades is still exposed today, and only that data needs urgent protection.

Vendor updates will indeed carry much of the load, especially for web and cloud services. The systems they will not reach are the ones the ranking puts at the top: custom applications, old network gear, embedded devices and data already captured. Knowing which systems fall outside the vendor path is what the exercise is for.

Programs that join the inventories

A well-run program tends to share a few features. The cryptographic inventory is joined to the records inventory, so each system shows both what cryptography it uses and how long its data matters. Records and privacy officers sit in the planning group alongside security architects. Every new procurement includes language requiring support for current post-quantum standards and the ability to change algorithms later. And the program reports progress in terms leaders understand: how much long-lived data still travels over vulnerable links, and how that number is falling.

Strong programs also make vendors part of the inventory. Rather than discovering each product’s cryptography by scanning, they ask vendors to list the algorithms, key sizes and libraries in each product, in a format the agency can load into its inventory. They ask when each product will support the new standards and whether customers will need to act. Vendors that cannot answer are telling the agency something about how long that product will take to migrate.

Useful measures are simple. The share of systems carrying data with a lifetime over twenty years that have a migration date. The number of network links carrying such data that still rely on vulnerable key exchange alone. The share of new contracts with crypto agility and post-quantum clauses. The volume of long-lived data deleted under updated retention schedules. Each can be tracked from the joined inventory and reported in a single page.

Programs that stall tend to fall into the same traps:

• Waiting for a date. Treating the arrival of a quantum computer as the deadline ignores that harvested data is already exposed.
• An inventory with no priorities. A list of thousands of cryptographic uses, with no indication of which matter most, satisfies a reporting requirement and helps nobody decide.
• Treating it as a pure technology project. Without records and privacy input, the security team cannot know which data has a long life.
• Forgetting the vendors. Much of the cryptography an agency relies on sits inside products it bought. Contracts, not code, are often the lever.
• Underestimating procurement. Engineering timelines are rarely the bottleneck. Budget and contracting cycles usually are.
• Keeping data forever by default. Every year of unnecessary retention extends the window in which harvested data can do harm.

Quantum readiness is a management question

• Which of our systems hold data that must stay confidential for more than twenty years, and do we know which network links carry it?
• For each of those systems, how long would it realistically take to change its cryptography, counting funding and procurement as well as engineering?
• Which systems are at the top of our priority list, and why? Could a program director explain that ranking to a budget committee?
• Do our new contracts require vendors to support post-quantum standards and to let us change algorithms later?
• What sensitive data are we keeping that we no longer need, and what would it take to delete it?

The questions are deliberately non-technical. The hardest parts of quantum readiness are knowing what data matters, for how long, and how quickly the organization can act. Those are management questions, and leaders are well placed to ask them.

Each question has an obvious owner. The records officer can answer the first in part, with the security architect tracing the network paths. The chief information officer owns the second and third, since they turn on funding and sequencing. The chief procurement officer owns the fourth. The fifth needs the records officer, the privacy officer and the program owner together, because deleting data is a policy decision as much as a technical one. An agency that assigns each question to a named person, with a date for a first answer, has started its quantum program in substance.

With hindsight

The algorithms themselves were tested quickly. Within weeks of NIST’s July 2022 selection, SIKE, one of the additional key establishment candidates it had advanced for further study, was broken by researchers using a conventional computer. None of the four selected algorithms fell, but the episode showed why NSM-10 warned against buying unstandardized products and why crypto agility mattered.

OMB’s implementing memo, M-23-02, issued in November 2022, built data lifetime into the federal inventory itself. Agencies had to report, for each system in scope, the types of data it held by national records management category and how long that data and its metadata needed protection. Systems holding data expected to remain mission-sensitive in 2035 had to be included. The first prioritized inventory was due May 4, 2023, and annually after that. The national security community had its own track, after the NSA published its quantum-resistant algorithm suite for national security systems in September 2022.

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. What had been a presidential directive became a statutory obligation, harder to set aside and easier for oversight bodies to check.

The cost picture firmed up too. In July 2024 OMB sent Congress a report, required by that law, estimating that migrating prioritized federal civilian systems between 2025 and 2035 would cost about 7.1 billion dollars in 2024 dollars. OMB described the figure as a rough estimate, and much of it reflected systems that could not support the new algorithms and would have to be replaced. That was the migration-time term of the arithmetic, expressed in money.

The standards followed. NIST published its first three post-quantum standards, FIPS 203, 204 and 205, in August 2024. FIPS stands for Federal Information Processing Standards, the technical rules federal systems must meet, so this was the moment the new algorithms became something agencies could actually require in contracts. Later that year NIST proposed deprecating today’s widely used public-key algorithms and disallowing them by 2035, turning the memo’s goal into a concrete end date for the old methods. In March 2025 NIST also chose HQC, built on different mathematics, as a backup to its main key establishment standard, with a final standard expected in 2027.

The private sector moved too. Major browsers and messaging services deployed hybrid post-quantum key exchange, which protects new traffic against harvesting. Hybrid means combining an established method with a new post-quantum one, so a connection stays safe as long as either holds. For the many agency services delivered through ordinary web browsers, that closed part of the gap.

Messaging moved in the same direction. Signal added post-quantum protection to its protocol in 2023, and Apple did the same for iMessage in 2024. Those deployments showed that larger keys were workable at very large scale on modern networks. They also showed that systems built with agility could change quickly once standards and vendor support existed.

Then the deadlines tightened. 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. A forged signature can be prevented in the future; a recorded conversation cannot be un-recorded.

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. The deadlines are now nearer and more specific, but the underlying logic has not changed: start with what must stay secret longest, and work backward from there.