QUANTUM · MIGRATION · REFERENCE · Published May 30

Post-quantum cryptography migration, May 2026: what to do, in what order, with what algorithms — and why the deadline is sooner than you think.

NIST's FIPS 203 (ML-KEM), FIPS 204 (ML-DSA), and FIPS 205 (SLH-DSA) are final standards as of 2024. NSA's CNSA 2.0 makes them mandatory on national security systems starting January 2027, full compliance by 2033. Corporate cyber insurers and large customers are following. The harvest-now-decrypt-later threat means data encrypted today with RSA or ECC is at risk if its sensitivity outlives the migration. This is the operator-level playbook: the standards, the Mosca framework for timing, the crypto inventory, the hybrid migration patterns, HSM + code-signing + blockchain considerations, and the realistic 2026-2030 sequence of work.

3 final FIPS standards (203, 204, 205)
Jan 2027 NSS deadline
~$15B estimated 5-yr migration market
TL;DR 30-second version · free
  1. 01 Three NIST standards matter: FIPS 203 (ML-KEM, key encapsulation, replaces RSA-OAEP/DH/ECDH), FIPS 204 (ML-DSA, digital signatures, replaces RSA-PSS/ECDSA), and FIPS 205 (SLH-DSA, hash-based signatures, conservative backup). All three are lattice- or hash-based and final. Implementation is in major TLS libraries (OpenSSL 3.x, BoringSSL, rustls), browser vendors (Cloudflare, Google Chrome ship hybrid X25519+Kyber today), and growing HSM support (Thales, Entrust roadmaps include PQC for 2026-2027).
  2. 02 Use Mosca's framework to decide urgency: if (data sensitivity lifetime + migration time) > (time to cryptographically-relevant quantum computer), you are exposed now. For most enterprises, data with >5-year sensitivity already fails this inequality. The harvest-now-decrypt-later threat means encrypted traffic captured today can be decrypted when sufficient quantum hardware exists — which the Harvard May 2026 review argues is closer than the public roadmaps state.
  3. 03 The migration sequence that survives: (1) crypto inventory — boring, gating, do it first; (2) hybrid TLS on one pilot service — operational learning; (3) HSM and key management upgrade; (4) signing infrastructure (code, firmware, documents); (5) protocol-by-protocol rollout (TLS production, SSH, VPN, S/MIME, blockchain wallets); (6) embedded + IoT — the long tail, hardest, most painful. Each step takes 6-18 months at enterprise scale. Starting in 2026 is on time. Starting in 2028 is late.
DEEP ANALYSIS · free while in beta
READING AS
FOR YOU

You are the owner. Build the crypto inventory this year. Brief the board on q-day risk and harvest-now-decrypt-later threat model with specific data classes named (financial, legal, healthcare, IP, customer PII). Get budget for a 2026-2030 migration program — typically $1-5M per $1B revenue depending on industry. Run the hybrid TLS pilot. Update RFP and procurement language. Track vendor HSM roadmaps. By Q4 2026, you should have a written migration roadmap with funded headcount.

FOR YOU

Hybrid TLS is your hands-on entry point. Get OpenSSL 3.x with oqs-provider running in a lab, validate ML-KEM-768 hybrid mode against your traffic patterns, measure the actual handshake overhead on your hot paths, write the runbook. SSH key rotation infrastructure: assess whether your existing key authority can support PQC keys when SSH client/server support ships (in progress). Code-signing pipeline: identify every key in CI/CD and the path to rotate them. Most of this is straightforward; the work is in inventory + sequence, not in any single technology.

FOR YOU

For most application code, the migration is invisible — your TLS library handles it. The exceptions: code that does its own crypto (JWT signing, message authentication, custom protocols), code with hardcoded algorithm assumptions ("if RSA-2048..."), and code that exposes algorithm choice to users. Audit your codebase for direct crypto calls. Replace algorithm-specific APIs with algorithm-agnostic ones (e.g., abstract "sign this" instead of "RSA-sign this"). The work is small per codebase, big in aggregate across an enterprise.

