The Post-Quantum Migration Playbook NIST Won't Hand CISOs

Your encryption already has an expiry date — you just haven't been told which systems hit it first. Adversaries are recording your TLS traffic today to decrypt it the moment a cryptographically-relevant quantum computer arrives, and NIST has set a hard line: RSA and ECC are deprecated after 2030 and disallowed after 2035.

This guide is the post-quantum cryptography & crypto-agility playbook for CISOs that turns that abstract threat into a sequenced, auditable migration you can start on Monday.

What Post-Quantum Cryptography Actually Is — And Why It's a 2026 Problem

Post-quantum cryptography (PQC) is a new family of mathematical algorithms designed to resist attack by both classical and quantum computers. It replaces the public-key cryptography — RSA, elliptic-curve (ECC), Diffie-Hellman — that quietly secures almost every digital interaction your enterprise has.

Here is the first misconception to kill. "Post-quantum" does not mean "after quantum computers arrive." It refers to cryptography that is safe against them. Crucially, PQC runs on the hardware you already own — no quantum machine, no exotic infrastructure, just new software libraries and a great deal of operational discipline.

The threat is concrete. A sufficiently large quantum computer running Shor's algorithm would factor the large integers and solve the discrete-logarithm problems that RSA and ECC depend on for their security. Symmetric crypto (AES) and hashing (SHA-2/3) are far less affected — the public-key layer is the casualty.

Why this lands on the CISO's desk, not just the CIO's

Quantum readiness is often filed under "emerging tech" and handed to a CIO innovation team. That is a category error. The exposure here is not about using quantum computers — it is about your existing cryptographic estate becoming non-compliant and then exploitable.

That makes it a present-tense security-risk and audit problem. The CISO owns the cryptographic risk register, the certificate lifecycle, and the evidence trail an auditor will demand. The CIO owns the program's funding and delivery. Both signatures belong on the plan.

Harvest Now, Decrypt Later: The Attack Already Stealing Your 2035 Secrets

This is the section most vendor checklists bury, and it is the single insight that should reset your timeline. The dangerous assumption inside most enterprises is: "The deadline is 2030, quantum computers aren't here yet, so we have time." That logic is backwards.

In a "harvest now, decrypt later" (HNDL) attack, an adversary — typically a well-resourced nation-state — captures and stores your encrypted traffic today. They cannot read it yet. They are simply patient, betting that a quantum computer will unlock the archive in a decade.

So the real question is not "when does quantum arrive?" It is: "How long does my data need to stay secret?" If the answer is longer than the time until a quantum computer exists, that data is, functionally, already compromised the moment it crosses the wire.

Mosca's Inequality — the only risk formula you need

Cryptographer Michele Mosca framed the exposure with a deceptively simple inequality. Let X = the number of years your data must remain confidential. Let Y = the years it will take you to migrate to PQC. Let Z = the years until a cryptographically-relevant quantum computer exists.

Run the numbers honestly. If your patient records, financial contracts, or state secrets must stay confidential for 15 years (X), and a realistic enterprise migration takes 5 years (Y), you need Z to be greater than 20 years. Almost no credible analyst gives you that runway.

The Compliance Clock: RSA, ECC, and the Deadlines That Bind You

Quantum risk became a compliance obligation the day regulators put dates on paper. These are no longer recommendations; they are the milestones an auditor will hold you to.

NIST IR 8547 — the global anchor

In its transition guidance (NIST IR 8547), NIST set the schedule the world is echoing. Algorithms at the 112-bit security level — RSA-2048, ECC P-256 — are deprecated after 2030 and disallowed after 2035.

"Deprecated" means the algorithm may still be used during migration but is no longer appropriate for new deployments. "Disallowed" means it must not be used at all — and a certificate relying on it will no longer be trusted.

The EU Coordinated PQC Roadmap — the 2026 trigger

For your German, Dutch, Swiss and UK readers, Europe moved the nearest deadline much closer. The EU's Coordinated Implementation Roadmap (June 2025) requires Member States to publish national PQC plans and complete cryptographic inventories by the end of 2026.

