Standards explainer

ML-KEM vs Kyber: What Changed in the NIST Standard?

Kyber was the name used during the NIST post-quantum competition. ML-KEM is the final NIST-standardised key encapsulation mechanism derived from Kyber and published as FIPS 203. For real migration planning, ML-KEM is the name that matters.

Kyber

The competition submission name most engineers saw before final standardisation.

ML-KEM

The NIST standard name for the key encapsulation mechanism in FIPS 203.

Migration impact

Use final standard terminology in procurement, architecture, compliance and implementation documents.

Why the Naming Matters

Teams still search for Kyber because that name appeared in research, prototypes and early vendor material. Procurement and compliance documents, however, should now reference FIPS 203 ML-KEM so the implementation target is clear.

The practical risk is ambiguity. A roadmap that says "enable Kyber" may not specify the final parameter set, approved implementation, library version, validation path or protocol integration. A roadmap that says "FIPS 203 ML-KEM" is easier to audit.

Where ML-KEM Fits

ML-KEM is for key establishment: creating shared secrets that can protect a session or wrap another key. It is relevant to TLS, VPNs, APIs, service-to-service encryption and other network protocols.

It is not a digital signature algorithm. Signature migration is handled by standards such as ML-DSA and SLH-DSA, which need a separate workstream for code signing, certificates, documents and identity.

ML-KEM Implementation: Choose the Right Integration

Start by identifying where key establishment happens. A website using a CDN needs changes at its TLS terminator; an application building an encrypted protocol needs a maintained cryptographic library and a reviewed protocol design.

  1. Pin the implementation target. Record the library or appliance version and final FIPS 203 parameter set: ML-KEM-512, ML-KEM-768 or ML-KEM-1024. Choose according to the protocol and security requirements. A vendor label saying only "Kyber" is insufficient.
  2. For web traffic, use the TLS integration. Confirm support at both client and server for the intended hybrid group. Read how X25519MLKEM768 combines classical and ML-KEM key exchange. Check the browser-to-CDN and CDN-to-origin connections separately.
  3. For library integration, understand the KEM boundary. Key generation, encapsulation and decapsulation establish a shared secret; they do not encrypt an application message directly. OpenSSL added ML-KEM support in version 3.5. Its documented encapsulation randomness override is for testing only and must not be used in production.
  4. Test the actual connection. In staging, record the negotiated group, peer versions, handshake failures and latency. Test older clients and document any classical fallback. A successful connection alone does not show that ML-KEM was negotiated.

Use the PQC implementation and pilot verification checklist to retain evidence before rollout, then check your public TLS endpoint. A public scan covers the exposed endpoint, not private services or every client connection.

Technical references: NIST FIPS 203 and its errata and OpenSSL ML-KEM operations.

ML-KEM Implementation Questions

Is ML-KEM the same as Kyber?

ML-KEM is derived from CRYSTALS-Kyber, but the final FIPS 203 standard is the implementation target. Do not assume a pre-standard Kyber implementation is interchangeable with ML-KEM; check the library version, parameter set and protocol support on both sides.

How do I start an ML-KEM implementation?

Use a maintained cryptographic library or a supported TLS integration. Specify the final FIPS 203 parameter set, confirm support at both peers and test interoperability in staging. For a website behind a CDN, start with the TLS terminator rather than adding raw KEM operations to application code.

Does ML-KEM encrypt application data directly?

No. ML-KEM establishes a shared secret. A protocol derives keys from that secret for symmetric encryption of application data. Authentication and digital signatures must also be addressed by the protocol.

Check Your Public TLS Starting Point

The scanner checks whether your endpoint is ready for modern TLS and whether hybrid post-quantum key exchange is observed.

Free readiness account

Keep This Guide Connected to a Real Website Scan

A PQC guide is more useful when it is attached to current evidence. Create a free account, add a public domain now or later, and keep a repeatable baseline for TLS, security headers and visible post-quantum readiness.

No cardStart the free evidence path without a paid plan.
Saved scanKeep the public endpoint result after the browser session.
Rescan laterRerun after TLS, header or provider changes.

Prefer to scan first? Open the free quantum security scanner.

Create Your Free Account

Start with Google, Microsoft or a one-time email code. You can add a domain now if you want the scanner to run after signup, but it is not required.

No cardNo passwordFree saved scan
Add a domain to scan after signup (optional)

Leave this blank to create the account first and scan later.

or use email code

No card or password is needed. The free account can keep scan evidence for rescans and badge qualification when you add a public domain.