FOR YOU

The PQC migration market is the clearer commercial story in quantum: $15B+ over 5 years, multiple revenue lines, fast monetization vs hardware bets. Plays: (1) HSM vendors with PQC roadmaps (Thales, Entrust, AWS); (2) crypto-discovery tooling (Sandbox AQ, IBM Quantum Safe, CryptoNext, KeyFactor); (3) certificate authorities and PKI infrastructure (Sectigo, DigiCert, Venafi); (4) consulting + managed services for migration (Accenture, Deloitte, Kyndryl). Procurement starts 2026; revenue lands 2027-2030; replacement cycle continues into 2030s.

FOR YOU

If your product handles long-lived sensitive data (healthcare, legal, financial, defense, IP), PQC posture becomes a sales asset in 2026 enterprise procurement and a compliance requirement by 2027 for government. Get the conversation into your sales collateral now. If your stack uses standard TLS libraries, the technical migration is straightforward; if you wrote your own crypto layer (rare but happens), refactor toward algorithm-agnostic abstractions. The cost of being early is small; the cost of being late is a procurement disqualifier.

Six concrete standards + implementation surfaces to anchor on. Each is load-bearing for the migration.

Standard

FIPS 203 — ML-KEM (Kyber)

Module-Lattice-Based Key Encapsulation Mechanism. Replaces RSA-OAEP, DH, ECDH for key establishment. ML-KEM-512/768/1024 corresponding to AES-128/192/256 security levels. The workhorse for new TLS, key exchange, hybrid encryption.

kem
Standard

FIPS 204 — ML-DSA (Dilithium)

Module-Lattice-Based Digital Signature Algorithm. Replaces RSA-PSS, ECDSA, Ed25519 for digital signatures. ML-DSA-44/65/87 levels. Signature size larger than ECDSA — design implications for code-signing and high-volume verification.

signature
Standard

FIPS 205 — SLH-DSA (SPHINCS+)

Stateless hash-based signature. Slower and larger than ML-DSA but security rests only on hash function strength — conservative backstop against lattice cryptanalysis surprises. Recommended for very long-lived signatures (firmware, root certificates).

signature
Framework

CNSA 2.0 timeline

NSA Commercial National Security Algorithm Suite 2.0. New NSS acquisitions must be CNSA 2.0 compliant from January 2027. Full compliance for most NSS types by 2033. Sets the de facto timeline for federal contractors and the floor for enterprise.

compliance
Pattern

Hybrid TLS — X25519 + ML-KEM-768

Concatenate a classical key exchange with a post-quantum one. If either is broken, the session stays secure. Production-deployed today in Cloudflare and Chrome. Negligible latency overhead. The right first migration step for almost everyone.

pattern
Tool

Open Quantum Safe — implementation library

OQS provides liboqs (PQC algorithms) and oqs-provider (OpenSSL 3 integration). Reference implementation for prototyping. Not for production — use vendor-supported builds (OpenSSL, BoringSSL, AWS-LC, BoringSSL fork in Chrome).

tooling

PQC migration is not a software patch. It is a multi-year reorganization of every cryptographic dependency in the enterprise, starting with discovery and ending with embedded devices that may need physical replacement. The Mosca framework gives you the urgency calculation. The standards give you the destination algorithms. The sequence below is the operational path.

BEFORE
How "we will do it later" goes wrong
  • No crypto inventory — nobody knows what depends on RSA/ECC and where
  • Asymmetric crypto in long-lived signed artifacts (firmware, root CAs, code) that ship with 10-year lifetimes
  • Vendor dependencies (HSM, SaaS, embedded device firmware) without PQC roadmaps
  • No hybrid TLS in production — first PQC code goes to production with zero operational experience
  • NSS deadline arrives with multi-year migration backlog and no funded program
