---
title: "Post-quantum cryptography: standards and migration"
description: "Why migrate before the threat is real Post-quantum cryptography (PQC) means new public-key algorithms designed to resist attacks by both classical and…"
url: https://optimizeall.com/learn/future-tech-horizons/post-quantum-cryptography-migration
updated: 2026-10-05
---

Emerging Tech Horizons: What's Next After Today's AI · Quantum computing and post-quantum security · lesson 9 of 16 · 7 min

# Post-quantum cryptography: standards and migration

## Why migrate before the threat is real

Post-quantum cryptography (PQC) means new public-key algorithms designed to resist attacks by both classical and quantum computers, while running on today's ordinary hardware. The reason to start now is timing: cryptographic migrations historically take many years across large organisations and their suppliers, and data with a long confidentiality life can be captured today and decrypted later.

## The standards (verified as of September 2026)

In August 2024, the US National Institute of Standards and Technology (NIST) published its first three PQC standards:

| Standard | Algorithm | Purpose | Based on |
|---|---|---|---|
| FIPS 203 | ML-KEM | Key encapsulation (establishing shared keys) | CRYSTALS-Kyber |
| FIPS 204 | ML-DSA | Digital signatures | CRYSTALS-Dilithium |
| FIPS 205 | SLH-DSA | Stateless hash-based digital signatures (conservative backup) | SPHINCS+ |

Further work continues: **FN-DSA** (based on FALCON) is being standardised as FIPS 206, and in March 2025 NIST selected **HQC** as an additional key-encapsulation algorithm to serve as a backup to ML-KEM, with a draft standard to follow. Check NIST's Computer Security Resource Center for current status.

NIST's transition guidance (NIST IR 8547) proposes that quantum-vulnerable algorithms such as RSA and elliptic-curve cryptography be **deprecated after 2030 and disallowed after 2035** for US federal systems. The UK National Cyber Security Centre (NCSC) set migration milestones for organisations: complete discovery and an initial plan **by 2028**, complete highest-priority migrations **by 2031**, and complete migration **by 2035**. Other governments and regulators (including in the EU) have issued similar roadmaps. For regulated sectors (finance, telecoms, critical infrastructure), expect supervisors to ask about PQC plans.

## What is already happening

Much of the early migration is happening **inside products you already use**. Major browsers, operating systems, cloud providers and content delivery networks have rolled out **hybrid key exchange** for TLS (combining a classical algorithm with ML-KEM, for example X25519 plus ML-KEM-768), so a lot of web traffic is already protected against harvest-now-decrypt-later. Widely used libraries such as OpenSSL (from version 3.5) include the new algorithms. Messaging apps have also added post-quantum protections.

## A migration plan for a normal organisation

1. **Inventory (cryptographic discovery).** Where do you use public-key cryptography? TLS certificates and endpoints, VPNs, SSH, code signing, document signing, identity systems (SAML, OIDC), payment systems, databases, IoT and OT devices, hardware security modules, and third-party SaaS.
2. **Prioritise.** Rank by data confidentiality lifetime (how long must it stay secret?), exposure (internet-facing?), and system lifetime (devices deployed now that will still run in 2035).
3. **Ask vendors.** Most organisations will migrate mainly by upgrading vendor products. Add PQC questions to procurement and renewals: roadmap, supported algorithms, hybrid modes, timelines.
4. **Crypto-agility.** Design systems so algorithms can be swapped via configuration rather than rewrites. Centralise cryptographic libraries and certificate management.
5. **Test hybrids.** Enable hybrid key exchange where supported and test for compatibility issues (larger key sizes can affect some older network equipment).
6. **Plan long-lived devices and signatures.** Firmware signing, smart meters, vehicles and industrial equipment have long lives; they need attention early.

## Hands-on: check what your systems support

With OpenSSL 3.5 or later installed:

```bash
# List key-encapsulation algorithms your OpenSSL build supports (look for ML-KEM)
openssl list -kem-algorithms

# Test whether a server negotiates hybrid post-quantum key exchange
openssl s_client -connect www.example.com:443 -groups X25519MLKEM768 </dev/null 2>/dev/null | grep -i -E "negotiated|group|Server Temp Key"
```

If the connection succeeds with the hybrid group, the server supports it. Output format varies by version, so read the full handshake summary if the grep shows nothing. Record results in your inventory.

