What the Quantum Threat Means for the Board

In November 2024, the U.S. National Institute of Standards and Technology (NIST) published a draft transition schedule containing two dates. After 2030, the 112-bit-security public-key cryptography that protects most internet traffic today is deprecated. After 2035, it is disallowed. That document, NIST IR 8547 (initial public draft), is informational in itself; binding cryptographic requirements reach U.S. federal systems through FIPS standards and OMB direction rather than through an interagency report. Two other authorities have published timelines that finish in the same year: the UK National Cyber Security Centre set out a migration timeline in March 2025 ending in 2035, and the National Security Agency’s CNSA 2.0 suite sets 2035 for national security systems.

Those dates matter for board oversight because they give an open-ended technology question a published schedule to plan against. The instruments differ by jurisdiction and some are still in draft, so none of them removes the judgment a board has to make about its own exposure. Directors don’t need to become cryptographers. They do need enough of the technical shape to scope a budget, set an internal deadline, and tell a good answer from a confident one.

What a quantum computer breaks, and what it leaves alone

The popular framing is a master key that opens every lock. That framing is wrong in a way that costs money, because it sends budget to the wrong systems.

Cryptography in commercial use comes in two families. Symmetric cryptography uses one shared secret to encrypt and decrypt, and it does the bulk work of protecting stored data and traffic in flight; the Advanced Encryption Standard (AES) is the one nearly everyone runs. Asymmetric cryptography, also called public-key cryptography, uses a matched pair of keys, and it does the work of establishing trust: agreeing a session key with a server you’ve never met, signing a certificate, signing a software update, signing a contract.

A large quantum computer breaks the second family and barely touches the first. Peter Shor showed in 1994 that a quantum computer can factor large numbers and solve discrete logarithm problems efficiently. Those two problems are the entire security basis for RSA, Diffie-Hellman, and elliptic-curve cryptography, so Shor’s algorithm doesn’t weaken them, it ends them. Lov Grover’s 1996 algorithm applies to symmetric cryptography and gives a quadratic speedup on brute-force search, which effectively halves key strength. AES-256 stays comfortable against that; the practical difficulty of running Grover at the required scale is itself substantial.

So the exposure sits in the trust layer rather than the data layer. Certificates, TLS handshakes, VPN key exchange, code signing, secure boot, document signing, payment authorization, and the whole public-key infrastructure that sits underneath them. That is where the work is, and it is also why the work is hard: those components are embedded in vendor firmware, in hardware security modules, in protocol standards, and in devices with fifteen-year service lives.

We now have replacements. NIST published three post-quantum cryptography standards on August 13, 2024: FIPS 203 specifies ML-KEM (formerly CRYSTALS-Kyber) for key establishment, FIPS 204 specifies ML-DSA (formerly CRYSTALS-Dilithium) for digital signatures, and FIPS 205 specifies SLH-DSA (formerly SPHINCS+) as a signature alternative built on different mathematics. A fourth signature standard, FN-DSA (formerly Falcon), and a backup key-establishment algorithm, HQC, are moving through the same process. Post-quantum cryptography means exactly this: algorithms designed to run on ordinary computers and to resist attack by quantum ones.

The three numbers that set your deadline

Michele Mosca, a cryptographer at the University of Waterloo, framed the timing question as an inequality, and it remains the cleanest tool a board has for this decision. Three numbers:

• x, data shelf life. How many years a given class of data must remain confidential.
• y, migration time. How many years your organization needs to inventory, plan, fund, test, and deploy the replacement, across your own systems and your suppliers’.
• z, time to a CRQC. A cryptographically relevant quantum computer is one large and reliable enough to run Shor’s algorithm against production key sizes. This is the number nobody knows.

If x plus y is greater than z, data you encrypt today is exposed at some point in its useful life. Work an example. A life insurer holds underwriting and medical data that must stay confidential for thirty years. Its architects estimate seven years to migrate, which is optimistic for an organization with mainframe-era policy administration. That gives 37, against published transition timelines ending in 2035 and a capability estimate nobody will stand behind. The insurer is already late for policies written this month.

The board cannot move z. It can move y, and y is the only variable under its control. Every quarter of delay in starting is a quarter added to y.

