Trackr.Live The landing site for Trackr Services
§ Trackr.Live

Post-Quantum Cryptography

Post-Quantum Cryptography (PQC) is the branch of cryptography concerned with primitives that remain secure against adversaries equipped with large-scale quantum computers. The discipline exists because the dominant public-key algorithms of the last fifty years — RSA, Diffie-Hellman, and elliptic curve variants of both — are vulnerable to Shor’s algorithm, which solves the underlying mathematical problems efficiently on a sufficiently large quantum computer. The post-quantum transition is now underway across cryptographic libraries, protocols, certificate ecosystems, and hardware modules, and it is going to be one of the larger multi-year operational programs in deployed cryptography.

This page is the deep-dive companion to the Cryptography umbrella overview and the cryptographic counterpart to a forthcoming Quantum Computing page that will cover the physics and engineering side of building the quantum computers themselves. The scope here is what PQC is, what the standards are, what the mathematical foundations are, and where the migration stands.

The quantum threat in concrete terms

Two quantum algorithms matter for cryptography. Both were published in the 1990s; both were theoretical curiosities for decades; both now drive multi-billion-dollar standardization and procurement programs.

Shor’s algorithm, published by Peter Shor in 1994, solves the integer factoring problem and the discrete logarithm problem in polynomial time on a quantum computer. Every widely-deployed asymmetric primitive in 2026 depends on the hardness of one of these problems:

  • RSA depends on factoring being hard. Shor breaks it.
  • Diffie-Hellman over finite fields depends on discrete log being hard. Shor breaks it.
  • Elliptic Curve Diffie-Hellman (ECDH) depends on the elliptic curve discrete log problem. Shor breaks it.
  • ECDSA, EdDSA, and RSA signatures all depend on one of the above. Shor breaks all of them.

A sufficiently large quantum computer running Shor’s algorithm can recover an RSA private key from the public key, derive a shared DH secret from the public exchange, and forge ECDSA signatures. The asymmetric layer of modern cryptography — the part that solves the key distribution problem — collapses entirely.

Grover’s algorithm, published by Lov Grover in 1996, provides a square-root speedup for unstructured search problems. The cryptographic implication is more limited: against symmetric ciphers, Grover reduces the effective key length by half. AES-128 retains 64 bits of security against a Grover-capable quantum adversary, which is uncomfortably close to brute-force range. AES-256 retains 128 bits, which is well out of reach.

Against cryptographic hash functions, Grover reduces preimage resistance from n bits to n/2 bits. SHA-256 retains 128 bits of preimage resistance. SHA-512 retains 256 bits.

The collision-resistance picture is more complex. The Brassard-Høyer-Tapp algorithm provides a cube-root speedup for finding collisions, reducing collision resistance from n/2 bits to n/3 bits, but the algorithm requires substantial quantum memory and in practical analyses provides less speedup than its theoretical bound. The standard recommendation is to use 384-bit or 512-bit hash outputs where 256-bit was previously sufficient.

The summary: symmetric cryptography survives with larger parameters. Asymmetric cryptography needs entirely new primitives.

“Sufficiently large” — the timeline question

The unresolved question is when a cryptographically-relevant quantum computer will exist. Current state-of-the-art quantum computers operate with on the order of 1,000 to 1,500 noisy physical qubits. Quantum error correction is required to convert noisy physical qubits into reliable logical qubits, with the conversion ratio depending on the error correction code and the physical error rate — typical estimates require 1,000 to 10,000 physical qubits per logical qubit.

Estimates of the resources required to break RSA-2048 vary widely depending on the error correction approach assumed:

  • Early estimates (2012-2015) suggested roughly 20 million physical qubits would be required, running for hours.
  • More recent estimates with improved algorithms and error correction (Gidney and Ekerå, 2019; Litinski, 2023) bring the number down toward 4,000-10,000 logical qubits, which still implies millions of physical qubits at current error rates.
  • Continued algorithmic improvements may reduce the requirements further, and continued improvements in physical qubit quality may reduce the overhead per logical qubit.

