NIST PQC Standards: What Enterprise Teams Need to Do Now

---

On August 13, 2024, NIST published three finalized post-quantum cryptographic standards: FIPS 203 (ML-KEM), FIPS 204 (ML-DSA), and FIPS 205 (SLH-DSA). After eight years of evaluation, four rounds of selection, and extensive cryptanalysis, these algorithms are now federal standards — and the starting gun for enterprise migration has fired.

The instinct is to start evaluating algorithms. That instinct is wrong.

The first step is not algorithm selection. It’s cryptographic inventory. You cannot migrate what you cannot find. And most enterprises cannot find 40-60% of their cryptographic dependencies.

This post covers what these standards actually specify, what timelines are mandated by NSA and OMB, and the concrete steps enterprise teams must take — starting this quarter.

---

The Three Standards: What Was Actually Published

FIPS 203: ML-KEM (Module-Lattice-Based Key Encapsulation Mechanism)

ML-KEM replaces classical key exchange mechanisms (RSA key transport, ECDH key agreement) used in TLS, VPNs, SSH, and encrypted email. It is derived from the CRYSTALS-Kyber submission.

Parameter Set	Security Level	Public Key Size	Ciphertext Size	Shared Secret Size
ML-KEM-512	NIST Level 1 (≈AES-128)	800 bytes	768 bytes	32 bytes
ML-KEM-768	NIST Level 3 (≈AES-192)	1,184 bytes	1,088 bytes	32 bytes
ML-KEM-1024	NIST Level 5 (≈AES-256)	1,568 bytes	1,568 bytes	32 bytes

For comparison, an X25519 ECDH public key is 32 bytes. ML-KEM-768 — the recommended general-purpose parameter set — produces a public key 37x larger. This is not a drop-in replacement in size-constrained protocols.

FIPS 204: ML-DSA (Module-Lattice-Based Digital Signature Algorithm)

ML-DSA replaces RSA signatures and ECDSA signatures used in TLS certificates, code signing, document signing, and authentication tokens. It is derived from the CRYSTALS-Dilithium submission.

Parameter Set	Security Level	Public Key Size	Signature Size	Signing Key Size
ML-DSA-44	NIST Level 2 (≈SHA-256)	1,312 bytes	2,420 bytes	2,560 bytes
ML-DSA-65	NIST Level 3 (≈AES-192)	1,952 bytes	3,309 bytes	4,032 bytes
ML-DSA-87	NIST Level 5 (≈AES-256)	2,592 bytes	4,627 bytes	4,896 bytes

An ECDSA P-256 signature is 64 bytes. An ML-DSA-65 signature is 3,309 bytes — 51x larger. For TLS certificate chains containing 3-4 signatures, this has measurable network impact.

FIPS 205: SLH-DSA (Stateless Hash-Based Digital Signature Algorithm)

SLH-DSA is the conservative backup option derived from SPHINCS+. It relies exclusively on hash function security — no lattice assumptions. If lattice-based schemes are ever broken, SLH-DSA remains secure.

Parameter Set	Security Level	Public Key Size	Signature Size	Use Case
SLH-DSA-128s	Level 1	32 bytes	7,856 bytes	Small keys, large signatures
SLH-DSA-128f	Level 1	32 bytes	17,088 bytes	Fast signing, larger signatures
SLH-DSA-256s	Level 5	64 bytes	29,792 bytes	Maximum security, very large signatures

SLH-DSA signatures are enormous. The “s” (small) variants optimize for smaller signatures at the cost of slower signing. The “f” (fast) variants sign quickly but produce even larger signatures. This algorithm is best suited for firmware signing, root certificates, and other use cases where signature size is tolerable.

---

PQC Migration Trajectory (CNSA 2.0 Timeline)

Projected algorithm distribution across enterprise infrastructure

⚠️ Organizations that haven't started inventory by 2026 will miss CNSA 2.0 network equipment deadline (2030) — migration typically takes 3-5 years.

NSA CNSA 2.0: The Federal Timeline That Affects Everyone

The NSA’s Commercial National Security Algorithm Suite 2.0 (CNSA 2.0) defines transition timelines for National Security Systems. While technically applicable to government systems, these timelines set the pace for the entire ecosystem — vendors, contractors, and supply chain partners follow suit.