On z itself, the honest position is a range with a direction. Craig Gidney published an estimate in May 2025 putting the requirement for factoring RSA-2048 at fewer than one million noisy physical qubits running for under a week, down from roughly twenty million in the widely cited 2019 estimate he co-authored. That is a five-year improvement of more than an order of magnitude in the algorithm, not in the hardware.

The hardware is further behind, and the distinction between physical and logical qubits is where most reporting goes wrong. A physical qubit is a piece of hardware and it is noisy. A logical qubit is an error-corrected abstraction assembled from many physical ones, and it is what algorithms actually consume. Vendors publish physical qubit counts in the hundreds and low thousands. Error-corrected logical qubits have been demonstrated in far smaller numbers. The gap between what has been demonstrated and the thousands Shor requires is enormous, and it has been closing in one direction only.

Harvest now, decrypt later

Harvest now, decrypt later, usually shortened to HNDL, describes an adversary who copies encrypted traffic or exfiltrates encrypted archives today, stores them cheaply, and decrypts them when a CRQC becomes available. The attack requires no quantum computer at the time of collection. It requires storage, patience, and a reason to believe the data will still be worth something.

There is no publicly confirmed case of a specific actor doing this, and the published guidance does not rest on one. NSA, NCSC, and the European Commission each cite HNDL as the reason their timelines start now rather than later, and the reasoning is straightforward: bulk collection is already routine, storage is cheap, and holding ciphertext is indistinguishable from the collection activity a well-resourced adversary conducts anyway.

For the board, HNDL changes one thing, and it changes it decisively. It means the deadline for long-lived data is not 2030 or 2035. For data with a twenty-year confidentiality requirement, the deadline was some time ago, and the practical response is triage rather than despair. Rank data classes by remaining confidentiality life, and protect the longest-lived first. That ranking is a business judgment about what stays sensitive, not a technical judgment, which puts it squarely in management’s hands with board visibility.

Why this already sits with the board

Nothing here requires a new governance structure, because the accountability structure exists and quantum risk simply enters it.

In the United States, Regulation S-K Item 106, effective for annual reports from December 2023, requires registrants to describe their processes for assessing and managing material cybersecurity risks and to describe the board’s oversight of those risks. In the European Union, Article 20 of the NIS2 Directive requires management bodies of in-scope entities to approve cybersecurity risk-management measures and oversee their implementation, and requires member states to provide that management bodies can be held liable for failures. For financial entities, the Digital Operational Resilience Act, applying from January 17, 2025, places ultimate responsibility for ICT risk management with the management body.

None of those instruments names quantum computing. They don’t need to. Each of them attaches board-level accountability to the process by which material technology risk is identified, resourced, and overseen, and a risk with published transition timelines ending in 2035 and a ten-year remediation cycle is not a plausible candidate for omission from that process.

Sector bodies have been more explicit. The G7 Cyber Expert Group issued a statement in September 2024 asking financial authorities and firms to develop an understanding of quantum computing risk and to plan the transition to quantum-resilient technologies.

The commercial pressure arrives earlier than the regulatory pressure, as it usually does. Procurement questionnaires from large enterprise and government buyers have started asking suppliers about their post-quantum migration plans. Answering that question badly is a revenue event long before it is a compliance event.

What a cryptographic migration actually takes

The clearest evidence for how long this takes is the retirement of SHA-1, and SHA-1 was the easy case.

SHA-1 is a hash function, published in 1995, used to produce a short fingerprint of a document or certificate. Cryptanalytic results in 2005 showed it was substantially weaker than its design strength. NIST’s SP 800-131A transition guidance disallowed it for digital signature generation after 2013. Browser vendors stopped trusting SHA-1 certificates for public websites in early 2017. In February 2017, researchers at Google and CWI Amsterdam published SHAttered, the first practical collision. In December 2022, NIST announced that SHA-1 would be retired entirely by December 31, 2030.

That is roughly twenty-five years from the first serious warning to the scheduled end, for a single algorithm, with a drop-in replacement of the same shape available the whole time. SHA-2 produces a fingerprint that fits where the old one did.

