Standards guide

NIST FIPS 203, 204 and 205: What the Post-Quantum Standards Mean

The first three NIST post-quantum cryptography standards define the practical starting point for migration: ML-KEM for key establishment, ML-DSA for digital signatures and SLH-DSA as a conservative hash-based signature option.

Updated: 18 June 2026|12 min read
FIPS 203

ML-KEM

Key establishment

TLS, VPNs, API transport, key wrapping and secure session establishment.

Usually the first standard to evaluate for public endpoints and network encryption.

FIPS 204

ML-DSA

Digital signatures

Software signing, document signing, device identity, API token signing and certificate workflows.

Useful where RSA or ECDSA signatures must remain trustworthy for many years.

FIPS 205

SLH-DSA

Hash-based signatures

Conservative signature option for high-assurance or low-frequency signing workflows.

Best treated as a specialised option because signatures are larger and slower.

Why These Standards Matter

For years, post-quantum cryptography planning was blocked by uncertainty. NIST has now standardised the first algorithms, giving security teams a stable base for procurement, architecture and pilot implementations.

This does not mean every system should be switched overnight. It means organisations can stop treating PQC as a future research topic and start building a cryptographic inventory, choosing pilot systems and testing hybrid deployments.

The practical question is no longer "which algorithms might win?" It is "where do ML-KEM, ML-DSA and SLH-DSA belong in our systems, and what has to change around certificates, key management, protocols and vendors?"

FIPS 203: ML-KEM for Key Establishment

ML-KEM is the main standard for establishing shared secrets in a quantum-resistant way. In web infrastructure, it is most relevant to TLS, VPNs, API gateways and other encrypted transport channels.

Most early deployments should use hybrid cryptography: classical key exchange remains in place while ML-KEM is added. That preserves compatibility while reducing exposure to future quantum decryption.

For public websites, the visible starting point is simple: confirm TLS 1.3 support, remove legacy downgrade paths where possible, then test whether the hosting or CDN provider can negotiate hybrid key exchange.

FIPS 204 and 205: Post-Quantum Signatures

ML-DSA is the primary NIST digital signature standard for many future workflows. It is relevant to code signing, firmware signing, document signing, identity systems and authentication flows where RSA or ECDSA are currently used.

SLH-DSA is also a digital signature standard, but it uses a different hash-based construction. It is attractive for conservative, high-assurance cases but has larger signatures and different performance trade-offs.

Signature migration is often harder than transport migration because signatures can live for a long time. Archives, contracts, software releases and device firmware can all depend on signatures that must remain verifiable years later.

Implementation Order for Most Teams

  1. 1. Inventory cryptography. List TLS endpoints, VPNs, certificates, signing systems, key stores, embedded devices and third-party dependencies.
  2. 2. Rank data by lifetime. Prioritise systems carrying data that must remain confidential or authentic for many years.
  3. 3. Start with transport pilots. Use ML-KEM hybrid key exchange where the provider stack already supports it.
  4. 4. Plan signature migration carefully. Test ML-DSA and SLH-DSA around certificate chains, code-signing workflows and verifier compatibility.
  5. 5. Document crypto-agility. Build systems so algorithms can be upgraded again without redesigning the application.

Primary References

Check Your Public TLS Readiness

Before a full migration, confirm whether your public endpoint is ready for modern TLS and post-quantum key exchange.

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.