```text
PQC INVENTORY ROW
System | Crypto use | Algorithm now | Data secrecy lifetime | Internet-facing | Vendor PQC roadmap | Priority | Owner | Target date
```

## Worked example: a Pakistani fintech

A fintech in Karachi mapped its cryptography: mobile app to API (TLS via a cloud load balancer), partner bank connections (VPN and mutual TLS), card data (HSM-backed keys), and document e-signatures. Priorities: partner connections (long-lived sensitive data) and signatures on loan contracts (must remain verifiable for years). Actions: enabled hybrid TLS where the cloud provider supported it, added PQC questions to the HSM and e-signature vendor renewals, and set 2028 discovery completion as an internal target aligned with international guidance.

## Pitfalls

- Waiting for a "quantum emergency" before starting inventory.
- Rolling out PQC without testing compatibility.
- Forgetting third parties and long-lived devices.

## How to measure success

Inventory coverage, share of internet-facing endpoints supporting hybrid PQC key exchange, vendors with committed PQC roadmaps, and progress against your milestone dates.

## Video lecture: Post-quantum cryptography: standards and migration

Lecture coming soon · 15 chapters · about 7 minutes. Read the full transcript below.

1. Post-quantum cryptography
2. The first standards (Aug 2024)
3. Why it matters now
4. Changing the locks early
5. Simple example: one inventory row
6. Coming next
7. Timelines
8. Already happening
9. Migration plan, steps 1 to 4
10. Steps 5 and 6
11. Worked example: fintech
12. Crypto-agility in practice
13. Three mistakes
14. Try this now
15. Recap

## Lecture transcript

### Post-quantum cryptography

If quantum computers capable of breaking today's encryption might be years away, why start changing cryptography now? Because big cryptographic migrations take years, and data captured today could be decrypted later. In this lesson you'll learn the new standards, the government timelines, what's already happening in the products you use, and a practical migration plan for a normal organisation.

### The first standards (Aug 2024)

Post-quantum cryptography means new public-key algorithms designed to resist attacks from both ordinary and quantum computers, while running on today's hardware. In August 2024, NIST published the first three standards. FIPS two oh three, ML-KEM, for establishing shared keys. FIPS two oh four, ML-DSA, for digital signatures. And FIPS two oh five, SLH-DSA, a conservative hash-based signature scheme as a backup.

### Why it matters now

Why does this matter now, rather than in ten years? Because cryptography is buried everywhere: websites, VPNs, payment systems, signed software, identity systems, smart devices and supplier connections. Most organisations don't even have a list of where it's used. Governments have published migration timelines, regulated sectors are starting to ask about plans, and vendors are shipping post-quantum options. Starting the inventory now spreads the effort over years, lets you ride vendor upgrades you'd be doing anyway, and avoids a rushed, expensive scramble later.

### Changing the locks early

Here's an analogy. Post-quantum migration is like replacing the locks in a large building before a new kind of lock-pick becomes widely available. Nobody can say exactly when the lock-pick arrives, but you know three things. It will take years to change every lock. Some rooms hold documents that must stay secret for decades. And thieves are already photocopying documents today to open later. So you start with an inventory of every lock, then change the most important ones first.

### Simple example: one inventory row

A simple example of an inventory row. System: customer portal login. Cryptography used: TLS on the web server, managed by your cloud load balancer. Algorithm today: elliptic-curve key exchange. Data secrecy lifetime: customer records, sensitive for many years. Internet-facing: yes. Vendor roadmap: the cloud provider supports hybrid post-quantum key exchange. Priority: high. Action: enable hybrid mode and test with older clients. That's one row, and it's already a plan.

### Coming next

More is on the way. FN-DSA, based on FALCON, is being standardised as FIPS two oh six. And in March 2025, NIST selected HQC as an additional key-establishment algorithm, a backup to ML-KEM built on different mathematics, with a draft standard to follow. Check NIST's official pages for the current status, because these move through drafts and approvals.

### Timelines

Now timelines. NIST's transition guidance proposes deprecating quantum-vulnerable algorithms like RSA and elliptic curves after 2030, and disallowing them after 2035, for US federal systems. The UK's National Cyber Security Centre set three milestones: discovery and an initial plan by 2028, highest-priority migrations by 2031, and full migration by 2035. Other governments, including in the EU, have issued similar roadmaps, and regulated sectors should expect supervisors to ask about plans.