Capability	Transition Start	Exclusively PQC By
Software and firmware signing	2025	2030
Web browsers and servers (TLS)	2025	2033
Cloud services and infrastructure	2025	2033
Traditional networking equipment	2026	2030
Operating systems	2026	2033
Niche equipment (embedded, IoT)	2027	2033
Legacy systems that cannot be upgraded	Evaluate now	Plan replacement by 2033

The critical phrase is “exclusively PQC by.” This means classical algorithms (RSA, ECDSA, ECDH) must be completely removed — not just supplemented — from these systems by the stated dates.

CNSA 2.0 Algorithm Requirements

Function	Required Algorithm	Parameter Set
Key Establishment	ML-KEM	ML-KEM-1024
Digital Signatures	ML-DSA	ML-DSA-87
Digital Signatures (backup)	SLH-DSA	SLH-DSA-256s
Symmetric Encryption	AES	AES-256
Hashing	SHA	SHA-384 or SHA-512

NSA mandates Level 5 parameters (ML-KEM-1024, ML-DSA-87) for national security systems. Commercial enterprises may choose Level 3 parameters (ML-KEM-768, ML-DSA-65) based on their risk tolerance and performance requirements.

---

OMB M-23-02: Federal Agency Obligations

Office of Management and Budget Memorandum M-23-02, “Migrating to Post-Quantum Cryptography,” issued in November 2022, establishes specific obligations for federal agencies:

1. Cryptographic inventory — Agencies must inventory all cryptographic systems, with priority on systems vulnerable to “harvest now, decrypt later” attacks.
2. Prioritized migration plan — Agencies must submit migration plans identifying high-value assets and timeline for PQC transition.
3. Annual reporting — Agencies must report progress annually to OMB and CISA.

While M-23-02 directly applies to federal agencies, its effects cascade to:

• Federal contractors (through CMMC and FedRAMP requirements)
• Cloud service providers serving government customers
• Any organization in the federal supply chain
• Financial services firms (OCC and SEC follow federal cybersecurity guidance)
• Healthcare organizations (HHS aligns with NIST frameworks)

If you sell to the US government, your PQC migration timeline is not voluntary.

---

”Harvest Now, Decrypt Later”: The Threat That Drives Urgency

The primary threat model driving PQC urgency is not that quantum computers will break your encryption tomorrow. It’s that adversaries are recording encrypted traffic today, storing it, and will decrypt it when quantum computers mature.

This matters if your encrypted data has value beyond 10-15 years:

Data Type	Value Duration	Exposure Window	Priority
National security intelligence	50+ years	Already at risk	Critical
Trade secrets and IP	10-20 years	Already at risk	High
Medical records (HIPAA)	Patient lifetime	Already at risk	High
Financial transaction records	7-10 years	At risk by 2030	Medium
Personal communications	5-10 years	At risk by 2030	Medium
Session tokens and ephemeral data	Hours to days	Not at risk	Low

For key encapsulation (protecting data in transit), the threat is active now. An adversary recording your TLS sessions today can decrypt them when a cryptographically-relevant quantum computer (CRQC) becomes available.

For digital signatures (authenticating identity), the threat timeline is different. Signatures only need to be secure for the duration they need to be verified. A code signing certificate used today doesn’t need to resist quantum attack unless the signed code will still be verified in 15+ years (firmware, long-lived infrastructure).

---

Vendor Readiness: Who Supports PQC Now

Enterprises don’t implement cryptographic algorithms from scratch. You consume them through vendors, libraries, and platforms. Here’s the current state:

Certificate Authorities

CA	PQC Certificate Support	Status	Notes
DigiCert	ML-DSA hybrid certificates	Available (limited)	PQC test certificates for evaluation
Entrust	ML-DSA research certificates	Lab environment only	Issuing hybrid certs for interop testing
Sectigo	Planning announced	2025-2026	No production issuance yet
Let’s Encrypt	No announcement	N/A	Focus remains on DV automation
Google Trust Services	Internal testing	N/A	Chrome experiments with ML-KEM in TLS

Hardware Security Modules (HSMs)