The gap between current capability (low thousands of physical qubits, dozens of logical qubits at best) and what would be needed to run Shor against RSA-2048 (millions of physical qubits) is several orders of magnitude. Closing the gap requires engineering progress that has been happening but is not guaranteed to continue at any particular rate.

Public estimates of when a cryptographically-relevant quantum computer (CRQC) will exist range from a decade to several decades. There is no scientific consensus, and the estimates from credible researchers span a wide range. The Mosca Theorem, framed by Michele Mosca, asks: if it takes Y years to migrate to PQC, the data must remain confidential for X years after that, and a quantum computer arrives in Z years — then if X + Y > Z, you are already late. For a Z somewhere between 10 and 30 years and an X for sensitive long-lived data of 10-50 years, the migration has to start now even if the quantum threat is structurally distant.

This is the threat model that drives PQC’s urgency: harvest now, decrypt later. An adversary with the capability to record and store internet traffic today can decrypt it whenever a sufficiently large quantum computer arrives. For data that must remain confidential into the 2040s or beyond, the encryption needs to be quantum-safe today.

The NIST standardization process

NIST began the post-quantum standardization effort in 2016 with a public call for proposals. The structure echoed the AES competition of the late 1990s: open submissions, public review, multi-round elimination, eventual selection of standards. The PQC process was longer and substantially more complex than AES.

Round 1 (2017-2019) received 82 submissions, of which 69 met the technical requirements and were accepted for evaluation. The submissions spanned the major mathematical families and represented work from research groups across academia, industry, and government cryptographic services worldwide.

Round 2 (2019-2020) narrowed the field to 26 candidates: 17 public-key encryption and key encapsulation mechanisms (KEMs), and 9 signature schemes.

Round 3 (2020-2022) further narrowed to 7 finalists and 8 alternates. The finalists included CRYSTALS-Kyber (lattice-based KEM), CRYSTALS-Dilithium (lattice-based signature), Falcon (lattice-based signature), SPHINCS+ (hash-based signature), Classic McEliece (code-based KEM), NTRU (lattice-based KEM), and Saber (lattice-based KEM).

Final selections (2022) announced CRYSTALS-Kyber as the primary KEM standard, with CRYSTALS-Dilithium, Falcon, and SPHINCS+ as the signature standards. Four additional KEMs (Classic McEliece, BIKE, HQC, SIKE) advanced to Round 4 for additional evaluation as potential backup standards in case the primary selections needed alternatives.

The SIKE break (July 2022) is the part of this story that should never be skipped. SIKE was a Round 4 candidate based on supersingular isogeny mathematics — a mathematical family entirely distinct from lattices, codes, and hashes. Within weeks of the Round 4 announcement, Wouter Castryck and Thomas Decru at KU Leuven published a classical attack that recovered SIKE private keys in roughly an hour on a single CPU core. Not a quantum attack; not a side-channel; a classical mathematical attack against the underlying problem. SIKE went from finalist-track candidate to completely broken within a single paper. The Castryck-Decru attack is the most dramatic late-stage break in the modern standardization era, and it serves as a sobering reminder that “no known attack” and “no possible attack” are different claims.

The FIPS standards (August 2024) finalized the first three standards:

  • FIPS 203 — Module-Lattice-Based Key Encapsulation Mechanism Standard (ML-KEM), based on CRYSTALS-Kyber.
  • FIPS 204 — Module-Lattice-Based Digital Signature Standard (ML-DSA), based on CRYSTALS-Dilithium.
  • FIPS 205 — Stateless Hash-Based Digital Signature Standard (SLH-DSA), based on SPHINCS+.

A fourth standard, FIPS 206 (FN-DSA, based on Falcon), is in draft and expected to finalize in 2026. The slower path for Falcon reflects implementation complexity — Falcon requires floating-point operations during signing, which complicates side-channel-resistant implementation — rather than any concern about the underlying security.

