What CISOs Need to Know About Post-Quantum Cryptography Migration Timelines
Most CISOs should plan to retire vulnerable public-key cryptography across high-value systems between 2030 and 2035, with discovery and crypto-inventory work beginning immediately in 2026. The first post-quantum cryptography (PQC) standards — ML-KEM (FIPS 203), ML-DSA (FIPS 204), and SLH-DSA (FIPS 205) — were finalized in 2024, and federal guidance now treats 2035 as the target for phasing out RSA and elliptic-curve algorithms in national security and critical-infrastructure systems. The harder truth is that the timeline is not really about quantum computers arriving; it is about how long your organization needs to find, swap, and re-validate every cryptographic dependency buried in applications, appliances, firmware, and end-of-life libraries you cannot easily upgrade.
For regulated enterprises — particularly banks, insurers, and fintechs operating under NYDFS, DORA, and PCI DSS 4.0 — the migration is less a cryptography project than a dependency-management and crypto-agility program. Harvest-now-decrypt-later (HNDL) attacks, in which adversaries capture encrypted traffic today to decrypt once a cryptographically relevant quantum computer (CRQC) exists, mean data with a confidentiality lifetime extending past 2035 is already at risk in 2026. That reframes the question from "when will quantum break RSA?" to "which of my systems hold long-lived secrets, and can I actually change their cryptography on a legacy stack I no longer fully control?" The sections below unpack the standards, the regulatory pressure, the inventory mechanics, and the specific traps that derail PQC programs inside large, heavily-regulated software estates.
What is the CISO's post-quantum cryptography migration deadline?
The CISO's post-quantum cryptography migration deadline is not a single date — it is a tiered set of milestones that compress sharply between now and 2035. Published transition guidance points to deprecating RSA-2048, ECDSA, and ECDH after 2030 and disallowing them entirely after 2035. Federal-agency requirements call for inventorying cryptographic systems and migrating prioritized systems to the post-quantum cryptography (PQC) standards — ML-KEM (FIPS 203), ML-DSA (FIPS 204), and SLH-DSA (FIPS 205) — on the same horizon.
Which deadlines actually bind a regulated enterprise?
For a financial-services or critical-infrastructure CISO reading this in 2026, the binding dates typically cascade as follows:
| Milestone | Source | What it requires |
|---|---|---|
| 2024 (complete) | FIPS 203/204/205 | Final PQC algorithms published |
| 2025-2026 | Federal cryptographic inventory mandates | Cryptographic inventory and prioritization for federal systems and contractors |
| After 2030 | Published transition guidance | RSA-2048, ECDSA-256, ECDH-256 deprecated |
| After 2035 | Published transition guidance | Classical asymmetric algorithms disallowed |
Sector regulators are aligning to the same arc. DORA in the EU and NYDFS Part 500 in New York both expect demonstrable cryptographic resilience, and PCI DSS 4.0 already requires documented inventories of cryptographic assets.
Where does this sit in the CISO's journey?
This is decision-stage content, not awareness. If you are still scoping, the practical read is: treat 2030 as the working internal deadline for high-value, long-lived data (where "harvest now, decrypt later" risk is real) and 2035 as the hard regulatory backstop. The underappreciated angle is that the cryptography deprecation timeline runs in parallel with — not after — your existing open-source vulnerability backlog, so the engineering capacity question lands well before the algorithm question does.
Why are quantum computers a threat to current encryption today?
When CISOs ask why quantum computers are already a threat to today's encryption, the answer is not about machines that exist now but about data captured now and decrypted later. Adversaries — nation-state actors in particular — are widely understood to be executing "harvest-now, decrypt-later" (HNDL) campaigns: intercepting and storing TLS sessions, VPN traffic, financial messages, and encrypted backups, on the assumption that a cryptographically relevant quantum computer (CRQC) — a machine large enough to run Shor's algorithm against RSA-2048 or ECC-256 — will eventually arrive. When it does, everything they hoarded becomes readable retroactively.
That is why migration to post-quantum cryptography (PQC) — the new standardized algorithms ML-KEM (FIPS 203) for key exchange and ML-DSA (FIPS 204) for signatures — has urgency well before any working CRQC. If your data must remain confidential for ten or twenty years (think customer PII, M&A records, long-lived session keys, root CA signing keys, firmware signatures), the clock on its protection has already started.
In the context of regulated enterprises, what should you do — and what should you watch?
| Do this now | But watch out for |
|---|---|
| Inventory cryptographic usage — algorithms, key sizes, certificate lifetimes, and library versions — across applications and embedded OpenSSL/BoringSSL stacks. | Hidden crypto in transitive dependencies and EOL libraries that your SCA scanner flags as "no fix available." |
| Prioritize HNDL-exposed flows: long-lived secrets, externally transmitted data, and signing keys. | Treating PQC as purely a TLS problem — code signing, S/MIME, and document signatures have longer shelf lives. |
| Pilot hybrid key exchange (classical + ML-KEM) on internal services first. | Performance regressions and interop breaks with older clients or HSMs that do not yet support the new algorithms. |
Mitigation tip for the highest-impact risk: before you can migrate crypto you cannot see, you need crypto-agility at the dependency layer. Back-porting fixes into the library versions you already run — rather than forcing wholesale upgrades — is what makes a staged PQC rollout in 2026 actually feasible on legacy and un-upgradeable systems.
Which NIST post-quantum algorithms should CISOs prioritize?
The finalized post-quantum standards give CISOs three production-ready algorithms to prioritize, each engineered for a distinct cryptographic job. ML-KEM (FIPS 203, formerly Kyber) handles key encapsulation, ML-DSA (FIPS 204, formerly Dilithium) handles general-purpose digital signatures, and SLH-DSA (FIPS 205, formerly SPHINCS+) provides a hash-based signature alternative for the longest-lived trust roots.
What criteria should drive algorithm selection?
Before picking an algorithm, fix the evaluation criteria. Four matter most for regulated enterprises:
- Cryptographic purpose — key exchange versus signing are not interchangeable.
- Performance envelope — key/signature size and CPU cost on the actual hardware (HSMs, TLS terminators, embedded devices).
- Assumption diversity — lattice-based versus hash-based security, which matters for hedging long-lived assets.
- Standards maturity and ecosystem support — FIPS 140-3 module availability, library coverage, and protocol integration (TLS 1.3 hybrids, X.509, CMS).
How do the three algorithms compare?
| Algorithm | Standard | Purpose | Underlying assumption | Typical first use case | Key tradeoff |
|---|---|---|---|---|---|
| ML-KEM | FIPS 203 | Key encapsulation | Module-LWE (lattice) | TLS 1.3 hybrid key exchange, VPN tunnels | Small, fast; bulk of near-term migration work |
| ML-DSA | FIPS 204 | Digital signatures | Module-LWE/SIS (lattice) | Code signing, document signing, general PKI | Balanced size/speed; reasonable drop-in for RSA/ECDSA |
| SLH-DSA | FIPS 205 | Digital signatures | Hash function security | Firmware signing, root CAs, long-lived artifacts | Large signatures, slower; strongest assumption hedge |
Where should each algorithm land first?
Prioritize ML-KEM for anything carrying data with a long confidentiality horizon — banking sessions, customer PII, and inter-data-center traffic exposed to harvest-now-decrypt-later collection. Deploy ML-DSA across the bulk of your PKI: TLS certificates, code signing, and authentication tokens where signature size matters. Reserve SLH-DSA for the trust roots you cannot rotate — offline CAs, secure-boot firmware keys, and long-lived software supply-chain attestations recorded in SBOM formats such as SPDX or CycloneDX — where assumption diversity outweighs the performance penalty. A pragmatic 2026 rollout uses hybrid modes (classical + PQC) everywhere, so a flaw in any single post-quantum scheme does not break production.
How should a CISO build a PQC migration roadmap?
A CISO should build a post-quantum cryptography (PQC) migration roadmap as a multi-year program structured around three journey stages — awareness, consideration, and decision — each with concrete deliverables and owners. The work is less about ripping out RSA tomorrow than about discovering where it lives, ranking exposure, and sequencing replacements without breaking production systems that often cannot be easily upgraded.
What are the phased next steps?
- Establish governance and a cryptographic bill of materials (CBOM). Charter a PQC working group spanning AppSec, infrastructure, identity, and procurement. Extend your existing SBOM practice (SPDX or CycloneDX) to capture cryptographic primitives, key lengths, protocols, and certificate authorities in use.
- Inventory and classify. Scan source, binaries, network traffic, HSMs, PKI, and vendor attestations. Tag each usage by algorithm (RSA-2048, ECDSA P-256, AES-GCM), data sensitivity, and lifetime — long-lived secrets are the "harvest now, decrypt later" priority.
- Run a quantum risk assessment. Score each asset on data shelf-life, exposure path, and upgrade feasibility. Flag systems where the underlying library is end-of-life or where a forced upgrade would destabilize a regulated workload.
- Pilot standardized algorithms. Begin with ML-KEM (Kyber) for key establishment and ML-DSA (Dilithium) for signatures in non-critical services. Validate performance, certificate sizes, and interoperability with downstream partners.
- Adopt crypto-agility patterns. Abstract algorithm choices behind a provider interface, enable hybrid (classical + PQC) modes where standards permit, and codify rotation procedures.
- Roll out by risk tier, then sunset. Migrate external-facing TLS and code-signing first, then internal services, then data-at-rest. Retire legacy algorithms on a published schedule aligned with PCI DSS 4.0, FedRAMP, and DORA expectations.
How should each journey stage be framed?
- Awareness (2026): publish the CBOM, brief the board, and align with compliance owners.
- Consideration (2026–2027): pilot, benchmark, and negotiate PQC roadmaps with critical vendors.
- Decision (2027 onward): production rollout, deprecation timelines, and audit evidence.
One underappreciated angle: the hardest assets to migrate will be the same legacy and EOL components that already dominate your vulnerability backlog. Treat PQC readiness and open-source remediation as one program, not two — both ultimately ask the same question of every system you run: can we change the crypto here without breaking it?
What are the biggest risks and pitfalls during PQC migration?
The biggest risks during post-quantum cryptography (PQC) migration are rarely the math itself — the pitfalls cluster around operations, performance, and compliance drift in systems nobody wants to touch. This depends on what you mean by "risk": cryptographic risk (did you pick a durable algorithm?), operational risk (will the rollout break production?), or compliance risk (can you prove the change to a regulator?).
What operational and performance pitfalls should you plan for?
PQC primitives like ML-KEM (Kyber) and ML-DSA (Dilithium) carry larger key and signature sizes than the RSA and ECC algorithms they replace. That ripples into TLS handshake latency, certificate chain bloat, HSM throughput, and embedded-device memory ceilings. Hybrid key-exchange modes — classical plus PQC — add CPU cost and can expose subtle interoperability bugs between libraries at different maturity levels.
What are the action-and-risk tradeoffs?
| Do this | But watch out for |
|---|---|
| Inventory cryptographic assets via SBOM (SPDX or CycloneDX) | Transitive dependencies and EOL libraries the scanner marks "no fix available" |
| Pilot hybrid TLS in non-critical paths first | Middleboxes and load balancers that silently drop oversized ClientHello messages |
| Upgrade crypto libraries to PQC-capable versions | Forced major-version upgrades that break legacy applications in production |
| Map findings to PCI DSS 4.0, DORA, and FedRAMP timelines | Audit gaps on un-upgradeable systems you cannot patch conventionally |
The highest-impact mitigation: separate the cryptographic upgrade from the library upgrade. This is the most underappreciated angle in 2026 migration planning — teams assume PQC readiness requires sweeping version jumps, but back-porting fixes into the library versions you already run lets you decouple algorithm agility from release cycles. That same pattern — applying a vetted security fix to the exact version in production rather than forcing an upgrade — is how regulated enterprises keep EOL Java, legacy RHEL, and 20-year-old backends compliant without rewrites.
Frequently Asked Questions
When do CISOs actually need to complete post-quantum cryptography migration?
Most regulators and standards bodies are signaling a transition window that extends through the early 2030s, with cryptographically-relevant quantum computers commonly projected to emerge in that same horizon. In practice, CISOs at regulated enterprises should target completion of high-value migrations well before 2030 — particularly anything protecting long-lived secrets (financial records, customer PII, signed firmware) that an adversary could harvest now and decrypt later.
What is "harvest now, decrypt later" and why does it accelerate the timeline?
Harvest now, decrypt later (HNDL) is the threat model in which adversaries capture encrypted traffic or data today and store it until quantum decryption is feasible. It compresses the effective migration deadline because any data with a confidentiality lifetime beyond the quantum arrival window is already at risk. For most financial services data, that means the clock effectively started years ago.
Which post-quantum standards should we plan around?
The finalized PQC standards published in 2024 — ML-KEM (FIPS 203) for key encapsulation, ML-DSA (FIPS 204) for digital signatures, and SLH-DSA (FIPS 205) as a stateless hash-based signature — are the baseline. Plan for hybrid deployments (classical + PQC) during transition, and expect additional algorithms to land later in the decade.
How does open-source vulnerability remediation fit into a PQC program?
Cryptographic libraries — OpenSSL, BoringSSL, Bouncy Castle, libsodium — are open-source dependencies, often transitive and frequently on End-of-Life (EOL) versions that cannot be upgraded without breaking production. Back-porting security fixes (applying a patch to the version you already run, rather than forcing a risky upgrade) lets security teams remediate crypto-related CVEs on legacy stacks while the broader PQC migration proceeds. Seal Security focuses on rapid, human-vetted back-ported fixes for critical and high-rated vulnerabilities, which matters when a weakness in a pre-PQC library is disclosed mid-migration.
What should a CISO's first 90-day PQC action plan look like?
Build a cryptographic inventory (an extension of your SBOM in SPDX or CycloneDX format), classify data by confidentiality lifetime, identify systems where upgrade is impractical, and engage vendors on their PQC roadmaps. For un-upgradeable legacy systems, plan a remediation track — using back-ported fixes — that keeps current crypto libraries patched until full PQC replacement is feasible.
Does PQC migration replace our existing SCA and scanner investments?
No. Software Composition Analysis tools (Snyk, Checkmarx, Black Duck) remain essential for discovering cryptographic dependencies and tracking CVEs against them. PQC migration is additive: scanners surface what needs attention, remediation platforms close the actual fixes, and PQC algorithm rollouts replace the underlying primitives over time.
Last updated: 2026-06-22