Post-Quantum Cryptography Migration

Post-quantum cryptography (PQC) migration is the work of replacing vulnerable public-key cryptography across protocols, libraries, devices, and operational processes. It starts with knowing where cryptography is used and what each dependency can support.

Reviewed October 5, 2026. This article covers selected developments from October 5, 2025 through October 5, 2026, with earlier standards identified as background. Its inventory and rollout examples are engineering recommendations, not a claim that every product already supports every algorithm.

TL;DR

Quick Example

Run this standalone Python 3 example to turn a small, fictional inventory into an owner-assigned review queue. It uses only the standard library and makes no network calls. The thresholds are illustrative business rules, not estimates of when a quantum computer will arrive.

The SFTP service and device updater are reviewed first for different reasons. The former carries long-lived secrets; the latter may have a long hardware and firmware replacement cycle. A production inventory should also record algorithm, library version, protocol endpoint, supplier, upgrade path, and last observed configuration.

Core Concepts

Key establishment is different from encryption

A key-encapsulation mechanism establishes a shared secret that another algorithm can use to protect data. ML-KEM is standardized in FIPS 203, originally published August 13, 2024. Its parameter sets are ML-KEM-512, ML-KEM-768, and ML-KEM-1024. It is not a drop-in file-encryption command. NIST FIPS 203

Signatures solve a different problem

Signatures authenticate an artifact or message and detect modification. The 2024 standards include the lattice-based ML-DSA in FIPS 204 and hash-based SLH-DSA in FIPS 205. Choosing a signature scheme does not replace the key-establishment mechanism in a connection. NIST FIPS 204, NIST FIPS 205

Captured traffic can remain valuable

An adversary can retain encrypted traffic for later decryption if a future capability breaks its key agreement. This makes the required confidentiality lifetime relevant today. OpenSSH's PQC guidance explains this threat and its use of hybrid key agreement, combining classical and post-quantum components. OpenSSH PQC guidance

Crypto agility is an operational capability

Crypto agility means being able to change cryptographic mechanisms while maintaining security and service operation. NIST's final CSWP 39 appeared December 19, 2025, with an updated version dated June 29, 2026. It addresses the operational trade-offs of making such changes. NIST crypto-agility guidance

For a service team, a useful test is concrete: can you identify affected endpoints, update the implementation, measure the result, and recover without relying on the person who originally configured it?

What Changed During the Past Year

The OpenSSH milestones come from its versioned release notes; the NIST dates come from the CSWP 39 update record. Experimental support is not an instruction to enable it fleet-wide.

Earlier background matters: OpenSSH already offered PQC key agreement before this window, and ML-KEM/X25519 became its preferred scheme in April 2025. The October warning did not introduce PQC from scratch. OpenSSH PQC history

Build an Evidence-Based Migration Plan

Inventory the actual path

For a partner file transfer, record the client, jump host, server, software distribution, configuration owner, and partner contact. A current laptop alone does not prove the remote server can negotiate the required mechanism.

Include outbound connections and rarely used paths. Disaster-recovery transfers and quarterly exports are easy to miss if the inventory only comes from normal daily traffic. Ask each service owner for both the main path and its recovery path.

Inspect capabilities without changing configuration

With OpenSSH installed, these commands print the local version and supported key-exchange algorithms:

They do not establish a connection or prove what a server will negotiate. OpenSSH documents -Q as a local capability query. OpenSSH client manual

For an approved staging connection, capture the negotiated algorithm separately. Store only the diagnostic fields you need: verbose logs can contain hostnames, account names, and local paths. Compare the observed result with the expected policy, rather than treating the absence of an error as evidence of completion.

Define acceptance before rollout

Create a small compatibility matrix covering managed desktops, automation runners, older appliances, and partner endpoints. For each combination, record connection success, selected mechanism, handshake latency, error handling, and recovery behavior.

Set measurable acceptance criteria. For example: every supported automation runner completes the staging transfer; no required partner path silently falls back; the recovery procedure restores service within its target time. The numbers should come from the service's requirements and baseline measurements.

Best Practices

Give each dependency an owner

An inventory item without an owner rarely becomes an upgrade. Assign a person or team to obtain the vendor's supported version, test configuration, and deployment constraints. Keep “supplier says supported” separate from “verified in our environment.”

Separate compatibility from security exceptions

If a legacy endpoint requires fallback, document the endpoint, rationale, expiry, and responsible team. Scope any exception narrowly. A general compatibility switch is difficult to retire because it hides which consumers still need it.

Rehearse recovery alongside deployment

Preserve previous configurations and test access through an approved recovery channel before making changes. A rollback that restores availability but reintroduces an unacceptable security exposure needs an explicit response plan and owner.

Track maintenance of the standard and implementation

Record the algorithm specification and the implementation supplying it. NIST's FIPS 203 page includes a November 17, 2025 planning note about potential corrections; its FIPS 204 page carries a July 31, 2026 errata note. Check those records when choosing or updating a library. FIPS 203 record, FIPS 204 record

Comparison

Use these as separate project tracks with shared ownership records. Completing one does not establish that the others are finished.

Common Mistakes

Counting installation as migration

Bad: Mark an endpoint complete because a new client is installed.

Correct: Verify the real connection path, negotiated algorithm, and partner compatibility, then record the evidence.

Confusing key exchange with signatures

Bad: Assume a hybrid SSH key exchange makes all host keys, user keys, and signed firmware post-quantum ready.

Correct: Maintain separate inventory fields and acceptance tests for key establishment and authentication.

Hiding warnings globally

Bad: Remove all cryptographic warnings to make automation output quieter.

Correct: Investigate affected endpoints; track any required exception and its removal date.

FAQ

Should I wait for a quantum-computer arrival date?

Use data lifetime, exposure, and replacement lead time to prioritize work. A precise forecast is not required to inventory dependencies or run a compatibility pilot.

Does ML-KEM replace AES?

No. ML-KEM establishes a shared secret; symmetric algorithms use key material to protect data. Review the full protocol and key-management design rather than substituting algorithm names in application code. FIPS 203

Can I turn on experimental signatures in production?

Treat them as a separate evaluation requiring implementation support, interoperability evidence, and a recovery plan. OpenSSH 10.4 explicitly labels its composite signature support experimental and leaves it disabled by default. OpenSSH release notes

What should a small team do first?

Choose one important flow, name its owner, and document both endpoints and their upgrade paths. A verified pilot and reusable inventory format are more useful than an untested organization-wide completion claim.

Related Topics

References