Most security teams in 2026 know that post-quantum cryptography is coming. Most security teams have not yet done the inventory, picked the migration order, or stood up the parallel signature paths needed to make the migration boring instead of painful. This topic is for the security lead, the CTO, and the senior engineer who has been told to “sort PQ” and isn't sure where to start.
The migration is not optional. The threat model is straightforward and the deadlines are now public. The good news is that the work is well-scoped. The bad news is that putting it off until 2028 will be expensive in a way that putting it off until 2027 won't be.
The threat model in one paragraph
A cryptographically-relevant quantum computer (CRQC) — large enough to run Shor's algorithm against today's RSA-2048 and Elliptic Curve key sizes — does not yet exist publicly. It will, within the decade, on most credible technical roadmaps. Once it does, every recorded encrypted exchange that used a vulnerable scheme can be retroactively decrypted. This is the “harvest now, decrypt later” threat. It applies today, because adversaries are already harvesting traffic in anticipation. Anything you encrypt this year that needs to stay confidential into the 2030s should already be PQ-protected.
What NIST has standardised
NIST's PQ standards landed in mid-2024 and have been finalised through 2025–2026. The three you actually need to know:
- ML-KEM (was Kyber) — the standard for key encapsulation, replacing RSA and Diffie–Hellman key exchange. This is the first one to deploy because every TLS handshake uses it.
- ML-DSA (was Dilithium) — the standard for digital signatures, replacing RSA and ECDSA in most contexts.
- SLH-DSA (was SPHINCS+) — a stateless hash-based signature scheme, recommended for long-lived signing keys (root CAs, firmware signing).
Every credible TLS library now ships with hybrid post-quantum support — typically as X25519MLKEM768 for the key exchange. Recent OpenSSL, BoringSSL, and rustls support it. Modern browsers negotiate it by default. The pieces are in place; the work is making sure your stack actually uses them.
What to migrate first
The migration order that minimises pain at IMPT.io and at every team we've helped looks like this:
1. TLS termination — fastest win, biggest coverage
Make sure your TLS terminators (load balancers, CDN, application servers) negotiate the hybrid PQ key-exchange suites. For most modern stacks this is a configuration change, not a code change. After this is done, all of your in-flight TLS traffic is harvest-now-decrypt-later resistant. This single change covers most of your real exposure.
2. Long-lived data at rest
Anything encrypted with a key derived from RSA or ECDH that has a long retention horizon — backups, archives, logs you keep for compliance — gets re-wrapped with a PQ-derived KEK. Quietly, in the background, no user-facing change. The work is in the key-management plumbing, not the application.
3. Software supply-chain signatures
Firmware-signing keys, package-signing keys, and root CAs that are baked into clients today and will live for ten years. These get migrated to SLH-DSA or hybrid signatures. The migration is annoying because the consumers of those signatures are field-deployed, but the deadline is real and the cost of being late is high.
4. Authentication and code-signing for short-lived artefacts
OAuth tokens, JWTs, transient session signatures. These are the lowest priority because the artefacts are short-lived enough that “harvest now, attack later” doesn't apply, and short-lived signatures can be migrated later as a routine refresh.
Hybrid is the right answer for the next two years
Do not rip out the existing classical schemes and replace them with PQ-only. Run both in parallel — a hybrid signature is a classical signature plus a PQ signature, both required to verify. This protects against two failure modes: the unlikely-but-possible discovery of a flaw in the new PQ schemes, and the certainty of operational incidents during the migration. Hybrid mode is what every major TLS library has converged on, and it is what your application crypto should converge on too.
Common pitfalls
- Performance assumptions. ML-KEM keys are larger than ECDH keys. ML-DSA signatures are larger than RSA-2048 signatures. The performance impact on a single TLS handshake is small; the impact on a high-volume signing service can be larger. Measure before you migrate; do not assume.
- HSM compatibility. Your hardware security modules may not yet support ML-DSA or ML-KEM in firmware. Check before you commit a migration plan; add HSM upgrades to the timeline if needed.
- Library churn. The PQ libraries are mature but the surface area is still moving. Pin versions; test thoroughly; do not auto-upgrade across major versions in production crypto code.
- Confusing PQ with PFS. Perfect Forward Secrecy and post-quantum cryptography are orthogonal. You want both. Make sure your migration preserves PFS — most do, but some early hybrid implementations didn't.
- Forgetting the long tail. Internal services, RPC layers between microservices, message-queue encryption, intra-data-centre traffic. The migration plan needs to cover everything, not just the user-facing TLS edge.
What we'll do in the workshop
Day 2 afternoon of the Clonmel workshop walks through a real PQ migration plan for a sample stack: TLS, message queue, data-at-rest, and signing. Bring your own architecture diagram if you have one — we will spend the second half of the session doing per-attendee migration plans for whatever you bring in. Everyone leaves with the next three months of crypto work mapped out.