A separate track for KEMs is examining HQC and BIKE as potential backup KEM standards using different mathematical foundations from the lattice-based ML-KEM, to provide algorithm diversity in case future cryptanalysis reveals weaknesses in lattice-based constructions.

The mathematical families

Five mathematical foundations have produced credible PQC candidates. Three made it through to standardization; one was eliminated dramatically late; the fifth is structurally promising but operationally awkward.

Lattice-based cryptography

The dominant family in the finalized NIST standards. Lattice-based constructions rest on the hardness of problems related to finding short vectors in high-dimensional lattices, or solving systems of equations modulo a polynomial ring.

The specific problems underpinning the standards:

  • Module Learning With Errors (Module-LWE) — underlies ML-KEM. Variant of the broader Learning With Errors problem that uses module structure to achieve better performance while retaining strong security arguments.
  • Module Short Integer Solution (Module-SIS) — underlies ML-DSA’s signature security.
  • NTRU — a separate lattice variant that did not advance to the final standards but is structurally similar.

The security arguments for lattice problems are strong but not as deeply analyzed as RSA or ECC — lattice cryptography has been studied for roughly thirty years, against fifty for RSA and twenty-five for elliptic curves. The depth of analysis is sufficient for confidence at the current parameter sets, but the field is younger.

Lattice constructions have moderate key sizes (1-2 KB), moderate signature sizes (3-4 KB for ML-DSA), and fast operations (typically faster than RSA-3072 on modern hardware). The combination makes them the practical choice for most general-purpose PQC deployment.

Hash-based signatures

Hash-based signature schemes — Lamport, Merkle, XMSS, LMS, SPHINCS+ — derive their security from the properties of cryptographic hash functions alone. This is conservatively the strongest security foundation available: if SHA-256 is preimage-resistant against quantum adversaries (which Grover only reduces by a square-root factor), then hash-based signatures are secure.

SLH-DSA (FIPS 205), based on SPHINCS+, is the stateless hash-based standard. The “stateless” qualifier matters because earlier hash-based schemes (XMSS, LMS) require the signer to maintain state — specifically, which one-time signatures have already been used. State management is operationally fragile (a backup that restores stale state can produce signature collisions that catastrophically compromise the key). SLH-DSA eliminates the state requirement at the cost of much larger signatures: 7 KB to 49 KB depending on parameter set, against 3-4 KB for ML-DSA.

SLH-DSA is the conservative choice for applications where signature size matters less than maximum security confidence: long-term root signing keys, firmware signing for devices expected to remain in service for decades, transparency-log signing where the signature is signed once and verified many times.

The stateful XMSS and LMS schemes (specified in RFC 8391 and RFC 8554 respectively) remain available for applications that can manage the state requirements. NIST published SP 800-208 specifically for stateful hash-based signatures used in long-term archival contexts, primarily for code signing for devices that must remain trustworthy for decades.

Code-based cryptography

Based on the hardness of decoding general linear codes, code-based cryptography has the longest research history of any PQC family — McEliece’s original proposal dates to 1978, four years after RSA. Classic McEliece is the canonical Round 4 candidate and remains a strong contender for standardization as a backup KEM.

The strength of code-based cryptography is the maturity of its security analysis — fifty years of attacks have been thrown at the McEliece construction, and the parameters have been adjusted in response, but the underlying problem remains. The weakness is key size: McEliece public keys are typically 250 KB to 1 MB, against 1-2 KB for ML-KEM. The size makes deployment in bandwidth-constrained contexts impractical.

For applications that can absorb the key size and benefit from the security history (long-lived encrypted archives, satellite communications, certain government use cases), code-based cryptography is a legitimate option. For general-purpose internet protocols, the size cost is typically prohibitive.

Multivariate cryptography

Based on the hardness of solving systems of multivariate quadratic equations over finite fields. The family was represented in the NIST competition primarily by Rainbow, a signature scheme that advanced to Round 3 as a finalist.

