The Post-Quantum Countdown: NIST Standards Are Live — Is Your Stack Ready?
This week, AWS announced that all new TLS connections to S3 and API Gateway are negotiated using ML-KEM (Kyber) — NIST's finalized post-quantum key encapsulation mechanism — as part of a hybrid classical/PQC handshake. Cloudflare, which has been running X25519+Kyber in Chrome for two years, confirmed the same shift on their edge network.
The cryptographic migration that security teams have been deferring is no longer theoretical. It's happening. The question is whether your application is ready — or whether you're quietly accumulating quantum debt.
Why Post-Quantum Cryptography?
The threat model is "harvest now, decrypt later." A capable adversary captures your TLS traffic today and stores it. When a cryptographically-relevant quantum computer exists — timelines range from 5 to 15 years — they decrypt it retroactively.
If your application handles data that must remain confidential for more than 5 years — health records, financial history, government data, trade secrets — that data is at risk today, even without a quantum computer in sight.
The math is stark: RSA-2048 and ECDH P-256, the workhorses of modern TLS, are broken in polynomial time by Shor's algorithm on a sufficiently powerful quantum computer. The NSA has already mandated PQC for classified systems by 2030.
The NIST PQC Standards (Finalized)
| Algorithm | Type | Purpose | Standard |
|---|---|---|---|
| ML-KEM (Kyber) | Lattice | Key encapsulation | FIPS 203 |
| ML-DSA (Dilithium) | Lattice | Digital signatures | FIPS 204 |
| SLH-DSA (SPHINCS+) | Hash-based | Digital signatures | FIPS 205 |
| FN-DSA (Falcon) | NTRU lattice | Digital signatures | FIPS 206 |
CRYSTALS-Kyber and CRYSTALS-Dilithium are the primary workhorses. SPHINCS+ is the conservative fallback that relies only on hash function security.
What's Already Migrated (And What Isn't)
Migrated by default in 2026:
- Chrome, Firefox, Safari — all negotiate hybrid TLS with X25519MLKEM768
- AWS, GCP, Azure TLS endpoints — hybrid handshakes on all new connections
- Let's Encrypt certificate issuance — ML-DSA signatures available in beta
Not migrated yet (your responsibility):
- JWTs and API signing keys — still typically ECDSA or RSA
- Database encryption at rest — usually AES-256 (symmetric, quantum-resistant) but key wrapping may use RSA
- SSH keys to your servers — still predominantly Ed25519 (safe until ~2030, plan migration)
- Code signing certificates — most CI/CD pipelines still use RSA-2048 or ECDSA
- mTLS between your own services — self-managed certificates you chose the algorithm for
Auditing Your Stack: A Developer Checklist
# 1. Scan for RSA/EC key usage in your codebase
grep -rn --include="*.ts" --include="*.js" --include="*.py" \
"RSA\|createECDH\|generateKeyPair.*ec\|rs256\|es256" ./src
# 2. Check your TLS certificate algorithm
echo | openssl s_client -connect yourapp.com:443 2>/dev/null \
| openssl x509 -noout -text | grep "Public Key Algorithm"
# 3. List SSH keys in use
ssh-keygen -l -f ~/.ssh/id_rsa 2>/dev/null
ssh-keygen -l -f ~/.ssh/id_ed25519 2>/dev/null
Node.js: Generating PQC-Ready Keys
The Web Crypto API doesn't yet support ML-KEM natively in Node.js 22, but @noble/post-quantum gives you a pure-JS implementation:
import { ml_kem768 } from "@noble/post-quantum/ml-kem";
// Key generation
const { publicKey, secretKey } = ml_kem768.keygen();
// Encapsulation (sender side)
const { cipherText, sharedSecret: senderSecret } = ml_kem768.encapsulate(publicKey);
// Decapsulation (receiver side)
const receiverSecret = ml_kem768.decapsulate(cipherText, secretKey);
// senderSecret === receiverSecret ✓
The Hybrid Approach
Don't drop classical crypto outright. Run hybrid key exchange — classical ECDH + ML-KEM in parallel, XOR the shared secrets together. You keep classical security guarantees while adding quantum resistance. This is exactly what AWS and Cloudflare are doing.
import { x25519 } from "@noble/curves/ed25519";
import { ml_kem768 } from "@noble/post-quantum/ml-kem";
import { sha256 } from "@noble/hashes/sha2";
function hybridKeyExchange(
ecPriv: Uint8Array,
ecPub: Uint8Array,
kemPub: Uint8Array
) {
const ecShared = x25519.getSharedSecret(ecPriv, ecPub);
const { cipherText, sharedSecret: kemShared } = ml_kem768.encapsulate(kemPub);
// Combine secrets via hash — neither alone is sufficient
const combined = sha256(new Uint8Array([...ecShared, ...kemShared]));
return { combined, cipherText };
}
Timeline for Developers
| When | Action |
|---|---|
| Now | Audit key types in use. Identify RSA/EC in signing and encryption paths. |
| Q2 2026 | Migrate API signing (JWTs) to ML-DSA. Update SSH keys to new PQC variants. |
| Q4 2026 | Rotate code-signing certs. Implement hybrid TLS for internal services. |
| 2027 | Deprecate all RSA < 4096 and EC < P-384 in internal systems. |
| 2030 | NSA mandate deadline for classified systems. Most enterprises should be fully migrated. |
The harvest-now-decrypt-later threat is real, active, and growing. The good news: the standards are finalized, the tooling is maturing, and the cloud providers are doing most of the heavy lifting for public-facing connections.
Your job is the data that moves between your services, the signatures your code produces, and the keys that protect your stores. Start the audit today.
Published March 12, 2026
