NIST Post-Quantum Compliance: What Engineers Need Now

Engineers do not read compliance documents. They search for "what do I actually need to do." This post answers that question for the NIST post-quantum cryptography standards that are now final, shipping in production software, and generating key material that is already arriving in your infrastructure whether you planned for it or not.

Here is the situation as of April 2026: FIPS 203 (ML-KEM, the key encapsulation mechanism formerly known as Kyber), FIPS 204 (ML-DSA, the digital signature algorithm formerly known as Dilithium), and FIPS 205 (SLH-DSA, the stateless hash-based signature algorithm formerly known as SPHINCS+) are all final published standards. They are not drafts. They are not proposals. They are mandatory for US federal systems and rapidly becoming the baseline expectation for any system handling sensitive data.

More importantly, the implementations are shipping now. Chrome has been negotiating ML-KEM key exchanges on every HTTPS connection since version 124. OpenSSL 3.5 includes ML-KEM and ML-DSA support. Go 1.24 ships with ML-KEM in the standard library. Rustls supports post-quantum key exchange. Your dependencies have already adopted post-quantum cryptography. The question is whether the rest of your infrastructure can handle it.

What Changed: The Standards Are Final

NIST published three post-quantum cryptography standards in 2024. Each replaces a classical cryptographic primitive that is vulnerable to quantum attack.

FIPS 203: ML-KEM (Module-Lattice-Based Key Encapsulation Mechanism). This replaces classical key exchange (ECDH, DH). It is used during TLS handshakes to establish shared secrets. ML-KEM is what Chrome, Firefox, and every major browser now negotiate during HTTPS connections. When your users connect to your service, the TLS handshake already uses ML-KEM if both sides support it. The key material produced by ML-KEM is larger than classical ECDH key material.

FIPS 204: ML-DSA (Module-Lattice-Based Digital Signature Algorithm). This replaces classical signatures (RSA, ECDSA) for general-purpose digital signatures. It is used for code signing, document signing, certificate chains, and any application that requires digital signatures. ML-DSA signatures are significantly larger than ECDSA signatures.

FIPS 205: SLH-DSA (Stateless Hash-Based Digital Signature Algorithm). This provides an alternative to ML-DSA based on different mathematical assumptions. While ML-DSA is based on lattice problems, SLH-DSA is based on hash function security. It serves as a hedge: if lattice-based schemes are broken, SLH-DSA remains secure. The tradeoff is that SLH-DSA signatures are even larger than ML-DSA signatures.

These three standards cover the two fundamental cryptographic operations: key exchange and digital signatures. Every system that uses cryptography -- which is every system that communicates over a network -- is affected by the transition from classical to post-quantum algorithms.

What Is Shipping Now

The post-quantum transition is not a future event. It is happening now, in production, in software that your systems depend on. Here is what has shipped as of April 2026.

Chrome (version 124+): Negotiates ML-KEM-768 (the FIPS 203 Level 3 parameter set) in TLS 1.3 key exchange by default. Every Chrome user connecting to your service is already performing post-quantum key exchange. The shared secret derivation uses a hybrid approach (X25519 + ML-KEM-768), so backward compatibility is maintained, but the key material transmitted during the handshake is larger.

OpenSSL 3.5: Includes ML-KEM and ML-DSA implementations. Any application linked against OpenSSL 3.5 can negotiate post-quantum connections. Server-side adoption is accelerating as Linux distributions ship OpenSSL 3.5 as the default.

Go 1.24: Ships crypto/mlkem in the standard library. Go applications can now perform ML-KEM key encapsulation without third-party dependencies. The Go TLS stack supports post-quantum key exchange when configured.

Rustls: The Rust TLS library supports post-quantum key exchange via the rustls-post-quantum crate. Any Rust service using Rustls can negotiate ML-KEM connections.

AWS: AWS KMS supports post-quantum TLS. AWS Certificate Manager is preparing to issue certificates with post-quantum signatures. AWS S3, Lambda, and API Gateway accept post-quantum TLS connections from clients that support them.

The point is not that you need to rush to adopt these standards yourself. The point is that your dependencies already have. Chrome is sending ML-KEM key shares to your server on every connection. Your server's TLS library is processing them. The key material is flowing through your infrastructure. The question is whether your infrastructure was sized for it.

What Breaks in Your Infrastructure