High-risk use cases — critical infrastructure, long-life data — must be migrated by 2030; the remainder by 2035. The roadmap explicitly states quantum-vulnerable public-key mechanisms shall not be used stand-alone for high-risk cases after 2030.

For US defence-adjacent suppliers, NSA's CNSA 2.0 sets specific parameters (ML-KEM-1024, ML-DSA-87) and earlier timelines for national security systems and their supply chains under DFARS and CMMC.

Meet Your New Algorithms: FIPS 203, 204 and 205 Decoded

NIST finalised its first PQC standards in August 2024. You do not need to be a cryptographer, but every CISO should be able to name the four pieces and what each one protects.

ML-KEM (FIPS 203) — the key exchange

The Module-Lattice Key-Encapsulation Mechanism, derived from CRYSTALS-Kyber, replaces RSA and ECC for establishing shared secrets. This is the workhorse for TLS, VPNs and any encrypted channel. If you migrate one thing first, it is this.

ML-DSA (FIPS 204) — the primary signature

The Module-Lattice Digital Signature Algorithm (from CRYSTALS-Dilithium) is the general-purpose replacement for RSA and ECDSA signatures — certificates, authentication tokens, document signing.

SLH-DSA (FIPS 205) — the conservative backup

The Stateless Hash-Based Digital Signature Algorithm (SPHINCS+) is slower with larger signatures, but its security rests only on hash functions — a different mathematical foundation. Use it where longevity matters most: firmware and code signing, long-life root certificates.

HQC — why diversity is the strategy

In 2025 NIST selected HQC as a backup key-encapsulation mechanism built on different (code-based) maths than ML-KEM. The lesson for leaders: never bet your entire estate on a single algorithm family. If one is later weakened, algorithm diversity is what stops a second emergency migration.

The deep selection logic — parameter sets, key-size trade-offs, and which algorithm fits TLS versus code signing — lives in our dedicated algorithm guide, a spoke of this hub.

Crypto-Agility vs. Migration: The Distinction That Decides Your Budget

This is the most expensive misunderstanding in the entire programme, so be precise. A post-quantum migration is the one-time project of replacing today's broken algorithms with NIST's new ones. Crypto-agility is the architectural capability to swap cryptographic algorithms again — quickly, cheaply, without re-engineering the application.

Teams that conflate the two run a brute-force migration: they hard-swap RSA for ML-KEM wherever they find it, declare victory, and move on. Then HQC gets promoted, or an algorithm is weakened, and they discover they have to do the entire painful project a second time.

The strategic goal is not to be migrated. It is to become an organisation for which any future migration is routine. That is the difference between a five-year fire drill and a permanent capability.

What a crypto-agile architecture looks like

In practice, agility means abstracting cryptography behind a service or interface so that algorithm choices are configuration, not code. It means a centralised certificate authority and automated certificate lifecycle management — not crypto hard-coded across hundreds of applications.

The mechanics of building this — the maturity model, the abstraction layer, the FIPS-mapped control checklist — are covered step by step in our crypto-agility checklist.

The CBOM: you cannot migrate what you cannot see

A Cryptographic Bill of Materials (CBOM) is a structured, machine-readable inventory of every cryptographic asset in your estate — algorithms, key lengths, certificates, libraries and their dependencies. It is the foundation of every credible programme.

The EU roadmap names it explicitly, and you cannot prove migration progress to an auditor without one. Treat the CBOM as the cryptographic equivalent of the SBOM your supply-chain team already maintains.

The CISO's Post-Quantum Migration Playbook: 7 Phases

Here is the actionable spine of the programme — seven phases, sequenced so that compliance evidence accumulates from day one rather than being reverse-engineered before an audit.

Phase 1 — Discover

Build the CBOM. Use automated cryptographic discovery scanning across code, network traffic, certificate stores and dependencies. The output is a single source of truth for every place cryptography lives.

Phase 2 — Prioritise

Apply Mosca's Inequality to rank systems by data-secrecy lifespan, not by technical ease. Long-life, high-confidentiality data goes to the front of the queue because its HNDL clock is already running.

