Post-Quantum Cryptography — A Realistic Migration Plan (FIPS 203 / 204 / 205 in the Field)

NIST finalized the first set of post-quantum cryptography standards in 2024: FIPS 203 (ML-KEM, formerly Kyber) for key establishment, FIPS 204 (ML-DSA, formerly Dilithium) for digital signatures, and FIPS 205 (SLH-DSA, formerly SPHINCS+) for hash-based signatures. The migration from RSA and elliptic-curve cryptography to PQC will take most enterprises 5 to 10 years. The work that must start in the next quarter is inventory and crypto-agility — not algorithm replacement at scale.

This piece is the migration plan that survives a CFO who asks 'why now?' and an engineering team that asks 'what do you actually want me to ship?'.

The four threats to plan against

The four work-streams that have to start this quarter

1. 01Cryptographic inventory. Catalog every place a quantum-vulnerable algorithm runs — TLS termination, IPsec, SSH, code signing, document signing, JWT signing, key wrapping, crypto in OT / embedded firmware, certificates and CAs. Most enterprises find 2–3x more cryptographic surface than expected.
2. 02Crypto-agility audit. For each cryptographic use, can the algorithm be swapped without code changes? If the answer is 'no' for any item, that is the next 18 months of engineering work — independent of which PQC algorithm wins.
3. 03Long-confidentiality data identification. Tag data by required confidentiality horizon. Anything > 10 years (medical records, government secrets, IP, customer PII for regulated industries) goes into a prioritized migration tier.
4. 04Vendor PQC roadmap pressure. Every commercial product that performs cryptography on your behalf should publish its PQC roadmap. If they cannot, that is procurement signal.

Hybrid is the transition design — not a workaround

Hybrid cryptography combines a classical algorithm (X25519, P-256) with a PQC algorithm (ML-KEM-768) such that breaking the hybrid requires breaking BOTH. This is the explicit recommendation of NIST, the IETF, and the major TLS libraries. Pure-PQC deployment is premature: PQC algorithms are new, the implementation surface is young, and side-channel research is ongoing. Hybrid lets you start migrating without taking implementation risk.

# Server config snippet — accept hybrid groups while still
# permitting classical for clients that have not migrated.

# Order matters: hybrids first, classical as fallback.
ssl_groups = "X25519MLKEM768:X25519:secp256r1"

# Logging: per-handshake group selection.
# Use this to measure migration % over time.
log_format = "$client_ip $tls_group $tls_version"

# Sample query for migration KPI:
#   SELECT tls_group, COUNT(*)
#   FROM   tls_handshake_log
#   WHERE  ts >= NOW() - INTERVAL '24h'
#   GROUP  BY tls_group;

Signatures are the harder migration

Key-establishment migration (KEMs) is operationally tractable: a TLS handshake either negotiates the new group or it does not. Signature migration is harder because signed artifacts are long-lived. A firmware image signed with RSA today must remain verifiable 15 years from now — and a future device must trust both the legacy signature and the new PQC signature during transition.

• 01Code signing — dual-sign (classical + PQC) for the transition window; verifiers accept either
• 02Document signing — append PQC signatures alongside legacy; CA hierarchy must support both
• 03JWT / API tokens — short-lived, easy to migrate; algorithm-agility in token validators is the prerequisite
• 04Firmware (OT, automotive, medical) — multi-year planning; coordinate with the standards bodies for the device class

What does NOT require action this year

Discipline matters. The temptation to over-invest in PQC right now is real — vendors are happy to encourage it. The following items are explicit non-priorities for 2026.

• 01Wholesale algorithm replacement across non-sensitive workloads — wait for crypto-agility first
• 02Pure-PQC deployment outside pilots — hybrid is the right design
• 03Investment in algorithms that have not been NIST-finalized — let the standards stabilize
• 04Replacement of crypto in devices that will retire before 2035
• 05Migration of authentication-only TLS where confidentiality horizon is < 24 hours

Five KPIs that prove the migration is on track

A 24-month plan

1. 01Months 0–6 — Cryptographic inventory + long-confidentiality data tagging. Stand up the PQC program owner. Begin crypto-agility audit for the top 20 systems by data sensitivity.
2. 02Months 6–12 — Crypto-agility remediation in the top 20 systems. Hybrid TLS pilot in non-production. Vendor-roadmap pressure on all cryptographic-product procurement.
3. 03Months 12–18 — Hybrid TLS in production for high-confidentiality endpoints. Begin code-signing dual-sign for new releases. Sign the first PQC-capable internal CA hierarchy.
4. 04Months 18–24 — Expand hybrid TLS coverage. Brief board against the five KPIs. Re-baseline plan for 2028 with the latest standards-body guidance.

Closing — start the clock, do not start the panic

Post-quantum cryptography is a 5–10 year migration that hides behind a deceptively short news cycle. The work this year is mundane: inventory, crypto-agility, identification of long-confidentiality data. The work in years two and three is hybrid deployment for the highest-value endpoints. The work after that is dictated by where the standards and the implementation surface settle. Treat it as a discipline, not a fire drill, and the program ends gracefully a decade from now — well before any adversary has the hardware that justified starting it.