Post-quantum key material and signatures are dramatically larger than their classical counterparts. This is the core engineering challenge of the PQ transition. The cryptography itself works. The problem is that everything downstream of the cryptography -- your session stores, your caches, your JWT tokens, your TLS session tickets, your certificate chains -- was sized for classical key material.

The Size Table

Here are the exact sizes for the three FIPS standards, compared to the classical algorithms they replace. These numbers are not approximations. They are the byte counts defined in the standards.

The numbers speak for themselves. An ML-KEM-768 public key is 1,184 bytes versus 32 bytes for X25519. That is a 37x increase. An ML-DSA-65 signature is 3,309 bytes versus 64 bytes for ECDSA. That is a 52x increase. An SLH-DSA-SHA2-128f signature is 17,088 bytes versus 64 bytes. That is a 267x increase.

Where the Sizes Hit Your Infrastructure

These size increases propagate through your infrastructure in four places that most teams do not anticipate until they break.

Session stores grow 47x. A TLS session ticket with classical cryptography is approximately 200 bytes. With ML-KEM key material and an ML-DSA signature, the session ticket grows to approximately 9,400 bytes. If your session cache holds 1 million sessions at 200 bytes each (200 MB), it now needs to hold 1 million sessions at 9,400 bytes each (9.4 GB). Your session cache either needs 47x more memory or it caches 47x fewer sessions, which means 47x more TLS full handshakes, which means higher latency and higher CPU cost.

JWT tokens grow 52x. A JWT signed with ECDSA-P256 has a 64-byte signature. A JWT signed with ML-DSA-65 has a 3,309-byte signature. The entire JWT payload -- which gets transmitted on every API request as a Bearer token -- grows from approximately 300 bytes to approximately 3,600 bytes. If your API processes 100,000 requests per second, the additional bandwidth from larger JWTs is approximately 330 MB/sec. That is not trivial, and it scales linearly with request rate.

TLS session tickets grow 34x. TLS session resumption relies on session tickets that the client presents to skip the full handshake. These tickets are stored by the client and transmitted to the server. With post-quantum key material, the tickets are larger, which increases the size of the ClientHello message. Some middleboxes, load balancers, and WAFs have maximum ClientHello size limits that were set for classical-sized messages. Post-quantum ClientHello messages may exceed these limits, causing connection failures that are difficult to diagnose.

Certificate chains grow 10-20x. A certificate chain with three certificates (leaf, intermediate, root), each signed with ML-DSA-65, contains approximately 10 KB of signature data alone. Add the public keys, and the chain exceeds 15 KB. A classical ECDSA chain is approximately 1.5 KB. This larger chain is transmitted during every TLS full handshake. For services that handle many new connections (CDNs, APIs, microservices), the bandwidth increase is measurable.

The CNSA 2.0 Timeline

The NSA's Commercial National Security Algorithm Suite 2.0 (CNSA 2.0) provides the timeline that federal agencies and their contractors must follow. If you sell to the US government or handle government data, these are hard deadlines. If you do not, they are still the best available guide to when the industry will expect post-quantum compliance.

The first two milestones have already passed. Software signing and web browsers are expected to use CNSA 2.0 algorithms now. Networking equipment is due this year. The 2030 deadline for custom applications is four years away, which sounds comfortable until you consider that most enterprise migration projects take 2-3 years from decision to completion. If you have not started planning, you are already behind the timeline that allows for a measured transition.

The 6-Step Migration Playbook

The following playbook covers the essential steps for migrating your infrastructure to handle post-quantum cryptographic material. This is not a complete guide to post-quantum cryptography. It is the operational checklist for ensuring that your infrastructure does not break as post-quantum key material arrives.

Step 1: Audit Your Cryptographic Inventory

Before you can migrate, you need to know what you are migrating from. Identify every place in your infrastructure where cryptographic operations occur. This includes TLS termination points, JWT signing and verification, session management, certificate storage, key management systems, and any application-level encryption or signing.

For each cryptographic usage point, record the algorithm, the key sizes, the frequency of operations, and the storage requirements. This audit produces a map of your cryptographic surface area. Most teams discover 3-5x more cryptographic usage points than they expected, because cryptography is embedded in libraries and frameworks that the application team does not directly manage.

