Post-quantum cryptography: a practical readiness guide

Know which cryptography quantum computers threaten

A sufficiently capable cryptographically relevant quantum computer could break widely used public-key systems based on factoring and discrete logarithms. That affects technologies such as RSA and elliptic-curve cryptography used for key establishment and digital signatures. It does not mean every encryption algorithm suddenly fails: well-sized symmetric encryption and hash functions have different quantum-security considerations and can often be strengthened with larger parameters.

No one can give a dependable date for such a machine. Migration still matters now because large systems take years to inventory, upgrade and test. Data captured today may also remain valuable for years. An adversary can store encrypted traffic and attempt to decrypt it later if the key exchange becomes breakable, a risk often described as harvest now, decrypt later.

Prioritize information by required confidentiality lifetime, exposure and business impact. Health, identity, government, intellectual-property and infrastructure records may need protection well beyond the lifetime of current certificates or equipment. A short-lived public status message has a different risk. This classification keeps the programme tied to real assets rather than treating every algorithm mention as an emergency.

Recognize the NIST post-quantum standards

NIST finalized its first three principal post-quantum cryptography standards in 2024. FIPS 203 specifies ML-KEM for establishing a shared secret used by encryption systems. FIPS 204 specifies ML-DSA for digital signatures, and FIPS 205 specifies the hash-based SLH-DSA signature scheme. These are standards to consume through maintained products and cryptographic libraries, not instructions to reimplement the mathematics inside an application.

Different functions need different migrations. Replacing a TLS key-establishment mechanism is not the same as replacing code-signing, document-signing, firmware-verification or certificate-authority signatures. Keys and signatures can also be larger than their classical counterparts, affecting packets, storage, hardware and performance. Test the complete protocol and operational workflow rather than benchmarking a primitive alone.

Standards and product support will continue to evolve. NIST selected HQC as an additional key-encapsulation algorithm in 2025 and continues other standardization work. Follow the current NIST project pages and your platform vendors for implementation status, approved parameters and transition guidance. Avoid adopting an algorithm solely because a package labels it quantum safe.

Build a cryptographic inventory and dependency map

Start by locating cryptography across internet endpoints, APIs, VPNs, databases, backups, email, identity systems, mobile apps, device firmware, signing pipelines, payment links and third-party integrations. Record the protocol, library, algorithm, key size, certificate authority, owner, data protected and planned replacement date. Automated discovery helps, but configuration repositories, procurement records and interviews reveal offline and embedded uses scanners miss.

Map dependencies around each use. A server may support a new algorithm while a load balancer, monitoring appliance, client SDK or hardware security module does not. A signed firmware format may be constrained by bootloader memory. Archived signatures may need to remain verifiable after the signing system changes. Identify who controls each layer and which vendor release or contract is required.

Use the inventory to expose hard-coded assumptions. Applications that accept only one certificate algorithm, fixed key lengths or fixed signature sizes are expensive to migrate. Crypto agility means algorithms and parameters can be replaced through supported, tested configuration while preserving secure defaults and auditability. It does not mean letting an untrusted peer select any algorithm it wants.

Run a staged and measurable migration

Assign an owner, classify the inventory and obtain roadmaps from cloud, identity, network, payment and software suppliers. Upgrade obsolete protocols and unsupported libraries first because a maintained platform is more likely to receive safe post-quantum support. Create a test environment that resembles production and measure compatibility, handshake size, latency, CPU, memory, certificate handling and failure behaviour.

Some ecosystems introduce hybrid mechanisms that combine classical and post-quantum components during transition. Use only combinations defined and supported by the protocol and vendors you rely on. A home-made hybrid can fail in composition even when both algorithms are individually strong. Keep rollback procedures, but prevent silent downgrade to an unapproved weak configuration.

Migrate according to risk and official timelines, then monitor what is actually negotiated in production. Update asset records, incident procedures, certificate automation, backup recovery and supplier requirements. NIST's transition planning calls for quantum-vulnerable algorithms to be deprecated and ultimately removed on a staged timeline toward 2035, with higher-risk systems moving sooner. Treat that as a programme deadline requiring steady work rather than a reason to wait until the final year.

Quick checklist

• Classify data by confidentiality lifetime and business impact.
• Inventory key establishment, signatures, certificates, libraries and devices.
• Map vendor and protocol dependencies for every critical cryptographic use.
• Use standardized algorithms through maintained implementations.
• Test performance, compatibility, failure and downgrade behaviour end to end.
• Track migration ownership, milestones and production negotiation evidence.

Primary references

Standards and platform support change. Use these authoritative sources to check the current specification and migration guidance.

• NIST — Post-Quantum Cryptography project
• NIST — FIPS 203, 204 and 205 approval
• NIST — Migration to Post-Quantum Cryptography