Rainbow was broken in February 2022 by Ward Beullens, whose attack reduced the security of the standardized parameter sets from claimed 128 bits to roughly 53 bits using a classical algorithm. Like SIKE, Rainbow’s break was a classical mathematical attack against the underlying problem, not a quantum attack. The break eliminated multivariate cryptography from the standardization track.

Multivariate cryptography continues as a research area, but no multivariate scheme is currently positioned for standardization. The family’s relevance to deployed PQC in 2026 is essentially zero.

Isogeny-based cryptography

Based on the hardness of finding isogenies between supersingular elliptic curves. The family was the most exotic of the PQC candidates and produced SIKE, which advanced through three rounds before being broken in 2022 by the Castryck-Decru attack.

Isogeny-based cryptography continues as a research area, with new variants (such as SQISign and CSIDH) that are not vulnerable to the Castryck-Decru attack. Whether any of these will reach standardization is an open question. For the current standardization round, the family is effectively out.

The finalized standards in operational terms

ML-KEM (FIPS 203)

Module-Lattice-Based Key Encapsulation Mechanism. Three parameter sets:

  • ML-KEM-512 — claimed security comparable to AES-128. 800-byte public key, 1632-byte secret key, 768-byte ciphertext.
  • ML-KEM-768 — claimed security comparable to AES-192. 1184-byte public key, 2400-byte secret key, 1088-byte ciphertext.
  • ML-KEM-1024 — claimed security comparable to AES-256. 1568-byte public key, 3168-byte secret key, 1568-byte ciphertext.

ML-KEM is a KEM (Key Encapsulation Mechanism), not a public-key encryption scheme directly. The distinction is structural: a KEM takes a public key and produces a shared symmetric key plus a ciphertext containing the encapsulated key material. The shared key is then used for symmetric encryption of actual data. The pattern is the cryptographic equivalent of “use ECDH to agree on a session key, then encrypt the data with AES-GCM,” but with ML-KEM substituted for ECDH.

ML-KEM-768 is the recommended general-purpose parameter set and is what major deployers (Cloudflare, Google, Apple, Signal) have been rolling out in their hybrid post-quantum deployments.

ML-DSA (FIPS 204)

Module-Lattice-Based Digital Signature Algorithm. Three parameter sets:

  • ML-DSA-44 — claimed security comparable to AES-128. 1312-byte public key, 2560-byte private key, 2420-byte signature.
  • ML-DSA-65 — claimed security comparable to AES-192. 1952-byte public key, 4032-byte private key, 3309-byte signature.
  • ML-DSA-87 — claimed security comparable to AES-256. 2592-byte public key, 4896-byte private key, 4627-byte signature.

ML-DSA signatures are 3-5 KB, against 64 bytes for Ed25519 and 256-512 bytes for RSA. The size difference dominates the deployment cost: TLS handshakes that include certificate chains see the cumulative signature size become a material fraction of the handshake bytes.

ML-DSA-65 is the recommended general-purpose parameter set.

SLH-DSA (FIPS 205)

Stateless Hash-Based Digital Signature Algorithm. Twelve parameter sets, varying in security level (128, 192, 256-bit), hash function (SHA-2 or SHAKE), and the small-signature vs. fast-signing tradeoff:

  • Small signature variants produce ~7-30 KB signatures with slower signing.
  • Fast signing variants produce ~17-49 KB signatures with faster signing.

SLH-DSA signatures are dramatically larger than ML-DSA signatures (5-10x in the typical case) and signing is slower (typically by a factor of 10-100x). The cost is justified by the conservative security argument — SLH-DSA depends only on the security of its underlying hash function, with no algebraic assumptions about lattices.

SLH-DSA is the right choice when the signing-cost / signature-size tradeoff favors signature trust over performance: firmware signing for long-lived devices, CA root signing, transparency log signing, code signing where verifications dramatically outnumber signings.