Phase 3 — Architect for agility

Before mass migration, build the abstraction layer and centralise certificate management. This is the step that converts a one-time migration into permanent crypto-agility — skip it and you will pay twice.

Phase 4 — Pilot with hybrids

Deploy hybrid certificates and hybrid key exchange (a classical algorithm plus a PQC algorithm together) in a contained environment. Hybrids preserve interoperability and de-risk the cutover while standards and libraries mature.

Phase 5 — Migrate in increments

Roll out by priority tier, system by system. This is where an agile, incremental delivery model is non-negotiable — which is why it has its own playbook below.

Phase 6 — Validate & evidence

Test interoperability, performance and rollback. Capture the audit evidence — what changed, when, and against which control — as you go. Auditors pull the evidence trail first; build it continuously.

Phase 7 — Govern continuously

Maintain the CBOM as a living asset, monitor for newly weakened algorithms, and keep the abstraction layer ready for the next swap. Crypto-agility is an operating model, not a project that closes.

The full migration mechanics — discovery tooling, hybrid deployment patterns, vendor and supply-chain handling — are detailed in our enterprise migration deep dive, the cornerstone spoke of this cluster.

Running PQC Migration the Agile Way — Sprints, Not a Death March

A multi-year cryptographic overhaul, run as a single waterfall programme, is almost guaranteed to stall. The estate is too large, the dependencies too tangled, and the big-bang cutover too risky. The discipline that rescues it is the one this organisation has always championed: agile delivery.

Reframe the migration as a product backlog. Each quantum-vulnerable system becomes an epic; each certificate, library or service becomes a story with clear acceptance criteria. Priority is set by Mosca's Inequality, not by whichever team shouts loudest.

Then add a quantum-safe gate to your Definition of Done: no new service ships with stand-alone quantum-vulnerable cryptography. This single policy stops you digging the hole deeper while you climb out of it.

We have written the sprint-planning model, backlog structure and Definition-of-Done changes as a complete spoke guide.

Budget, Timeline and Ownership: The Board's Three Questions

How long does it really take?

NIST estimates a large, fully-resourced federal migration takes three to five years. Heterogeneous enterprise estates — legacy systems, embedded crypto, sprawling supply chains — should plan for the upper end of that range or beyond. With the EU's 2026 and 2030 gates, the planning runway is effectively gone.

What does it cost — and what does waiting cost?

Direct costs are discovery tooling, certificate-management platforms, engineering time and testing. The harder line item is the cost of not acting: regulatory non-compliance after 2030, loss of certificate trust, and the open-ended liability of HNDL-exposed data. Frame the business case as obsolescence risk against a fixed deadline.

Who owns it?

The cleanest model is a shared RACI: the CISO accountable for cryptographic risk and audit evidence, the CIO accountable for programme delivery and funding, with a named migration lead running the agile execution. Ambiguous ownership is the most common cause of a stalled programme.

For the complementary executive and organisational view — how to structure teams, build a quantum centre of excellence, and prepare leadership for Q-Day — see our companion CIO guide.

The 90-Day Quick Start: What to Do Before Your Next Board Meeting

You do not need the full programme approved to make defensible progress. Here is the first quarter.

• Days 1–30 — Mandate & scope. Secure a shared CISO/CIO sponsor, name a migration lead, and launch automated cryptographic discovery to seed the CBOM.
• Days 31–60 — Inventory & prioritise. Produce a first-pass CBOM and rank systems with Mosca's Inequality. Identify your long-life, high-secrecy data — your HNDL front line.
• Days 61–90 — Pilot & evidence. Stand up a hybrid-certificate pilot on one non-critical system, capture the evidence trail, and brief the board with a backlog, a deadline map, and a budget ask grounded in the 2030 obsolescence date.

Q-Day is not a date on a distant calendar — it is a deadline already shaping your audit scope and your adversaries' patience. Start with the inventory, architect for agility, and run the migration in increments. The organisations that treat this as a capability, not a one-off scramble, will be the ones still trusted after 2035.