### Already happening

Here's the encouraging part. Much migration is already happening inside products you use. Major browsers, operating systems, clouds and content delivery networks have rolled out hybrid key exchange for TLS, which combines a classical algorithm with ML-KEM. That means a lot of web traffic is already protected against harvest now, decrypt later. OpenSSL added the new algorithms from version three point five, and messaging apps have added post-quantum protections too.

### Migration plan, steps 1 to 4

Your migration plan has six steps. One: inventory where you use public-key cryptography, TLS, VPNs, SSH, code and document signing, identity systems, payments, databases, IoT and OT devices, and SaaS. Two: prioritise by how long data must stay secret, how exposed it is, and how long systems will live. Three: ask your vendors about their roadmaps. Four: build crypto-agility, so algorithms can be swapped by configuration.

### Steps 5 and 6

Five: test hybrid modes, because larger keys can trip up some older network equipment. And six: plan early for long-lived devices and signatures, like firmware signing, smart meters, vehicles and industrial equipment that will still be running in 2035. The lesson text shows two OpenSSL commands you can use to list supported algorithms and check whether a server negotiates hybrid post-quantum key exchange, plus an inventory row template.

### Worked example: fintech

A fintech in Karachi mapped its cryptography: app to API over TLS through a cloud load balancer, partner bank links over VPN and mutual TLS, card keys in hardware security modules, and e-signatures on loan contracts. It prioritised partner links, because the data is sensitive for years, and signatures, because contracts must remain verifiable. It enabled hybrid TLS where the cloud supported it, added PQC questions to vendor renewals, and set a 2028 discovery target in line with international guidance.

### Crypto-agility in practice

What does crypto-agility look like in practice? Keep an up-to-date inventory of certificates and keys, ideally managed centrally. Use well-maintained libraries rather than custom cryptography. Make algorithm choices configuration settings, not hard-coded values. And test changes in staging first. Organisations that did this well for past migrations, like moving away from older hash functions, found the next migration far easier.

### Three mistakes

Three common mistakes. First, waiting for a quantum emergency before starting the inventory, when discovery alone can take a year or more. Second, rolling out new algorithms without testing compatibility, because larger keys and new handshakes can break older devices and network equipment. Third, forgetting third parties and long-lived devices, like payment terminals, industrial controllers and firmware signing, which can't be updated overnight.

### Try this now

Try this now. Pick five systems that matter most to your business, for example your website, customer portal, VPN, payment connection and document signing. For each, fill in one inventory row: what cryptography it uses, how long the data it protects must stay secret, whether it's internet-facing, and what the vendor says about post-quantum support. If you have OpenSSL three point five or later, test one public endpoint for hybrid key exchange using the command in the lesson text. Then email one vendor asking for their post-quantum roadmap.

### Recap

To recap. NIST's FIPS two oh three, two oh four and two oh five are the foundation, with more standards coming. Timelines point to 2030 and 2035, with the NCSC asking for discovery by 2028. Much migration comes through vendors, so inventory, prioritise, ask vendors, build agility, test hybrids and plan long-lived devices. Your next step: inventory five key systems and test one endpoint. Next module: the energy and compute constraints behind AI.

## Key takeaways

- NIST published FIPS 203 (ML-KEM), 204 (ML-DSA) and 205 (SLH-DSA) in August 2024; FN-DSA and HQC are progressing as further standards.
- Guidance points to deprecating RSA and ECC around 2030 and disallowing by 2035; the UK NCSC set 2028, 2031 and 2035 milestones.
- Much early migration happens via vendors, such as hybrid ML-KEM key exchange in browsers, clouds and CDNs.
- Inventory, prioritise by secrecy lifetime and exposure, ask vendors, build crypto-agility, test hybrids and plan long-lived devices.

## Try it

Create a PQC inventory for five of your most important systems, test one public endpoint for hybrid key exchange, and send PQC roadmap questions to one vendor.

- [Previous: Quantum computing: what it is and what it is not](https://optimizeall.com/learn/future-tech-horizons/quantum-computing-basics)
- [Next: Energy, compute and the physical limits of AI](https://optimizeall.com/learn/future-tech-horizons/energy-compute-and-ai-infrastructure)
- [All lessons of Emerging Tech Horizons: What's Next After Today's AI](https://optimizeall.com/learn/future-tech-horizons)