FN-DSA (FIPS 206, in draft)

Fast-Fourier Lattice-Based Compact Digital Signature Algorithm. Based on Falcon. Smaller signatures (666 bytes for Falcon-512, 1280 bytes for Falcon-1024) and smaller public keys (897 and 1793 bytes respectively) than ML-DSA. The size advantage is significant, particularly in bandwidth-constrained contexts.

The cost of FN-DSA is implementation complexity. Falcon signing requires high-precision floating-point operations, which complicates constant-time implementation (preventing timing side channels) and which produces correctness sensitivities to floating-point environment that are unusual in cryptographic code. NIST has been deliberate about the standardization timeline, requiring extensive analysis of the floating-point sensitivity questions before publishing the final standard.

FN-DSA is expected to be available in 2026 and will be the right choice for applications where the smaller signature size matters and the implementation complexity is acceptable.

Hybrid deployment

The dominant pattern for production PQC deployment in 2026 is hybrid: run a classical primitive (X25519 or P-256) alongside a post-quantum primitive (ML-KEM-768), and combine their outputs through a key derivation function to produce the actual session key.

The hybrid construction protects against two distinct risks:

  • Classical attacks against the post-quantum primitive. ML-KEM has been studied for less than a decade. If a classical break is discovered (à la SIKE or Rainbow), the classical component continues to provide security.
  • Quantum attacks against the classical primitive. If a quantum computer arrives, the classical primitive is broken, but the post-quantum component continues to provide security.

The cost of hybrid is real: every cryptographic operation costs roughly twice as much (both the classical and PQ primitives run), every handshake is larger (both classical and PQ public keys are transmitted), and the implementation complexity is higher. The benefit is a smooth migration path that does not bet the entire security argument on a single relatively-new primitive.

Production hybrid deployments in 2026:

  • Cloudflare has shipped hybrid X25519+ML-KEM-768 in their TLS infrastructure since 2023, with substantial deployment statistics published showing handshake performance impact on the order of single-digit milliseconds.
  • Google Chrome ships X25519+ML-KEM-768 for connections to Google services, with rollout to general-purpose TLS proceeding through 2024-2025.
  • Apple iMessage has deployed PQ3, a hybrid PQ key agreement protocol for iMessage end-to-end encryption, since iOS 17.4 in early 2024.
  • Signal Protocol added PQXDH (Post-Quantum Extended Diffie-Hellman) in late 2023, providing PQ-resistant initial key agreement for new Signal conversations.
  • OpenSSH added hybrid post-quantum key exchange (sntrup761x25519 initially, ML-KEM variants emerging) in OpenSSH 9.0 and later.

The pattern across these deployments: hybrid first, with the post-quantum component sized for ~192-bit equivalent security, layered onto existing classical primitives without removing them. The migration to PQ-only mode is years away and will depend on accumulated confidence in the PQ primitives.

Size implications and protocol impact

The most operationally visible consequence of the PQC transition is size. Classical asymmetric primitives have small public keys and small signatures. Post-quantum primitives have substantially larger ones. The downstream impact on protocols, certificates, and storage is non-trivial.

Comparative sizes for typical-security-level deployments:

Primitive Public key Private key Signature/Ciphertext
Ed25519 32 B 64 B 64 B
X25519 32 B 32 B — (KEM ciphertext: 32 B)
RSA-3072 384 B 1.5 KB 384 B
ML-KEM-768 1.2 KB 2.4 KB 1.1 KB
ML-DSA-65 2.0 KB 4.0 KB 3.3 KB
Falcon-512 897 B 1.3 KB 666 B
SLH-DSA-128s 32 B 64 B 7.9 KB
SLH-DSA-128f 32 B 64 B 17 KB

The deployment consequences fall into several categories.

TLS handshakes absorb a roughly 2 KB increase per direction when ML-KEM-768 is added to the ClientHello and ServerHello. For initial connections this is a meaningful fraction of the handshake size; for connection establishment over slow links (mobile, satellite) the latency impact is measurable.