Automated tools can accelerate this audit. Many cloud providers offer cryptographic inventory services. Open-source tools like detect-secrets and cfssl can identify certificate and key usage. The goal is a complete list, not a perfect one. You will discover additional usage points during migration.

Step 2: Size Your Cache Layer for PQ Objects

This is the step most teams skip, and it is the step that causes production incidents. Take your cryptographic inventory from Step 1 and calculate the storage requirements for post-quantum equivalents of every cached cryptographic object.

Session tokens: multiply your current session cache memory by 47x (or provision for the new per-session size). JWT tokens: calculate the bandwidth increase from 52x larger signatures on every API request. TLS tickets: verify that your load balancers and middleboxes can handle larger ClientHello messages. Certificate chains: ensure your certificate cache can store 10-20x larger chains without evicting aggressively.

If your session cache currently uses 500 MB for 2.5 million sessions at 200 bytes each, the same number of sessions with PQ material requires 23.5 GB. You have three options: add 23 GB of cache memory, reduce the number of cached sessions by 47x (accepting more full handshakes), or implement a tiered caching strategy that keeps PQ session material in an in-process L1 cache with a fast eviction policy. The third option is what Cachee provides: an L1 tier that handles the larger object sizes with CacheeLFU admission to maximize the hit rate within a fixed memory budget.

Step 3: Update TLS Configuration

Your TLS termination points need to support post-quantum key exchange. If you use Nginx, Apache, HAProxy, or a cloud load balancer, check whether the underlying TLS library (OpenSSL, BoringSSL, Rustls) supports ML-KEM. Most modern versions do. The configuration change is typically a single line that adds the post-quantum key exchange group to the supported groups list.

# Nginx example (OpenSSL 3.5+)
ssl_ecdh_curve X25519MLKEM768:X25519:prime256v1;

# This enables hybrid PQ key exchange (X25519 + ML-KEM-768)
# Backward compatible: classical clients still connect via X25519

The hybrid approach (classical + PQ) is the recommended migration path. It maintains backward compatibility with clients that do not support PQ while providing PQ protection for clients that do. There is no reason to delay this step. The performance impact is minimal (ML-KEM key generation and encapsulation are fast), and the backward compatibility means zero risk of breaking existing clients.

Step 4: Migrate Signature Infrastructure

Signature migration is more complex than key exchange migration because signatures are stored, transmitted, and verified across many systems. JWTs, API tokens, code signatures, document signatures, and certificate chains all contain signatures that will transition from classical to post-quantum algorithms.

The recommended approach is to adopt a dual-signature strategy during the transition period. Issue signatures with both a classical algorithm (ECDSA) and a post-quantum algorithm (ML-DSA). Verifiers that support PQ check the PQ signature. Verifiers that do not support PQ check the classical signature. This maintains interoperability while gradually moving the ecosystem to PQ-only verification.

For JWTs specifically, the JOSE working group has defined new algorithm identifiers for ML-DSA. Your JWT library needs to support these identifiers. If it does not yet, you can sign JWTs with ML-DSA and include the signature as a custom claim while maintaining the classical signature in the standard JOSE header. This is a transitional pattern that works with existing JWT infrastructure while adding PQ protection.

Step 5: Test With Real PQ Traffic

The most common failure mode in PQ migration is not cryptographic failure. It is infrastructure failure: buffers that are too small, message size limits that are too low, timeouts that are too short for larger handshakes, and caches that cannot handle the increased object sizes.

Test your infrastructure with real PQ traffic before you commit to the migration. Use a PQ-enabled client (Chrome, or a custom client using OpenSSL 3.5) to connect to your service and observe the behavior. Measure session cache memory usage. Check for oversized message errors in load balancer logs. Verify that your WAF does not reject the larger ClientHello. Confirm that your monitoring systems correctly parse the PQ-specific TLS metrics.

Run this test in a staging environment first, then in production with a small percentage of traffic. The failure modes are predictable and fixable, but they need to be discovered before 100% of your traffic is PQ.

Step 6: Monitor and Optimize

After enabling PQ support, monitor four metrics continuously.

Cache memory utilization. PQ objects are larger. Your cache memory usage will increase. Track the growth rate and project when you will need to add capacity or optimize eviction policies.

