NIST's finalized post-quantum standards and how to plan a migration

What NIST published

On August 13, 2024, the National Institute of Standards and Technology (NIST) published the first three finalized post-quantum cryptographic standards. The algorithms, the product of eight years of analysis, testing and public review, are designed to resist attacks from both classical and quantum computers.

This is the most significant change to cryptographic standards since AES was adopted in 2001. Every organization that uses public-key cryptography will eventually have to migrate.

The three standards

FIPS 203: ML-KEM (key encapsulation)

ML-KEM (Module-Lattice-based Key Encapsulation Mechanism) replaces key exchange protocols such as ECDH and RSA-KEM. Use cases include TLS/HTTPS key exchange, VPN tunnel establishment, secure messaging (Signal, WhatsApp, etc.) and API authentication.

Security levels:

Key sizes:

FIPS 204: ML-DSA (digital signatures)

ML-DSA (Module-Lattice-based Digital Signature Algorithm) replaces RSA and ECDSA for digital signatures. Use cases include code signing, document signing, certificate authorities, and blockchain and cryptocurrencies.

Security levels:

Signature sizes:

FIPS 205: SLH-DSA (hash-based signatures)

SLH-DSA (Stateless Hash-based Digital Signature Algorithm) is an alternative signature scheme based on hash functions instead of lattices. Its security rests on well-understood hash functions, it has no complex mathematical structures, and it is the conservative choice if lattice problems are broken. In exchange, signatures are larger (7-50 KB depending on parameters) and signing and verification are slower, so it fits best where signature size isn't critical.

The "harvest now, decrypt later" threat

Adversaries are already collecting encrypted data to decrypt once quantum computers are available. Data with long-term sensitivity is at risk:

• Government secrets (decades of relevance)
• Medical records (lifetime of the patient)
• Financial data (years of regulatory retention)
• Intellectual property (duration of competitive advantage)

If your encrypted data needs to stay secret for 10+ years, you should already be planning the migration.

Recommended migration timeline

Immediate (now to 2025)

Assessment:

• Inventory all cryptographic usage
• Identify data with long-term confidentiality requirements
• Catalog certificates, key management systems and protocols
• Check vendor roadmaps for post-quantum support

Early adoption:

• Test ML-KEM in non-production environments
• Update cryptographic libraries to versions with PQ support
• Train development teams on post-quantum concepts

Short term (2025 to 2027)

Hybrid deployment:

• Deploy hybrid key exchange (classical + ML-KEM)
• Update TLS configurations to support hybrid cipher suites
• Start preparing certificate authorities for PQ certificates

Standards compliance:

• Follow NIST transition guidelines (SP 800-131A updates)
• Track industry-specific guidance (HIPAA, PCI-DSS, etc.)
• Review migration plans with compliance auditors

Medium term (2027 to 2030)

Full transition:

• Go post-quantum-only for new deployments
• Phase out classical algorithms where possible
• Move all certificates to post-quantum

Verification:

• Audit systems for remaining classical cryptography
• Check interoperability with partners and vendors
• Document compliance for regulatory requirements

Implementation steps

Step 1: cryptographic inventory

Create a complete inventory:

# Example inventory format
systems:
  - name: "Customer Portal"
    protocols:
      - TLS 1.3 (ECDHE key exchange)
    certificates:
      - issuer: "DigiCert"
        expiry: "2025-06-15"
        algorithm: "RSA-2048"
    data_sensitivity: "HIGH"
    pq_migration_priority: 1

  - name: "Internal API Gateway"
    protocols:
      - mTLS (RSA certificates)
    certificates:
      - issuer: "Internal CA"
        expiry: "2024-12-01"
        algorithm: "ECDSA P-256"
    data_sensitivity: "MEDIUM"
    pq_migration_priority: 2

Step 2: library updates

Switch to libraries with post-quantum support:

// OpenCrypt provides drop-in post-quantum support
use opencrypt::kem::{MlKem768, Kem};
use opencrypt::signature::{MlDsa65, Signer, Verifier};

// Key encapsulation
let (public_key, secret_key) = MlKem768::generate_keypair(&mut rng);
let (ciphertext, shared_secret) = public_key.encapsulate(&mut rng);
let decrypted_secret = secret_key.decapsulate(&ciphertext)?;

// Digital signatures
let signing_key = MlDsa65::generate_signing_key(&mut rng);
let signature = signing_key.sign(message);
signing_key.verifying_key().verify(message, &signature)?;

Step 3: protocol configuration

Enable hybrid mode in TLS:

# Nginx with hybrid post-quantum support
ssl_protocols TLSv1.3;
ssl_conf_command Groups X25519MLKEM768:X25519:P-256;
ssl_prefer_server_ciphers off;

Common questions

Is my RSA/ECDSA data already compromised?

Not yet: current quantum computers cannot break these algorithms. But data captured today could be decrypted in the future, so the risk depends on how long it must stay confidential.

Should I wait for more mature implementations?

For production systems handling sensitive data, hybrid mode protects you now without committing fully to post-quantum-only. It is the recommended approach for most organizations starting to migrate.

What about performance?

Post-quantum algorithms are generally slower than classical ones, but the difference is often acceptable:

For most applications the overhead is negligible next to network latency.

What if the post-quantum algorithms are broken?

That is why hybrid mode is recommended during the transition: with classical and post-quantum algorithms combined, security holds even if one of them is compromised. SLH-DSA (hash-based signatures) is also a conservative alternative that rests on different mathematical assumptions.

Resources

• NIST Post-Quantum Cryptography
• FIPS 203 (ML-KEM)
• FIPS 204 (ML-DSA)
• FIPS 205 (SLH-DSA)
• OpenCrypt documentation

OpenCrypt provides production-ready implementations of all three NIST standards.