Certificate chains would grow substantially if both intermediate and root certificates use ML-DSA signatures. A typical TLS certificate chain with ECDSA P-256 signatures is roughly 3-5 KB total; the same chain with ML-DSA-65 signatures would be 15-25 KB. For protocols that ship the full chain on every handshake, this is a non-trivial bandwidth cost. The migration to PQ certificates is therefore being staged carefully — likely starting with leaf certificates while intermediates and roots remain classical for longer.

QUIC has a particular sensitivity to ClientHello size because the initial QUIC packet must fit within a single UDP datagram. The hybrid ML-KEM ClientHello fits but with less margin than the classical version, and additional protocol extensions could push it over the threshold. This has been a topic of active discussion in the IETF QUIC and TLS working groups.

Embedded and constrained devices face the sharpest tradeoffs. A device with limited storage for cryptographic keys, limited RAM for cryptographic operations, or limited bandwidth for cryptographic exchanges may struggle to accommodate post-quantum primitives at all. The IoT industry will likely need to develop specialized PQ profiles that trade additional security margin for smaller parameter sets.

Performance characteristics

The performance picture is less dire than the size picture but worth understanding for protocol designers.

ML-KEM operations are fast — comparable to or slightly faster than RSA-3072 operations and within a small factor of X25519. Public key generation, encapsulation, and decapsulation all run in low single-digit microseconds on modern x86 servers. The performance is good enough that ML-KEM is not a bottleneck in TLS handshakes.

ML-DSA operations are slower. Signing is comparable to RSA-3072 signing; verification is faster. The combination is acceptable for general-purpose use but noticeably more expensive than Ed25519 verification.

SLH-DSA operations are dramatically slower than ML-DSA. Signing can take milliseconds; verification is faster but still measured in milliseconds. SLH-DSA is not appropriate for high-frequency signature operations; it is appropriate for occasional high-trust signing (firmware images, code signing, CA root operations).

FN-DSA (Falcon) operations are fast in both directions, with the implementation-complexity caveat noted above.

Hardware acceleration for PQC primitives is emerging. Intel announced PQC-specific instructions for Sapphire Rapids and successor generations. ARM has announced PQ-specific extensions in upcoming SBSA generations. The acceleration will reduce the performance gap over time but is not universal yet.

The migration challenge

Migrating an existing cryptographic deployment to post-quantum involves several distinct work streams.

Cryptographic library support. The major libraries are adding PQC primitives:
– BoringSSL has shipped ML-KEM hybrid support since 2023.
– OpenSSL 3.5 (March 2025) added ML-KEM and ML-DSA support natively.
– The Go standard library added ML-KEM support in Go 1.24.
– Rustls and rust-crypto have ongoing PQC integration work.
– WolfSSL, mbedTLS, BoringSSL forks for embedded are adding PQC variants.

Protocol updates. TLS 1.3 supports PQ hybrid key exchange through standard mechanisms (the named_group extension carries hybrid identifiers). SSH, IPsec, Signal Protocol, MLS (Messaging Layer Security), and other protocols are adding PQ support through their respective standardization tracks.

Certificate ecosystem. Public CAs are beginning experimental issuance of PQ certificates, but production deployment is gated on browser support, root program acceptance, and the size-impact analysis described above. The CAB Forum has been working through the operational requirements; the first publicly-trusted PQ certificates at scale are likely in 2027-2028.

HSMs and hardware modules. Existing HSMs need firmware updates to support PQ primitives. Older HSMs may have storage or compute constraints that prevent PQ support entirely, requiring hardware replacement. The major HSM vendors (Thales, Entrust, AWS CloudHSM, Google Cloud HSM, Azure Key Vault Premium) are rolling out PQ support through 2025-2027.

Cloud KMS. AWS, Google, and Azure are adding PQ algorithm support to their KMS offerings, with timelines staged through 2025-2027. The migration pattern is to add PQ algorithms as new options while continuing to support classical algorithms for existing keys.