→
AFTER
How successful 2026 PQC programs look
  • Crypto inventory in a system of record (BOM-style), refreshed quarterly
  • Hybrid TLS pilot on one internal service in 2026, broader rollout 2027
  • HSM + signing infrastructure roadmap aligned with vendor PQC ship dates
  • Mosca framework applied per data class — explicit decisions on what migrates first
  • Procurement language requires vendor PQC roadmap for new contracts
  • Board briefed on q-day exposure and migration timeline

The migration math is not exotic — it is project management on a 5-7 year horizon with high vendor dependency. The technical pieces (algorithms, libraries, protocols) are in place. The hard work is discovery, prioritization, vendor coordination, and the long tail of embedded systems. Starting in 2026 is on schedule. Starting in 2028 means you ship past the NSS deadline and your customers ask uncomfortable questions in procurement.

DEEP READ 4 sections · cited primary sources · technical review pending

01 Mosca's framework — the urgency calculation

Michele Mosca's 2015 framework gives you a single inequality to test your exposure: if X + Y > Z, you are at risk now, where X is the time your data must remain confidential (data sensitivity lifetime), Y is the time required to migrate your systems to post-quantum cryptography, and Z is the time until a cryptographically-relevant quantum computer exists. Most enterprises fail this inequality today.

Worked example for typical enterprise data classes: financial records and legal documents often need 7-10 year confidentiality (X=10). Migrating a mid-size enterprise's full crypto inventory to PQC takes 3-5 years (Y=4). Mid-2026 best estimates for Z range from 8 years (Harvard, optimistic on progress) to 15 years (NSA's CNSA 2.0 timeline implies CRQC concern by 2033). X+Y = 14 years. Z = 8-15 years. The data encrypted today is plausibly within the harvest-now-decrypt-later window.

The framework is useful precisely because it forces you to put numbers on each variable. "Quantum is 20 years away" stops being persuasive when you write down that your data lifetime is 10 years and your migration time is 5 years. The fact that experts disagree on Z is the reason hybrid migration is the right answer — hybrid TLS is secure under both classical and post-quantum threat models, so you get the migration insurance without betting on a specific Z.

  • X — data sensitivity lifetime How long does this data need to stay confidential? Financial/legal: 7-10yr. Healthcare: lifetime. Trade secrets: 10-20yr. Defense: 25+yr.
  • Y — migration time How long to migrate this system class? Hybrid TLS: 1yr. HSMs: 2-3yr. Code-signing infrastructure: 2-4yr. Embedded/IoT: 5-10yr.
  • Z — time to CRQC Estimates range from 8yr (aggressive) to 15-20yr (conservative). Pick a Z and decide; do not wait for consensus.
PRIMARY SOURCE Mosca · "Cybersecurity in an era with quantum computers"

02 Crypto inventory — what to find, how to find it

You cannot migrate what you have not catalogued. Crypto inventory means a system of record listing every place asymmetric cryptography is used in your environment, with enough metadata to plan migration. The shape of a useful entry: { asset_id, location, crypto_type (RSA/ECC/DSA), key_size, owner, criticality, dependency_graph, migration_pathway, target_completion }.

Where to look: (1) TLS termination — load balancers, reverse proxies, CDNs, internal mesh, every cert in your CA inventory; (2) SSH — host keys on every machine, user keys in every key authority, jumphost configurations; (3) HSMs — every HSM in every facility, with full key inventory per partition; (4) code and firmware signing — every CA used for code-signing, every key in your CI/CD signing pipeline, every firmware image with embedded signing keys; (5) document signing — PDF signatures, S/MIME email, internal document workflow systems; (6) blockchain wallets and signing keys if you are in that space; (7) embedded devices and IoT — usually the long tail, often the hardest, sometimes requires physical device replacement.

