The encryption and digital signatures that protect almost every system today will need to be replaced before a large quantum computer can break them, and data stolen now can be decrypted later. This briefing is for directors, chief executives, CFOs and CISOs who need to understand post-quantum cryptography (PQC) as a business programme: why it matters before any quantum computer exists, which deadlines governments have set, what drives the cost, and how to judge whether management's plan is credible. It stays at board level. The technical approach is covered in the Crypto-Agility Guide and the Post-Quantum Cryptography Migration Guide.
The risk in one paragraph
Public-key cryptography (mainly RSA and elliptic curve algorithms) secures web traffic, VPNs, email, payments, software updates, identity tokens and the certificates that machines use to prove who they are. A sufficiently large quantum computer would break these algorithms. Nobody can say exactly when one will exist, but two things make the risk present rather than future. First, an adversary can record encrypted traffic today and decrypt it once the capability arrives, which the UK NCSC describes as collecting and storing data today and decrypting it at some point in the future. Second, replacing cryptography across an enterprise and its suppliers takes many years, so organisations that start late will still be migrating when the threat becomes real. The business question is therefore not "when will quantum computers arrive" but "which of our data must stay secret beyond the date we could finish migrating, and are we on track".
Why this is a board-level issue now
- The replacement standards exist. NIST published its first three post-quantum standards on 13 August 2024: FIPS 203 (ML-KEM) for key establishment, and FIPS 204 (ML-DSA) and FIPS 205 (SLH-DSA) for digital signatures, and encouraged organisations to begin transitioning as soon as possible. Waiting for standards is no longer a reason to delay.
- Governments have set dates. The UK NCSC's migration timelines, published on 20 March 2025, expect organisations to complete discovery and an initial plan by 2028, complete the highest-priority migrations by 2031 and complete migration of all systems, services and products by 2035. For US national security systems, NSA's CNSA 2.0 guidance requires new acquisitions to be compliant from 1 January 2027. Track every jurisdiction in the Post-Quantum Cryptography Deadlines Tracker.
- US federal policy has moved again. NIST IR 8547, Transition to Post-Quantum Cryptography Standards, was published as final on 27 October 2026, and states that it supports Executive Order 14412 and OMB memorandum M-26-15, which direct federal agencies to prioritise migrating their most sensitive systems. Suppliers to government should expect these requirements to flow into contracts.
- The EU is coordinating Member States. The European Commission published a coordinated implementation roadmap for the transition to PQC on 23 June 2025, aimed at a synchronised transition across Member States.
- The cost is real and needs planning. The NCSC warns that the total financial cost of PQC migration could be significant and advises organisations to budget for preparatory work as well as the migration itself.
Harvest now, decrypt later: which data is exposed
Not all data is equally at risk. Storing large volumes of encrypted traffic for years is expensive, so the NCSC judges the attack worthwhile mainly for the most valuable information. A practical test for the board is to compare how long each class of data must stay confidential with how long migration will take.
| Data or asset | Typical confidentiality need | Exposure today | Priority |
|---|---|---|---|
| Trade secrets, M&A, intellectual property | 10 years or more | High if sent over networks an adversary can record | First wave |
| Health, genetic and government identity data | Lifetime of the person | High | First wave |
| Long-lived trust anchors (root CAs, firmware signing keys) | Lifetime of the devices that trust them | Signatures cannot be harvested, but keys deployed now may still be in use when they can be forged | First wave for devices with long lifetimes |
| Financial transactions and session data | Days to a few years | Lower | Second wave |
| Public marketing content | None | None | No action |
For signatures the concern is different: a forged signature cannot be made until the quantum computer exists, but the NCSC advises considering the risk early when deploying keys for high-value trust anchors intended to have a long operational life, such as roots of trust in hardware that will be in service for a decade or more.
Deadlines at a glance
| Source | Milestone | Who it applies to |
|---|---|---|
| NIST FIPS 203, 204, 205 | Standards final 13 August 2024 | Everyone using NIST-aligned cryptography |
| UK NCSC migration timelines | 2028: goals, discovery and initial plan; 2031: highest-priority migration; 2035: all systems | UK organisations, especially critical national infrastructure and large enterprises |
| NSA CNSA 2.0 | 1 January 2027: new acquisitions compliant; 31 December 2030: phase out equipment that cannot support it; 31 December 2031: CNSA 2.0 algorithms mandated; 2035: all national security systems quantum resistant | US national security systems and their suppliers |
| NIST IR 8547 (final 27 October 2026) | Transition plan for quantum-vulnerable algorithms, supporting EO 14412 and OMB M-26-15 | US federal agencies, then their suppliers |
| EU coordinated roadmap (23 June 2025) | Synchronised transition across Member States | EU Member States, then operators and suppliers |
Dates move as guidance is updated. Management should hold a jurisdiction map that names the source and the date it was checked.
What drives the migration budget
- Discovery: finding every place cryptography is used, across applications, devices, cloud services, certificates, keys and suppliers. Most organisations have no complete inventory, and building one is the first and often most underestimated cost. See the Cryptographic Inventory and CBOM Guide.
- Vendor dependency: much of the change arrives through supplier updates to operating systems, browsers, network equipment, HSMs and SaaS. The cost is in tracking, testing and pushing suppliers, and in replacing products that will never be upgraded.
- Hardware refresh: devices with fixed cryptography or long lives (industrial controllers, payment terminals, smart cards, embedded systems) may need replacement rather than an update.
- Certificates and machine identities: every certificate authority, certificate and signing key in the estate will eventually be reissued with new algorithms. Organisations that already automate certificate management will pay far less. See the Post-Quantum Migration for NHIs Guide.
- Testing and performance: post-quantum keys and signatures are larger, which can affect constrained devices, network protocols and latency, so testing is a real line item.
- Programme management: a multi-year, cross-functional programme needs a team, governance and reporting.
The biggest saving is to fold PQC into work already planned: technology refresh cycles, certificate automation and procurement requirements, rather than running it as a one-off emergency later.
Hybrid now, post-quantum only later
Boards will hear the term "hybrid" in management updates, and it affects both cost and timing. A hybrid scheme combines a post-quantum algorithm with a traditional one, so that a connection stays secure if either algorithm holds. The NCSC treats hybrids as an interim measure: they add cost, complexity and some inefficiency, they may be needed for interoperability or protocol reasons, and once a quantum computer exists the traditional half adds no protection. Its recommendation is to use hybrids within a plan that allows a later move to post-quantum only, and for public key infrastructure it prefers a single migration to a fully post-quantum PKI over an intermediate hybrid PKI.
| Approach | When it fits | Board implication |
|---|---|---|
| Hybrid key exchange | Protecting traffic against harvest now, decrypt later while products and protocols mature | Low cost where products already support it; a quick win for long-life data |
| Post-quantum only | New systems and products built on the final standards, and the end state for all systems | Requires supplier support and testing; the target for the 2035 milestones |
| Replace or retire | Devices and products that cannot be upgraded | Capital cost; plan into refresh cycles now |
| Accept the risk | Systems with no long-life data that will be retired before the threat matters | Must be a recorded decision with an end date, not a default |
For US national security systems, CNSA 2.0 sets a similar direction: configure components to prefer the new algorithms first, then accept only them as products mature.
Five questions for the board to ask
- Which of our data must stay confidential for more than ten years, and is it protected against harvest now, decrypt later today? A credible answer names data classes, the systems that carry them and the plan for each.
- Do we have a cryptographic inventory, and what percentage of the estate does it cover? Expect a coverage figure and a date for completion, aligned with the 2028 discovery milestone.
- Which of our critical suppliers have published post-quantum roadmaps, and what do our contracts require? Look for a supplier list with status and procurement clauses for new purchases.
- What is the multi-year budget, and how much of it is absorbed by planned refresh cycles? The board should see a costed plan, not a single future request.
- How quickly could we replace an algorithm or certificate authority across the estate if we had to? The answer measures crypto agility; months for a single CA replacement suggests years for PQC.
Red flags in management answers
- "Quantum computers are years away": this ignores harvest now, decrypt later and the length of migration. The question is migration time, not arrival date.
- "Our vendors will handle it": suppliers will deliver updated products, but somebody must find every dependency, test, deploy and replace what will never be updated.
- "We will start when the standards settle": the core NIST standards were finalised in August 2024.
- No inventory, but a completion date: a date without knowing the scope is not a plan.
- PQC as a security-only project: procurement, architecture, operations and suppliers all have to change; a plan owned only by the security team will stall.
- Buying "quantum-safe" products without a plan: products help only when they fit an inventory-driven priority list.
What good looks like
| Area | Good practice |
|---|---|
| Governance | A named executive owner, PQC on the risk register, an annual board review against a dated roadmap |
| Inventory | A cryptographic inventory covering applications, devices, certificates, keys and suppliers, with owners |
| Prioritisation | Data classified by confidentiality lifetime; long-lived and high-value data and trust anchors migrated first |
| Supply chain | Critical suppliers' roadmaps tracked; PQC requirements in new procurement; a statement of intent published to suppliers |
| Agility | Certificates and keys managed centrally and automated, so algorithms and CAs can be changed by configuration |
| Testing | Pilots of hybrid key exchange on priority services, with performance and compatibility results |
| Budget | A multi-year costed plan aligned with refresh cycles and reviewed annually |
The Post-Quantum Readiness Maturity Model turns this table into five levels for self-assessment.
Where to invest first
- Discovery and inventory: fund the cryptographic inventory, since every later decision depends on it and the NCSC expects it complete by 2028.
- Procurement requirements: add PQC support and roadmap commitments to new contracts now, so that systems bought this year do not become next decade's migration cost. CISA, NSA and NIST jointly recommend engaging technology vendors early.
- Certificate and key automation: central, automated management of certificates and keys is the single largest enabler of crypto agility. See the PKI and Certificate Lifecycle Maturity Model.
- Protect the longest-lived data: enable hybrid post-quantum key exchange for the services that carry the most sensitive long-life data, where products support it. See the Hybrid Post-Quantum TLS Key Exchange Guide.
- Long-lived trust anchors: plan post-quantum signatures for firmware signing and roots of trust in devices with long service lives.
Metrics to track
- Percentage of the estate covered by the cryptographic inventory.
- Number of high-priority systems (long-life data or trust anchors) and the percentage with an approved migration plan.
- Percentage of critical suppliers with a published PQC roadmap, and of new contracts with PQC requirements.
- Percentage of certificates and keys under automated central management.
- Number of priority services piloting or using hybrid post-quantum key exchange.
- Spend against the multi-year budget and against the milestone plan.
A 90-day plan
- Days 1 to 30: name the executive owner; ask management for a one-page view of data with long confidentiality needs; confirm which deadlines apply in each jurisdiction and contract; commission the cryptographic inventory.
- Days 31 to 60: add PQC requirements to procurement templates; list critical suppliers and request their roadmaps; agree the scope and method of the inventory with architecture and operations.
- Days 61 to 90: receive initial inventory results and a prioritised list; approve a multi-year roadmap and budget aligned with the 2028, 2031 and 2035 milestones; baseline maturity with the Post-Quantum Readiness Maturity Model.
Common failure patterns
- Waiting for certainty: boards defer until a quantum computer is announced, by which time harvested data is already exposed and migration cannot finish in time.
- Inventory that stops at certificates: cryptography embedded in applications, libraries, devices and supplier services is missed.
- Buying new technical debt: procurement continues to buy long-lived systems without a post-quantum path.
- Treating it as a one-off project: without crypto agility the next algorithm change will be just as painful.
- Ignoring machine identities: service certificates, signing keys and device identities make up most of the cryptographic estate and are rarely in scope at the start.
Practitioner checklist
- Brief the board annually on PQC exposure, deadlines and progress against a dated roadmap.
- Classify data by how long it must stay confidential and map it to systems.
- Build and maintain a cryptographic inventory covering applications, devices, certificates, keys and suppliers.
- Maintain a jurisdiction and contract map of PQC deadlines, with source and date checked.
- Add PQC requirements to procurement and track critical suppliers' roadmaps.
- Automate certificate and key management to make algorithm changes a configuration task.
- Pilot hybrid key exchange on the services carrying the longest-lived data.
- Report the six metrics above to the risk or audit committee at least twice a year.
Standards and references
- NIST: First Three Finalised Post-Quantum Encryption Standards
- NIST: IR 8547 Transition to Post-Quantum Cryptography Standards
- UK NCSC: Timelines for Migration to Post-Quantum Cryptography
- UK NCSC: Next Steps in Preparing for Post-Quantum Cryptography
- NSA: CNSA 2.0 Frequently Asked Questions
- CISA, NSA and NIST: Quantum-Readiness, Migration to Post-Quantum Cryptography
- European Commission: Coordinated Implementation Roadmap for the Transition to Post-Quantum Cryptography
How NHI Mgmt Group can help
We provide independent identity and non-human identity risk assessments, board briefings and programme initiation support, including inventories of the certificates, keys and machine identities that post-quantum migration will touch. Our NHI Foundation Level Training Course helps security and IAM teams govern service accounts, API keys and secrets. Contact us to arrange a briefing.
Related NHI Mgmt Group resources: Crypto-Agility Guide · Post-Quantum Cryptography Migration Guide · Post-Quantum Cryptography Deadlines Tracker · Post-Quantum Readiness Guide