Application code. Most applications use high-level cryptographic libraries that abstract the primitive choice, so the migration is primarily a configuration change. Applications that have hardcoded specific algorithms or that have built protocol-level logic around specific key sizes may require more invasive changes.

The migration is a multi-year operational program for any organization with substantial cryptographic infrastructure. The timeline is gated more by ecosystem readiness (HSMs, certificates, protocols) than by any single organization’s ability to deploy.

Quantum-safe symmetric cryptography

Symmetric cryptography is far less affected by the quantum transition than asymmetric is, but it is not entirely unaffected. The standard mitigation is doubled parameter sizes:

  • AES-256 instead of AES-128 (post-quantum safe by current understanding).
  • SHA-384, SHA-512, SHA3-384, SHA3-512, or SHAKE256 with appropriate output length instead of 256-bit hashes.
  • HMAC and KMAC with the larger underlying hash functions.

The cost is modest. AES-256 is roughly 40% slower than AES-128 on hardware-accelerated implementations; the slowdown is invisible at the protocol level for almost all applications. SHA-512 is faster than SHA-256 on 64-bit hardware. The migration to larger symmetric parameters is essentially a configuration choice rather than an algorithm replacement.

Many modern protocols already default to the larger parameters: TLS 1.3 supports AES-256-GCM as a standard cipher suite, modern signing protocols use SHA-384 or SHA-512 hashes, and the trend in protocol design has been toward 256-bit symmetric security regardless of the quantum question.

What to actually do in 2026

For new systems, the practical recommendations:

  • Symmetric: AES-256 by default. SHA-384 or SHA-512 for hash functions. The cost is negligible and the protection is durable.
  • Key agreement in protocols you control: hybrid X25519+ML-KEM-768. The cost is modest, the protection is forward-looking, and the library support has reached production quality.
  • Key agreement in protocols you don’t control: wait for the protocol’s standardization track to deliver PQ support. Don’t implement custom hybrid constructions; the failure modes are subtle and the standards exist.
  • Signatures for high-value, low-frequency operations: SLH-DSA for firmware signing, CA root signing, transparency log signing — anywhere the signature size and signing cost are bearable and the conservative security argument is valuable.
  • Signatures for high-frequency operations: classical ECDSA or Ed25519 for now, migrating to ML-DSA-65 as protocol and certificate support reaches production. For mixed deployments, hybrid signatures that include both classical and PQ are the safest transition path.
  • Certificates: continue using classical certificates while monitoring CA and root program rollout of PQ certificates. The migration here is gated by ecosystem readiness, not by individual deployment choices.
  • Key management: verify that HSMs, TPMs, and cloud KMSes have PQ roadmaps that align with the application’s confidentiality timeline. If long-lived secrets are being held in hardware that cannot accept PQ keys, the hardware migration is on the critical path.
  • Harvest-now-decrypt-later mitigation: for traffic that must remain confidential into the 2040s or beyond, enable hybrid PQ key exchange now. Every connection using only classical key exchange today is potentially harvestable for future decryption.

Avoid: deploying experimental or non-standardized PQ primitives in production (the standards are now stable, use them), assuming that the PQ migration is a future problem (the harvest-now threat is present), and treating the PQ transition as an algorithm-substitution project (it’s an ecosystem migration, with corresponding orchestration complexity).

The post-quantum transition is real, the standards are now stable, the libraries are catching up, and the major deployers have started shipping hybrid configurations. The migration is going to take years. For most organizations, the right posture in 2026 is to enable hybrid PQ where it’s available, plan the HSM and certificate-management migration as a multi-year program, and accept that the cryptographic stack is going to look meaningfully different in 2030 than it did in 2020. The discipline has been through transitions before — DES to AES, MD5 to SHA-2, SHA-1 to SHA-2 — and each one took years. This one will take longer because it touches more layers of the stack, but the trajectory is the same.