Automation tools that help: ssh-keyscan for SSH discovery, OpenSSL scripts for cert inventory, vendor HSM APIs (Thales nShield, AWS CloudHSM, Azure Key Vault, Google Cloud KMS) for managed key inventory, CA management consoles (Sectigo, DigiCert, Let's Encrypt internal mirrors) for cert inventory. For the long tail (embedded, IoT, legacy on-prem), expect manual work. The discovery phase typically takes 2-4 months at enterprise scale before you have a useful baseline.

  • TLS layer Load balancers, CDNs, reverse proxies, every cert in your CA system. Start here — biggest surface, most tooling support.
  • SSH + Bastion Host keys, user keys, jumphost configs. ssh-keyscan + cert authority audit.
  • HSMs Every HSM, every partition, every key. Vendor APIs do the heavy lifting.
  • Code + firmware Every signing key in CI/CD, every embedded signing CA. Long-lived signatures = SLH-DSA candidates.
  • Document signing PDF, S/MIME, internal workflow systems. Often forgotten until audit time.
  • Embedded + IoT The long tail. Usually painful. Some devices will need replacement, not patching.

03 Hybrid TLS — the right first pilot, end-to-end

Hybrid TLS combines a classical key exchange (typically X25519 elliptic-curve Diffie-Hellman) with a post-quantum one (typically ML-KEM-768, formerly Kyber-768) by concatenating their shared secrets and using the combined value as the TLS handshake input. If either algorithm is broken — including a future quantum break of X25519 — the session stays secure. The performance overhead is small (a few hundred bytes of handshake, low single-digit milliseconds of CPU on modern hardware).

What ships today: Cloudflare enables hybrid TLS by default for connections originating from Chrome since late 2024. Chrome enabled hybrid X25519+Kyber-768 by default in Chrome 124. Edge, Firefox, Safari are following. Server-side: OpenSSL 3.x with the oqs-provider supports it, BoringSSL (used by Chrome) supports it natively, AWS-LC supports it. NSS, GnuTLS are in various states of integration.

Migration pilot recipe: pick an internal HTTPS service with controlled clients, enable hybrid TLS on the server, run a 4-week soak measuring handshake latency p99 and incompatibility rate, confirm legacy clients still negotiate classical-only ciphersuites successfully, document the runbook for production rollout. The deliverable is operational confidence and a runbook — not security improvement, which the hybrid mode delivers safely either way.

  • Browser support Chrome (124+), Edge, Cloudflare. Firefox, Safari progressing. Default on by 2026 mid-year.
  • Server libraries OpenSSL 3.x + oqs-provider, BoringSSL, AWS-LC. Production-ready.
  • Performance impact A few hundred bytes of handshake, low-ms CPU. Negligible for almost all production traffic.
  • Compatibility risk Hybrid mode falls back to classical for legacy clients. No connection breakage if implemented correctly.
PRIMARY SOURCE Cloudflare — Post-quantum TLS in production

04 HSMs, code signing, and the long tail

Hardware Security Modules are the trickiest piece of the migration because they are appliances with vendor-controlled firmware lifecycles. The major vendors (Thales, Entrust, Utimaco, Marvell, AWS CloudHSM, Azure Managed HSM, Google Cloud HSM) all have PQC roadmaps but ship dates vary. Some support ML-KEM and ML-DSA in current firmware revisions; others require hardware refresh. For each HSM in your inventory, get the vendor's PQC support matrix and migration path in writing. Plan for 18-36 months between roadmap commitment and production deployment.

Code signing is its own challenge because signatures must remain verifiable for the lifetime of the signed artifact. Firmware that ships in a 10-year industrial device today, signed with ECDSA, is verified by a CRQC-equipped attacker against a key Shor can recover. The right approach for long-lived signed artifacts is SLH-DSA (FIPS 205) — slower and larger than ML-DSA but security depends only on hash function strength, making it the conservative choice for >10-year signature lifetimes. For shorter-lived signing (TLS certs, JWT tokens, sessions) ML-DSA is the practical choice.

The long tail — embedded systems, IoT devices, legacy on-prem applications, payment terminals, vehicle ECUs — is the part of the migration that takes 5-10 years and sometimes requires physical replacement rather than software upgrade. The honest plan for these systems is: identify them in inventory, accept they will not be migrated on the same timeline as your TLS layer, and apply compensating controls (network segmentation, traffic encryption layers above the device, eventual retire-and-replace). Not every device gets PQC by 2030; the realistic goal is the systems with high data sensitivity do.

  • HSM migration Vendor-roadmap dependent. 18-36 months from roadmap commit to production. Get the matrix in writing.
  • Long-lived signatures SLH-DSA (FIPS 205) for firmware, root CAs, anything signed for >10yr verification window.
  • Short-lived signatures ML-DSA (FIPS 204) for TLS certs, code-signing certs with renewal cadence, JWT.
  • Embedded + IoT long tail Many will not migrate cleanly. Plan compensating controls + retire-and-replace, not universal upgrade.

Six migration failure modes worth naming up front. Severity reflects how often the pattern bites enterprises mid-migration.

  1. no-inventory HIGH

    Starting migration without a crypto inventory

    The most common failure pattern: teams pick the most visible PQC project (hybrid TLS rollout) and start there without an inventory of what asymmetric crypto exists across the estate. They ship hybrid TLS, claim PQC progress, and discover 18 months later that the long-tail surface — SSH keys, code-signing CAs, embedded HSMs, document signing, vendor SaaS — is bigger than the work they did and untouched. The board hears "we did PQC" but the actual exposure surface is barely reduced.

    DO Crypto inventory first, even if it is boring and visible to no executive. The inventory IS the project. Hybrid TLS without an inventory is theater.
  2. pure-pqc-too-early HIGH

    Deploying pure-PQC (non-hybrid) too early

    ML-KEM and ML-DSA are mathematically sound but the implementations are young. Side-channel attacks, implementation bugs, and lattice-cryptanalysis surprises remain possibilities. Going pure-PQC removes your classical fallback. Hybrid mode (classical + PQC) is secure under both threat models — broken classical and broken PQC both leave you safe. Almost every production deployment in 2026-2030 should be hybrid, not pure.

    DO Default to hybrid for the migration window. Plan for pure-PQC only when both standards have meaningful production deployment history and implementations have been hardened against side-channel work.
  3. sig-size-blindside MEDIUM

    Underestimating signature + key size impact

    ML-DSA signatures are ~3.3 KB (vs ECDSA's ~64 bytes). ML-KEM public keys are ~1.5 KB (vs X25519's 32 bytes). SLH-DSA signatures can be 8-49 KB depending on parameters. For high-volume signature verification, large signed-blob distribution, low-bandwidth IoT, or anywhere bytes-on-the-wire is a cost driver, the size delta is real. Most enterprise systems absorb it without trouble; some — particularly IoT, blockchain, and CDN edge — need design changes.

    DO Run actual size + perf measurements on your hot paths before mass rollout. Most cases are fine. Some need pre-rollout redesign.
  4. vendor-roadmap-trust MEDIUM

    Trusting vendor "PQC supported" claims without specifics

    Vendor marketing in 2026 includes a lot of "PQC-ready" claims that mean different things: shipping ML-KEM-768 in TLS today, having a roadmap commitment for 2027, supporting a non-standard PQC algorithm from the NIST third round that has since been broken (some early SIKE-based deployments), or simply having a PQC press release. Get specifics in writing for every vendor dependency: which standard (FIPS 203/204/205), what version, what protocols, what timeline.

    DO RFP language for any 2026+ vendor contract: 'specify FIPS 203/204/205 support status, target release version, supported protocols, sunset date for non-PQC algorithms.' Anything vaguer is a gap to track.
  5. embedded-fantasy MEDIUM

    Assuming embedded + IoT will migrate on the same timeline as TLS

    Embedded devices with hardware-baked cryptography accelerators, IoT devices with limited compute, payment terminals with regulatory firmware constraints, vehicle ECUs with 10-15 year lifecycles — none of these migrate cleanly on the 2027-2030 schedule that works for TLS. The honest plan accepts that these surfaces require multi-year roadmaps, vendor cooperation, and in many cases retire-and-replace rather than upgrade. Pretending they will be migrated by 2030 is the most common over-optimism in 2026 PQC programs.

    DO Treat embedded + IoT as a separate program with its own multi-year roadmap. Network segmentation, traffic encryption above the device, and end-of-life planning are first-class controls, not failures of the migration.
  6. crypto-agility-deficit MEDIUM

    Treating PQC as one-time migration vs ongoing crypto agility

    PQC standards may change. ML-KEM and ML-DSA could be hardened, weakened, or replaced as cryptanalysis progresses. Systems built with hardcoded algorithm choices ("use ECDSA") will be in the same position in 2030 they are in today: a multi-year project to swap one algorithm for another. Systems built with crypto agility — abstracted algorithm selection, key management that supports rotation across algorithm families, protocol negotiation with fallback — make the next migration a configuration change.

    DO While you are migrating, build the agility. Algorithm-agnostic key APIs, configurable protocol stacks, key-rotation infrastructure that supports cross-algorithm rotation. Future-you will thank present-you.

Three actions worth taking this quarter regardless of where you sit on the timeline.

  1. 1

    Build the crypto inventory — system of record, not a spreadsheet

    Set up a real system of record for asymmetric crypto usage across the enterprise. Fields per entry: asset_id, location, crypto_type, key_size, owner, criticality, dependency_graph, migration_pathway, target_completion. Populate the TLS layer first (biggest surface, most automation); SSH and HSMs second; signing infrastructure third; long-tail last. Refresh quarterly. This is the deliverable that gates every later decision. Tools: ServiceNow CMDB extensions, dedicated PQC inventory products (IBM Quantum Safe, Sandbox AQ, CryptoNext), or build on your existing asset management system.

  2. 2

    Pilot hybrid TLS on one internal service this quarter

    Pick an HTTPS service with controlled clients (internal admin tool, partner-facing API with managed client SDK). Enable hybrid X25519+ML-KEM-768 on the server. Run a 4-week soak measuring handshake latency, incompatibility rate, log volume changes. Document the runbook. This is operational learning, not security improvement (hybrid is safe either way). The deliverable is the team being ready when the production rollout lands. Cost: 1-2 SRE weeks. ROI: removes the "we have never run PQC in production" excuse.

  3. 3

    Update procurement language for 2026+ contracts

    Add PQC requirements to RFP and contract templates: vendor must commit to a PQC roadmap with specific NIST standard support (FIPS 203/204/205), target release dates, supported protocols, and a sunset timeline for legacy algorithms. Make this contractual, not aspirational. The PQC vendor ecosystem is competitive enough in 2026 that vendors will provide this on request; vendors that will not are signaling something about their roadmap. Procurement language is the lever for vendor coordination at scale.

Six developments that will shape migration scope, pace, and cost over the next 12-24 months.

OpenSSL 3.4+ default cipher behavior

When OpenSSL ships hybrid X25519+ML-KEM as a default option (not just supported) in a stable release, the rollout pace across the open-source server ecosystem accelerates sharply. Watch for 2026-2027 LTS branches.

Browser fleet PQC adoption

Chrome, Edge, Firefox, Safari moving from "supported" to "default-on" for hybrid TLS changes server-side telemetry meaningfully. Expect inflection across 2026.

HSM vendor PQC GA dates

Thales nShield, Entrust nShield, Utimaco SecurityServer, AWS CloudHSM, Azure Managed HSM, Google Cloud HSM — track GA ship dates for FIPS 203/204 support. Multi-year planning depends on this.

Cyber-insurance PQC clauses

When major cyber insurers add PQC posture to renewal questionnaires (likely 2026-2027), enterprise budget conversations get easier. Watch Coalition, Beazley, Munich Re published materials.

Cryptanalysis news on ML-KEM / ML-DSA

Any meaningful cryptanalysis result against the lattice-based standards changes the playbook. Hybrid mode protects you; pure-PQC deployments would need to react fast. Subscribe to IACR ePrint feeds.

NIST IR 8547 finalization

The draft "Transition to Post-Quantum Cryptography Standards" guidance becomes prescriptive once finalized. Federal contractors will treat the final version as compliance baseline.