What is Post-Quantum Cryptography (PQC)?

ML-KEM (FIPS 203, formerly CRYSTALS-Kyber) — a key-encapsulation mechanism. Used to securely establish a shared symmetric key between two parties — the role classical RSA-OAEP and ECDH play today. Three parameter sets (ML-KEM-512, -768, -1024) at increasing security strengths. ML-KEM-768 is the practical default for new deployments.

ML-DSA (FIPS 204, formerly CRYSTALS-Dilithium) — a digital signature scheme. Used to sign documents, TLS certificates, software updates, code, anywhere classical RSA and ECDSA signatures are used today. Three parameter sets (ML-DSA-44, -65, -87). ML-DSA-65 is the practical default.

SLH-DSA (FIPS 205, formerly SPHINCS+) — a stateless hash-based signature scheme. Slower than ML-DSA and produces larger signatures, but its security depends only on hash functions — making it a conservative backup if a future cryptanalytic break against lattice-based schemes (ML-KEM, ML-DSA) is found. Recommended for high-assurance signing where signature size is acceptable (root-CA signing, code-signing trust anchors).

A fourth algorithm, HQC, was selected by NIST in March 2025 as a backup KEM based on different mathematical assumptions than ML-KEM. Production tooling is still emerging; ML-KEM remains the default for 2026 deployments.

For symmetric cryptography (AES, SHA-2/3), the impact is smaller: doubling the key size (AES-256 over AES-128, SHA-384 over SHA-256) is generally sufficient against quantum attacks. Symmetric migration is therefore largely a configuration change; asymmetric migration is the hard part.

A cryptographically relevant quantum computer does not exist today. The published consensus among regulator-level guidance (CISA Quantum-Readiness Roadmap, NIST IR 8547, BSI Migration Handbook) treats a CRQC capable of breaking RSA-2048 as a 5-15 year horizon, with significant uncertainty.

The operational reason migration starts now anyway is the harvest-now-decrypt-later model. An adversary with the capability to collect encrypted traffic today (nation-states, well-funded criminal groups) can store it indefinitely. When a CRQC becomes available, the stored traffic is decrypted retroactively. Any data with a confidentiality lifetime that extends past the CRQC arrival date is therefore *already* at risk.

For most operators, this changes priorities:

• High urgency: long-lived secrets, intellectual property, medical records, classified communications, document-signing keys, root CAs.
• Medium urgency: financial transactions visible after settlement, internal communications with multi-year retention.
• Lower urgency: short-lived session data, transient e-commerce traffic.

For critical operators (defence, government, banking, healthcare), the safe operational assumption is that all encrypted exchanges *not yet protected by PQC* are being collected by at least one capable adversary today. The migration question is therefore not "when" but "in what order".

The dominant migration pattern through 2024-2026 is hybrid — classical and PQC algorithms negotiated in parallel, with the session protected only if both are broken. This handles two practical risks: a future cryptanalytic break against ML-KEM (the algorithms are new, so peer review is still active) and interoperability with legacy peers that do not yet support PQC.

TLS 1.3 hybrid key exchange — the IETF-standardised pattern is X25519MLKEM768 (combining the classical X25519 curve with ML-KEM-768). Chrome enabled it by default in 2024 (Chromium PQC announcement); Firefox followed; Cloudflare reported double-digit percentages of TLS traffic using it by late 2024; Apple and Google rolled it across consumer endpoints through 2024-2025. By 2026, the majority of new TLS connections to major sites already use it.

Hybrid certificate signatures — composite signature formats (an X.509 certificate signed by both a classical and a PQC algorithm) are still in late draft. Root CAs are moving toward PQC root keys with classical intermediates as a transitional pattern; full hybrid certificate ecosystems are projected for 2026-2028.

Code-signing — PQC code-signing pilots are underway in Apple, Microsoft, and major Linux distributions; production code-signing using PQC for general developer use is projected through 2027.

The practical implication for operators: hybrid TLS is largely "configure your load balancer and TLS terminator" — possible now. Hybrid signing is harder and requires roadmap planning through 2027-2028.

A practical model used by operators we work with:

Step 1 — Cryptographic inventory (weeks 1-8). You cannot migrate what you do not know you have. Inventory every place classical asymmetric cryptography is used:

• TLS endpoints (web, API, MTLS service mesh, mail, DNS-over-HTTPS).
• Certificate hierarchies (root CAs, intermediate CAs, issuance policies, lifetimes).
• Code-signing keys (CI/CD, container registry, OS package signing, firmware signing).
• Document-signing keys (eIDAS qualified signatures, internal document approval workflows).
• VPN endpoints (IKEv2, OpenVPN, WireGuard — WireGuard uses Curve25519 and needs a PQC successor).
• Disk and DB encryption schemes that wrap symmetric keys with asymmetric ones.
• Hardcoded public keys in firmware, mobile apps, embedded devices.

Step 2 — Prioritise by confidentiality lifetime (weeks 6-12). Each system gets a "data lifetime" tag. Anything where the protected data must remain confidential past the CRQC horizon (5-15 years from now) is high priority.

Step 3 — Hybrid TLS first (months 3-9). Enable hybrid key exchange on TLS endpoints. Most modern load balancers, TLS terminators and reverse proxies now support X25519MLKEM768. This is the lowest-risk, lowest-cost, highest-value first move.

Step 4 — Long-lived signing keys (months 6-24). Plan migration of code-signing trust anchors, document-signing keys, eIDAS qualified signing services. This is multi-year because the trust anchor must be available where verification happens, and old verifiers must continue to work.

Step 5 — Cryptographic agility (continuous). Design new systems with algorithm abstraction so the next migration (classical → hybrid → pure PQC → next-gen PQC) does not require a redesign each time. This is where most legacy systems struggle: cryptographic choices baked in at design time were never expected to change.

For EU operators, the ETSI TR 103 619 PQC migration framework, the BSI migration handbook, and the ANSSI position paper are the converging reference documents. NIS2 implementing measures through 2026-2027 are expected to make PQC migration plans a documented requirement for essential entities. Programs that started inventory and hybrid TLS in 2026 will satisfy that requirement; programs starting in 2028 will not.