Post-Quantum Cryptography: The Migration Has Started, Whether You Have or Not

In August 2024, NIST published three final post-quantum cryptographic standards: FIPS 203 (ML-KEM, the key encapsulation mechanism), FIPS 204 (ML-DSA, the digital signature algorithm), and FIPS 205 (SLH-DSA, a hash-based signature scheme). These are not drafts. They are final standards. The era of "we are working on quantum-resistant algorithms" ended in August 2024. The era of "we need to migrate to them" started at the same time.

Most organisations have not started. The gap between where the standards are and where most cryptographic infrastructure sits is significant, and the timeline for closing it is shorter than the complexity suggests.

Why the Urgency Is Real Now, Not Someday

The standard argument for urgency in post-quantum cryptography is that sufficiently powerful quantum computers do not yet exist at the scale needed to break RSA-2048 or ECDSA. That is true. It is also the wrong frame for risk management.

Harvest-now-decrypt-later is the threat that makes this a current issue. Nation-state actors with long-term intelligence interests are collecting encrypted data today with the explicit intention of decrypting it when quantum capability matures. Communications, authentication tokens, financial transactions, health records: any data collected now and encrypted with current algorithms is potentially vulnerable to future decryption. For data that needs to remain confidential for five, ten, or fifteen years, the risk clock started years ago.

Intelligence community assessments from GCHQ, NSA, and CISA have all made this explicit. The NCSC UK guidance on post-quantum cryptography, updated 2024, states that organisations should treat migration to post-quantum cryptographic algorithms as a medium-term priority with near-term planning actions required now. The US NSA has directed that systems using RSA and ECDH begin transition planning immediately, with a target completion date of 2035 for national security systems. That timeline is not relaxed. It is the outer boundary for mission-critical systems, not the start date.

What NIST FIPS 203, 204, and 205 Actually Establish

The three final standards cover different cryptographic functions:

FIPS 203 (ML-KEM, based on CRYSTALS-Kyber) is the primary standard for key encapsulation: the mechanism used to securely establish shared secret keys. This is what replaces RSA and ECDH in key exchange protocols. TLS, VPNs, and secure communications infrastructure that currently relies on RSA or Diffie-Hellman key exchange needs to migrate to ML-KEM.

FIPS 204 (ML-DSA, based on CRYSTALS-Dilithium) is the primary standard for digital signatures. This is what replaces ECDSA and RSA signatures in code signing, certificate authorities, authentication tokens, and document signing workflows. Certificate infrastructure that relies on ECDSA needs to migrate to ML-DSA.

FIPS 205 (SLH-DSA, based on SPHINCS+) is a hash-based signature standard intended as a conservative alternative. It relies on different mathematical assumptions than ML-DSA, making it a useful backup if vulnerabilities are found in lattice-based schemes. Most organisations will deploy ML-DSA as primary and consider SLH-DSA for high-assurance contexts.

NIST has indicated that FIPS 206 (FN-DSA, based on FALCON) is forthcoming, targeted primarily at applications requiring smaller signature sizes. Organisations should design their migration architecture to accommodate additional standards as they are finalised, rather than treating the August 2024 release as the complete final set.

What the Migration Actually Requires

The challenge in post-quantum migration is not adopting a new algorithm. It is identifying every place where vulnerable algorithms are used and replacing them in a coordinated way without breaking dependencies.

Cryptographic inventory is the starting point. Most organisations do not have a complete picture of where RSA, ECDSA, ECDH, and Diffie-Hellman are in use: TLS configurations, VPN endpoints, certificate authorities, code signing pipelines, SSH configurations, hardware security modules, API authentication, and embedded systems. Building that inventory is the prerequisite for everything else. Without it, migration planning is guesswork.

Crypto agility is the architectural principle the migration depends on. Systems that were designed with algorithm flexibility built in can swap cryptographic primitives with moderate effort. Systems that have algorithms hardcoded (a substantial proportion of legacy financial infrastructure, embedded systems, and older enterprise platforms) require more significant remediation. The migration assessment needs to distinguish between systems where algorithm substitution is an operational task and systems where it is an engineering project.

Hybrid deployments are the practical near-term approach for most organisations. Hybrid TLS configurations that use both classical and post-quantum algorithms in parallel provide protection against both classical adversaries today and quantum adversaries in the future, while maintaining compatibility with systems that have not yet migrated. Major browser vendors and cloud providers have already begun deploying hybrid post-quantum TLS. Google reported in 2024 that a significant proportion of Chrome connections to Google services were using hybrid key exchange. The infrastructure is moving. The question is whether your organisation's systems are compatible.

Regulatory and Audit Implications

DORA's ICT risk management requirements (Article 9) explicitly cover cryptographic controls as part of ICT security. The EBA's guidelines on ICT and security risk management require that institutions maintain up-to-date cryptographic key management and assess cryptographic risk as part of ICT risk assessments. Post-quantum migration is increasingly part of supervisory conversations in financial services, particularly for institutions with long data retention obligations.

The FCA and PRA have not yet published formal post-quantum cryptography guidance for UK financial services, but the NCSC's guidance applies and the direction of travel is clear. FFIEC guidance for US financial institutions is evolving in the same direction. Institutions that have not started cryptographic inventory work are behind the supervisory curve.

For IT audit functions, post-quantum cryptography is moving from "emerging risk" to "audit scope item." The audit questions are: does the institution have a cryptographic inventory? Does it have a post-quantum migration plan? Is that plan prioritised against the data retention profile and the criticality of the systems involved? Are hybrid deployment approaches in use for high-risk systems? These are assessable, evidenced questions.

Where to Start

The organisations making progress on post-quantum migration are not trying to solve everything simultaneously. They are sequencing the work against risk: highest sensitivity data with longest retention requirements first, most exposed systems second, internal infrastructure third.

The immediate actions are three: build the cryptographic inventory, assess crypto agility across critical systems, and identify which systems are candidates for early hybrid deployment. None of these require waiting for quantum computers to be a credible near-term threat. They require treating a published, final NIST standard as the signal it is: the migration has been defined, the clock is running, and the organisations that start now will have the advantage of managing the transition rather than reacting to it.