Post-quantum migration is not that. The replacements change the shape of the data. An ECDSA P-256 signature is about 64 bytes; an ML-DSA-65 signature is around 3,300 bytes. An ML-KEM-768 public key is a little over a kilobyte, where a P-256 public key is 33 bytes compressed, or 65 uncompressed. Those differences break protocol assumptions, exceed packet size budgets, overflow fixed-length fields in embedded devices, and exhaust the storage on smart cards and hardware tokens designed a decade ago. Some equipment will be replaced rather than updated, because it cannot hold the new keys.

The market response to this is uneven. A large share of vendor “quantum-safe” claims currently describe a roadmap rather than a shipped, tested, standards-conformant product. Treat the claim as a question to be evidenced, not a box to be ticked.

Ten questions worth putting to management

Thirty questions is a reading list. Ten is a board meeting. These are ordered so that the first two can be answered this quarter and the rest depend on them.

Do we have a cryptographic inventory, and when will it be finished? The artifact is usually called a cryptographic bill of materials, or CBOM: a structured list of every algorithm, key, certificate, and library in use, and the system each one sits in. Nothing else on this list can be costed without it. Ask for a completion date, not a status.

Which data must stay confidential past 2035, and where is it stored? This is a business classification exercise that management will want to hand to security. It shouldn’t be handed to security, because the people who know how long a contract, a claim, or a design file stays sensitive are the ones who own the business line.

What is our target date for the highest-priority systems, and what does that date assume? A date with no stated assumptions is a wish. The answer should name the dependencies it is resting on, including vendor release schedules.

Is our infrastructure crypto-agile, and has that been tested? Crypto-agility means being able to change cryptographic algorithms through configuration and routine update rather than re-engineering. Almost every organization believes it has some. The useful follow-up is whether anyone has actually swapped an algorithm end to end in a production-like environment and measured what broke.

What is the multi-year cost, and which budget year does it start in? Migration spending that has not entered a budget cycle has not started, whatever the roadmap says.

Which third parties sit on the critical path, and what have they committed to in writing? Cloud providers, payment processors, identity providers, HSM vendors, and firmware suppliers. Verbal assurance from an account manager is not a commitment.

What is our plan for suppliers who will not get there in time? Some will not. Replacement cycles for critical vendors run years, so the decision point on the slowest ones arrives well before 2030.

Who owns this by name, and how often do they report to us? One named executive, a defined reporting cadence, and a standing place on the risk register. Distributed ownership across the CIO, CISO, and CRO reliably produces distributed inaction.

Do the people running the migration have verified competence in it, and what is our plan for the ones who don’t? This is a new specialism, and the number of practitioners who have actually executed a post-quantum migration is small. Ask what training and certification the team holds, and what the hiring or development plan is for the gap.

What is our disclosure position? If material cyber risk is disclosed annually, at what point does an unstarted migration against a published 2035 timeline become something a reasonable investor would want described.

What a defensible position looks like now

Directors are entitled to ask what “adequate” means before the migration is finished, and there is a reasonable answer. A board is on defensible ground when four things are true.

Someone owns the work by name and reports on it. A cryptographic inventory exists or has a funded completion date. Data classes are ranked by confidentiality life, and the longest-lived have a protection plan that assumes harvest now, decrypt later is real. And a multi-year budget line exists in an approved plan rather than in a slide.

Everything else follows from those four. None of them requires the board to understand lattice mathematics, and all four are the kind of thing that shows badly in a regulatory review if absent.

Building the capability to answer

Each of those ten questions ends with a person who has to produce an answer, and the honest constraint on most migration programs right now is not budget or standards but people who have done this work before. That capability is buildable, and it is faster to build than the migration it supports.

Quantum Academy runs certification programs for the technical and governance roles this transition depends on, from cryptographic inventory and migration planning through to the executive-level oversight this article describes. The current program list, prerequisites, and pricing are at quantumacademy.com/.

For the migration methodology itself, pqcframework.org sets out the phased approach in detail. For deeper technical treatment of the algorithms, resource estimates, and hardware progress behind the timelines quoted here, PostQuantum.com covers the underlying research. NIST’s own standards and transition documents are published at the post-quantum cryptography project page.

The timelines are published. The remaining variable is how long your organization takes, and that number starts moving the quarter the board asks for the inventory.