TLS handshake latency. PQ key exchange adds a small amount of latency to the TLS handshake (typically 0.5-2 milliseconds). Monitor P50 and P99 handshake latency to ensure it remains within acceptable bounds. If handshake latency increases more than expected, check whether your server's CPU is bottlenecked on PQ key generation.

Session resumption rate. If your session cache cannot hold as many sessions due to larger PQ session tickets, your session resumption rate will drop. This means more full TLS handshakes, which means higher latency for returning users. Monitor the resumption rate and adjust cache sizing if it drops below your target (typically 80-90%).

Bandwidth consumption. Larger JWTs, larger certificates, and larger TLS messages all increase bandwidth. Monitor your network transfer costs, especially cross-AZ and cross-region transfer, and attribute the increase to PQ migration so it does not surprise the finance team.

Do I Need to Do This Now?

Yes, but probably not for the reason you think.

The quantum threat itself -- a cryptographically relevant quantum computer that can break RSA and ECC -- is likely 10 to 20 years away. If that were the only consideration, you could wait. But there are three reasons why the migration timeline is now, not later.

Reason 1: Harvest now, decrypt later. Adversaries are collecting encrypted traffic today with the intention of decrypting it when quantum computers become available. If your data has a secrecy requirement that extends beyond the expected arrival of quantum computers (medical records, financial data, government classified information, trade secrets), you need PQ protection now. The data being harvested today cannot be retroactively protected.

Reason 2: Your dependencies already did it. Chrome is negotiating ML-KEM on every connection. Go 1.24 ships ML-KEM in the standard library. OpenSSL 3.5 supports PQ algorithms. Your infrastructure is already receiving PQ key material. The question is not whether to adopt PQ cryptography. The question is whether your infrastructure handles the PQ key material that is already arriving. If your session cache cannot store the larger session tickets, you have a performance problem now, not in 10 years.

Reason 3: Compliance timelines are binding. If you sell to the US federal government, CNSA 2.0 requires PQ for software signing and web services now. Networking equipment must support PQ by the end of 2026. Custom applications must be migrated by 2030. These are procurement requirements. If your product does not meet them, you lose contracts. Similar requirements are emerging in the EU (ETSI), UK (NCSC), and other jurisdictions.

How Cachee Handles the PQ Size Problem

The fundamental infrastructure challenge of post-quantum compliance is size. Keys are larger. Signatures are larger. Sessions are larger. Tokens are larger. Everything that gets cached, stored, or transmitted is larger. The infrastructure that worked at classical sizes does not work at PQ sizes without modification.

Cachee addresses this in three ways.

Memory-efficient storage with CacheeLFU admission. The CacheeLFU admission policy ensures that cache memory is allocated to the entries that produce the most hits. When PQ objects are 47x larger, the same cache memory budget holds 47x fewer entries. CacheeLFU ensures that those entries are the ones that matter most: the hottest sessions, the most frequently accessed tokens, the most commonly verified certificates. A 2 GB cache with CacheeLFU and PQ-sized sessions provides a higher effective hit rate than a naive 4 GB cache, because every admission decision is optimized for frequency.

In-process L1 with zero serialization. PQ objects are large. Serializing a 9,400-byte session ticket to send it to Redis costs 3-8 microseconds per operation. At 50,000 operations per second, that is 150-400 milliseconds of CPU per second burned on serialization alone. Cachee's in-process L1 cache stores PQ objects as native memory structures with zero serialization. The lookup cost is 31 nanoseconds regardless of object size. The larger your cached objects, the more you save by avoiding serialization to an external cache.

Post-quantum attestation of cached values. Cachee attests cached values using post-quantum signatures. Every cached entry can be verified as authentic using ML-DSA or SLH-DSA signatures, ensuring that cache integrity is maintained even in a post-quantum threat model. This is not just PQ-compatible caching. It is PQ-secured caching. The cache itself is protected by the same post-quantum cryptography that protects your transport layer.

The transition to post-quantum cryptography is not optional. It is happening now, driven by browser vendors and library maintainers who have already shipped PQ support. The infrastructure question is not whether to support PQ but whether your cache layer can handle the 47x increase in session sizes, the 52x increase in JWT signatures, and the 34x increase in TLS tickets. If it cannot, your session hit rate drops, your handshake latency increases, and your bandwidth costs rise. The migration playbook is six steps, starting with an audit of your cryptographic surface area and a sizing calculation for your cache layer. Both are zero-risk actions you can take today.