What FIPS 203 standardises
FIPS 203 is the Module-Lattice-Based Key-Encapsulation Mechanism Standard, published by NIST on 13 August 2024. It standardises ML-KEM, the algorithm submitted to the NIST post-quantum standardisation project under the name Kyber.
A key-encapsulation mechanism is a set of algorithms that lets two parties establish a shared secret over a public channel. NIST's standard states that ML-KEM "is believed to be secure, even against adversaries who possess a quantum computer".
The standard defines three parameter sets. In NIST's own ordering, of increasing security strength and decreasing performance:
| Parameter set | Relative security strength | Relative performance |
|---|---|---|
| ML-KEM-512 | Lowest of the three | Fastest |
| ML-KEM-768 | Middle | Middle |
| ML-KEM-1024 | Highest | Slowest |
The practical significance of the parameter sets for a VPN migration is that both peers must agree on the same one. A gateway that implements only ML-KEM-768 cannot negotiate with a peer configured to require ML-KEM-1024, and this is a real source of failed negotiations during a migration rather than a theoretical concern.
What ML-KEM does not do
ML-KEM establishes a shared secret. That is its entire job.
It does not authenticate the parties. A key-encapsulation mechanism run between two anonymous parties produces a shared secret that neither party can attribute to anyone. In a VPN, authentication comes from somewhere else entirely: a certificate, a preshared key, or an EAP exchange.
This distinction has a specific consequence that is worth stating plainly, because it is the single most commonly confused point in post-quantum VPN work:
- Adding ML-KEM to a tunnel's key establishment protects the session key against an adversary who records the traffic today and decrypts it later, once a cryptographically relevant quantum computer exists.
- It does not protect the authentication of the peer. If your tunnel authenticates with an RSA or ECDSA certificate, it still does after the change, and that certificate remains vulnerable to the same future adversary.
The authentication side of the problem is addressed by a different standard, FIPS 204, which standardises ML-DSA, the module-lattice digital signature algorithm. Deploying it across a VPN estate is a PKI programme, not a VPN configuration change, and it generally lags key establishment by a considerable margin.
Why the authentication gap is usually acceptable — and when it is not
The asymmetry between the two is not an oversight in the standards; it reflects a real difference in the threat.
An adversary who breaks your key establishment in ten years' time can decrypt traffic they recorded today. This is the "harvest now, decrypt later" problem, and it is a present-tense risk for any data whose confidentiality must outlive the arrival of a quantum computer.
An adversary who breaks your authentication in ten years' time can impersonate a peer — in ten years' time. They cannot retroactively impersonate anyone in a session that already completed. Authentication is a live-attack problem, so the deadline for fixing it is the arrival of the capability, not today.
That reasoning holds for most enterprise estates. It stops holding where certificates have very long validity periods, where a device's identity key cannot be rotated in practice, or where a regulator requires post-quantum authentication on a stated timetable regardless of the threat model. Establish which of those applies to your environment before deciding that authentication can wait.
What this means for an estate assessment
Three things follow directly:
-
Record the two properties separately. An inventory that has one "post-quantum ready" column per tunnel is recording an answer to a question nobody asked. Key establishment and authentication need their own columns because they migrate on different timelines through different mechanisms.
-
Parameter set agreement is a migration risk. Where both peers support ML-KEM but are configured for different parameter sets, the tunnel will fail to establish. This belongs in the pre-flight checks, not in the post-change diagnosis.
-
A standard existing is not a product supporting it. FIPS 203 was published in August 2024. Whether a specific gateway on a specific software release can negotiate ML-KEM in an IKEv2 exchange is an entirely separate question, answered per product and per release. That is what the compatibility matrix is for.
Known limitations of this page
This page describes what the standard says. It makes no claim about which products implement it, at which release, or with which parameter sets — those claims require product-level verification and are recorded separately against each compatibility record with their own sources and review dates.