HSM Vendor	PQC Algorithm Support	Status	Firmware Version
Thales Luna	ML-KEM, ML-DSA	Available	Luna 7.x firmware update
Entrust nShield	ML-DSA, SLH-DSA	Available	nShield 5 with PQC firmware
AWS CloudHSM	ML-KEM (TLS offload)	Limited preview	Via SDK update
Azure Managed HSM	Not yet	Planned 2025-2026	—
Utimaco	ML-KEM, ML-DSA	Available	SecurityServer firmware 5.x
Marvell LiquidSecurity	ML-DSA	In development	Expected 2025

Cryptographic Libraries

Library	ML-KEM	ML-DSA	SLH-DSA	Production Ready
OpenSSL 3.x (via oqs-provider)	✓	✓	✓	Experimental
BoringSSL (Google)	ML-KEM-768	In progress	—	Production (ML-KEM in Chrome)
AWS-LC (libcrypto)	ML-KEM	ML-DSA	—	Production
Bouncy Castle (Java/C#)	ML-KEM	ML-DSA	SLH-DSA	Production
Microsoft SymCrypt	ML-KEM	In development	—	Preview
wolfSSL	ML-KEM	ML-DSA	SLH-DSA	Production

Cloud Provider Support

Provider	Service	PQC Support	Details
AWS	KMS	ML-KEM key agreement	Available for TLS to KMS endpoints
AWS	S2N (TLS library)	ML-KEM hybrid	Used in AWS service endpoints
Google Cloud	Cloud KMS	Experimental	Internal testing
Google	Chrome	ML-KEM-768 hybrid	Default in Chrome 131+ (TLS 1.3)
Microsoft	Azure	SymCrypt integration planned	No production PQC yet
Cloudflare	Edge TLS	ML-KEM hybrid	Available for all customers

---

The Hybrid Approach: Why You Don’t Switch Algorithms Overnight

No responsible engineer deploys a brand-new cryptographic algorithm in production without a safety net. The hybrid approach combines a classical algorithm with a post-quantum algorithm, so that security is maintained even if either algorithm is broken.

Hybrid Key Exchange in TLS 1.3

Chrome and Firefox already support hybrid key exchange using X25519Kyber768Draft00 (now transitioning to X25519MLKEM768). This combines:

• X25519 — Classical elliptic curve Diffie-Hellman (128-bit security against classical computers)
• ML-KEM-768 — Post-quantum key encapsulation (Level 3 security against quantum computers)

Both shared secrets are combined. If ML-KEM is unexpectedly broken, X25519 still provides classical security. If X25519 is broken by a quantum computer, ML-KEM provides post-quantum security.

TLS 1.3 ClientHello key_share extension:
  - x25519_mlkem768 (hybrid): X25519 public key (32 bytes) + ML-KEM-768 public key (1,184 bytes)
  Total key_share: 1,216 bytes (vs. 32 bytes for X25519 alone)

Impact on TLS Handshake Size

Handshake Component	Classical (ECDHE + ECDSA)	Hybrid (X25519+ML-KEM, ECDSA certs)	Full PQC (ML-KEM + ML-DSA certs)
ClientHello key_share	32 bytes	1,216 bytes	1,216 bytes
ServerHello key_share	32 bytes	1,120 bytes	1,120 bytes
Certificate chain (3 certs)	~3,000 bytes	~3,000 bytes	~12,000 bytes
CertificateVerify signature	64 bytes	64 bytes	3,309 bytes
Total handshake	~4,500 bytes	~6,700 bytes	~18,900 bytes

A full PQC handshake is approximately 4x the size of a classical handshake. On low-bandwidth connections (IoT, satellite, mobile in developing regions), this is a measurable performance impact.

Bandwidth Implications at Scale

For high-traffic services handling millions of TLS connections per day:

Daily TLS Connections	Classical Handshake Bandwidth	Full PQC Handshake Bandwidth	Additional Daily Bandwidth
1 million	4.5 GB	18.9 GB	+14.4 GB
10 million	45 GB	189 GB	+144 GB
100 million	450 GB	1.89 TB	+1.44 TB

This doesn’t break most enterprise networks, but it requires capacity planning — especially for edge locations, mobile APIs, and services behind bandwidth-constrained links.

---

Certificate Chain Impact: What Larger Certificates Mean

When ML-DSA certificates replace ECDSA or RSA certificates, every certificate in the chain grows substantially:

Certificate Component	RSA-2048	ECDSA P-256	ML-DSA-65
Public key	256 bytes	64 bytes	1,952 bytes
Signature	256 bytes	64 bytes	3,309 bytes
Typical cert total	~1,200 bytes	~800 bytes	~4,500 bytes
3-cert chain total	~3,600 bytes	~2,400 bytes	~13,500 bytes

Implications for Protocols

• TLS 1.3 — Larger ServerCertificate message. May exceed initial congestion window (typically 10 TCP segments = ~14,600 bytes), requiring additional round trips.
• OCSP stapling — Stapled OCSP responses will also grow if signed with ML-DSA.
• Certificate Transparency — SCTs embedded in certificates add additional bulk.
• HTTP/2 and HTTP/3 — Header compression helps, but initial handshake still pays the full cost.
• DNS-over-HTTPS/TLS — Certificate chain in every new connection impacts DNS resolution latency.

TCP Initial Congestion Window Problem

The standard initial congestion window (initcwnd) is 10 segments, allowing approximately 14,600 bytes in the first flight. A full PQC certificate chain (~13,500 bytes) plus the rest of the ServerHello message may exceed this window, requiring a second round trip before the handshake completes.

Mitigations:

• Increase server initcwnd (ip route change ... initcwnd 20)
• Use TLS certificate compression (RFC 8879)
• Minimize certificate chain length (cross-signed intermediates add bulk)
• Implement TLS session resumption aggressively (0-RTT where appropriate)

---

Network Protocol Changes Required

PQC migration isn’t just a certificate swap. Multiple protocols need updates:

Protocol	Current Crypto	PQC Replacement	Status
TLS 1.3	ECDHE + ECDSA/RSA	ML-KEM + ML-DSA	Hybrid deployed in browsers
SSH	Ed25519, RSA	ML-KEM + ML-DSA (draft)	IETF drafts in progress
IPsec/IKEv2	ECDH + RSA/ECDSA	ML-KEM + ML-DSA	RFC 9370 (framework), algorithms TBD
S/MIME	RSA + ECDSA	ML-KEM + ML-DSA	IETF drafts in progress
DNSSEC	RSA, ECDSA	SLH-DSA (research)	Signature size is a major problem
Code signing	RSA, ECDSA	ML-DSA	Supported in some toolchains
Kerberos	AES (symmetric)	Minimal impact	KDC-to-KDC may need PQC
LDAPS	TLS-based	Inherits TLS changes	Follows TLS migration
802.1X (RADIUS/EAP)	TLS-based	Inherits TLS changes	Certificate size matters for EAP

SSH Considerations

OpenSSH 9.0+ already uses a hybrid key exchange (sntrup761x25519-sha512@openssh.com) by default. The post-quantum component (NTRU Prime) predates the NIST selections, and future versions will transition to ML-KEM. No action needed for key exchange if you’re running current OpenSSH.

SSH host keys and user keys signed with ML-DSA will require client updates. Plan for a transition period where both classical and PQC host keys are presented.

IPsec/VPN Considerations

RFC 9370 defines the framework for PQC in IKEv2 but does not specify which algorithms to use. Vendor implementations are pending. For site-to-site VPNs:

• Verify your VPN appliance vendor’s PQC roadmap
• Plan for larger IKE_SA_INIT packets (may exceed typical MTU)
• Test with hybrid key exchange when vendor firmware supports it
• Consider IP fragmentation impacts for large IKE messages

---

Testing PQC in TLS 1.3 Today

You can test post-quantum key exchange right now without any infrastructure changes:

Chrome/Chromium

Chrome 124+ supports hybrid key exchange by default. To verify:

1. Navigate to a site supporting hybrid key exchange (e.g., cloudflare.com, google.com)
2. Open DevTools → Security tab
3. Look for “X25519Kyber768” or “X25519MLKEM768” in the key exchange field

OpenSSL Testing

# Build OpenSSL with OQS provider for PQC algorithm support
# Using the oqs-provider project (https://github.com/open-quantum-safe/oqs-provider)

# Test ML-KEM key generation
openssl genpkey -algorithm mlkem768 -out mlkem768_key.pem

# Test ML-DSA key generation
openssl genpkey -algorithm mldsa65 -out mldsa65_key.pem

# Create a test certificate with ML-DSA
openssl req -x509 -new -key mldsa65_key.pem -out mldsa65_cert.pem \
  -days 365 -subj "/CN=PQC Test Certificate"

# Start a test TLS server with PQC
openssl s_server -cert mldsa65_cert.pem -key mldsa65_key.pem \
  -groups x25519_mlkem768 -port 4433

# Connect with hybrid key exchange
openssl s_client -groups x25519_mlkem768 -connect localhost:4433

Measuring Handshake Performance

# Benchmark classical vs hybrid TLS handshake latency
# Classical (X25519 + ECDSA)
openssl s_time -connect target:443 -new -time 10

# Hybrid (X25519+ML-KEM, if server supports it)
openssl s_client -groups x25519_mlkem768 -connect target:443 \
  -brief 2>&1 | grep -i "protocol\|cipher\|group"

# Measure handshake bytes with tcpdump
tcpdump -i eth0 -w handshake_classical.pcap "port 443" &
curl -so /dev/null https://classical-server.example.com
kill %1

tcpdump -i eth0 -w handshake_pqc.pcap "port 443" &
curl -so /dev/null https://pqc-server.example.com
kill %1

# Compare pcap sizes for handshake overhead
ls -la handshake_*.pcap

---

The 5-Step Enterprise Action Plan

Step 1: Build a Cryptographic Bill of Materials (CBOM)

You cannot migrate what you cannot find. A CBOM documents every cryptographic algorithm, key, certificate, and protocol in use across your environment.

What to inventory:

Category	What to Document	Where to Look
TLS certificates	Algorithm, key size, CA, expiry	Certificate inventory tools, CT logs
SSH keys	Algorithm, key size, location	~/.ssh/, /etc/ssh/, key management systems
VPN configurations	Key exchange, authentication	Firewall/VPN appliance configs
Code signing certificates	Algorithm, key size, HSM location	Build systems, signing servers
Database encryption (TDE)	Algorithm, key wrapping method	Database configs, KMS
File/disk encryption	Algorithm, key management	BitLocker, LUKS, FileVault configs
API authentication tokens	Signing algorithm (JWT, HMAC)	Identity providers, API gateways
Email encryption (S/MIME)	Algorithm, certificate CA	Email server configs, user certs
Hardware tokens (FIDO2)	Attestation key algorithm	Token vendor documentation
Embedded/IoT devices	Firmware signing, TLS stack	Device inventory, vendor specs

Tools for discovery:

• Network scanning: Identify TLS versions and cipher suites in use (sslyze, testssl.sh)
• Code scanning: Find cryptographic library calls in source code (semgrep rules for crypto)
• Configuration audits: Parse configs for algorithm references
• Vendor documentation: Catalog what algorithms each product uses internally

Step 2: Classify by Risk and Migration Complexity

Not everything migrates at once. Prioritize based on:

Priority	Criteria	Examples
P1 — Immediate	Protects data with 15+ year value; harvest-now threat applies	Classified data, trade secrets, healthcare records
P2 — Near-term (2025-2027)	Public-facing TLS; vendor mandates approaching	Web servers, API endpoints, customer portals
P3 — Medium-term (2027-2030)	Internal infrastructure; no immediate threat	Internal PKI, Active Directory CS, LDAPS
P4 — Long-term (2030-2033)	Legacy systems; replacement more practical than upgrade	Embedded devices, mainframes, EOL appliances

Step 3: Enable Hybrid Key Exchange in TLS

This is the lowest-risk, highest-impact action available today:

1. Verify your TLS termination software supports hybrid groups (Nginx 1.25+, HAProxy with OpenSSL 3.2+, cloud load balancers)
2. Add x25519_mlkem768 to your server’s supported groups list
3. Clients that support hybrid (Chrome, Firefox, Edge) will automatically negotiate it
4. Clients that don’t will fall back to classical key exchange — no breakage

# Nginx configuration for hybrid key exchange
ssl_ecdh_curve x25519_mlkem768:X25519:prime256v1;

This single change protects all new TLS sessions against future quantum decryption of recorded traffic.

Step 4: Engage Your Vendor Ecosystem

Vendor Type	Questions to Ask
Certificate Authority	When will you issue ML-DSA certificates? Do you support hybrid?
HSM vendor	What firmware version supports PQC? What’s the upgrade path?
Cloud provider	Which services support PQC key exchange? What’s the roadmap?
VPN appliance vendor	When will IKEv2 PQC support ship? Will hybrid be available?
PKI software (AD CS, EJBCA)	What’s the PQC roadmap? Can it issue ML-DSA certs?
Code signing platform	When will ML-DSA signing be available?
Email gateway	S/MIME with PQC — what’s the timeline?

Step 5: Plan Migration Budget and Resources

Budget Category	Estimated Range	Timing
Cryptographic inventory and assessment	$50,000 - $200,000	Year 1
HSM firmware upgrades or replacements	$100,000 - $500,000	Year 1-2
PKI infrastructure updates	$75,000 - $300,000	Year 1-3
Application code changes	$200,000 - $1,000,000	Year 2-4
Network infrastructure upgrades	$100,000 - $400,000	Year 2-3
Testing and validation	$50,000 - $150,000	Ongoing
Training and skills development	$25,000 - $75,000	Ongoing
Total estimated range	$600,000 - $2,625,000	3-5 years

These ranges vary enormously based on environment complexity, certificate volume, and legacy system burden. A 500-person SaaS company with modern infrastructure will be on the low end. A global financial institution with mainframes will be on the high end.

---

Common Mistakes to Avoid

Mistake	Why It’s Wrong	Correct Approach
”We’ll wait until quantum computers exist”	Harvest-now attacks mean the threat is active today	Start hybrid key exchange now
”Our CA will handle it”	CAs issue certificates — they don’t manage your migration	Own your migration plan
”We only need to change TLS”	VPN, SSH, code signing, tokens all use vulnerable crypto	Inventory everything
”ML-KEM is drop-in for RSA”	Key sizes, performance, and protocols all change	Test thoroughly before deploying
”We’ll skip hybrid and go straight to PQC”	Pure PQC lacks years of deployment experience	Hybrid provides safety net
”Our compliance framework doesn’t require PQC yet”	OMB M-23-02 and CNSA 2.0 set hard deadlines	Federal supply chain requirements propagate

---

Timeline Summary

Date	Event	Enterprise Impact
August 2024	FIPS 203/204/205 published	Standards are final — begin planning
2025	CNSA 2.0 transition starts (software signing, TLS)	Vendors must begin PQC support
2025-2026	FedRAMP/CMMC expected to reference PQC requirements	Federal suppliers must demonstrate progress
2027	Additional NIST standards (HBS, signature on-ramp)	More algorithm choices available
2030	CNSA 2.0 deadline for networking equipment, code signing	Classical-only systems non-compliant
2033	CNSA 2.0 deadline for all systems exclusively PQC	No classical algorithms permitted in NSS
2030-2040	Estimated CRQC availability (broad range)	Recorded traffic becomes decryptable

---

What to Start This Quarter

1. Request your vendor PQC roadmaps — If your HSM vendor, CA, or PKI platform cannot articulate a PQC timeline, that’s a procurement risk you need to evaluate now.

2. Enable hybrid key exchange on one public-facing service — Pick your marketing site or developer portal. Enable x25519_mlkem768. Measure performance. Build confidence.

3. Initiate CBOM development — Even a partial cryptographic inventory is better than none. Start with TLS certificates and SSH keys. Expand from there.

4. Brief your CISO with a timeline slide — Frame this as: “The standards are final. Federal mandates exist. Our vendors are moving. Here’s our recommended timeline and budget range.”

5. Identify a PQC pilot project — A new microservice, a test environment, an internal tool. Somewhere you can deploy ML-KEM and ML-DSA certificates without production risk.

---

About QCecuring

QCecuring helps enterprise teams navigate the post-quantum transition — from cryptographic inventory through production migration. Our platform provides automated CBOM generation, PQC readiness assessment, and certificate lifecycle management that supports both classical and post-quantum algorithms.

We don’t sell fear. We sell operational readiness. The standards are published, the timelines are set, and the work begins with knowing what you have.

Start your cryptographic inventory →

---

Tags: NIST, Post-Quantum Cryptography, PQC, FIPS 203, FIPS 204, FIPS 205, ML-KEM, ML-DSA, SLH-DSA, CNSA 2.0, OMB M-23-02, Hybrid Key Exchange, TLS 1.3, Cryptographic Inventory, CBOM, Enterprise Security, Quantum Computing