One of the Four NIST PQC Algorithms Can Already Run on Your Infrastructure
If your infrastructure runs behind Cloudflare, you may be further along than you think. Post-quantum encryption at the edge is on by default. The three signing algorithms are still open decisions: code signing pipelines, long-lived records, and bandwidth-constrained systems each map to a different algorithm, a different readiness level, and one with documented implementation risk that NSA's own guidance flags.
NIST finalized three post-quantum cryptography standards in August 2024. A fourth, FN-DSA, was selected as part of the same process and is on track for finalization later in 2026. One of the three may already be active on your infrastructure right now, without any migration work on your end.
The urgency is real. In August 2023, CISA, NSA, and NIST published a joint advisory stating that adversaries are actively stealing encrypted data today with the intent to decrypt it once quantum capability matures. Harvest-now-decrypt-later (HNDL), exfiltrating encrypted traffic now and decrypting it when quantum computers reach sufficient scale, is the operational planning assumption driving current national security cryptography requirements, not a speculative future threat.
The four algorithms operate at different readiness levels, carry distinct implementation risks, and exist for separate use cases. Here is the status map.
The Map: Current Status of All Four
The four NIST PQC algorithms span two problem categories: three digital signature algorithms (proving authenticity and integrity) and one key encapsulation mechanism (protecting data in transit). The three signatures require deliberate migration work. The KEM may already be running.
ML-DSA
FIPS 204A digital signature algorithm based on the Module Lattice structure (the CRYSTALS-Dilithium submission). CNSA 2.0 includes ML-DSA-87 as the approved signature algorithm for national security systems. Signature sizes are reasonable: approximately 2.4 KB at security level 128, 4.6 KB at level 256. Key generation and signing are fast.
This is NIST's primary recommendation for general-purpose post-quantum signing: code signing in deployment pipelines, AI model artifact signing, document authentication. For these use cases, ML-DSA is deployable today.
In practice, the migration looks like substituting the signing call in your pipeline. Where a current CI/CD step calls GPG or Cosign, the ML-DSA equivalent uses @noble/post-quantum in Node.js or the OQS Python and Go bindings. The API shape is the same: generate a key pair, call sign(privateKey, message), distribute the public key for verification. The surrounding pipeline, artifact storage, deployment gating, and verification tooling, stays unchanged.
One practical caveat worth stating plainly: "production ready" means the standard is finalized and compliant library implementations exist. For public TLS certificate signing, mainstream CAs, including Let's Encrypt, do not yet issue ML-DSA certificates, and browsers don't accept them. ML-DSA public keys run 1,312 bytes at security level 2 (ML-DSA-44) and 1,952 bytes at security level 3 (ML-DSA-65). The CNSA 2.0 requirement is ML-DSA-87 (security level 5, ~2,592-byte public keys) for national security systems; those SL2 and SL3 figures reflect the parameter range for non-NSS applications. Versus 32 bytes for ED25519, the size differential makes traditional ML-DSA certificate chains impractical at scale regardless of parameter set. Google has announced it will not embed ML-DSA into traditional X.509 for Chrome; instead, Google and Cloudflare are developing a Merkle Tree Certificate format where ML-DSA signatures are operationally viable. No CA/Browser Forum deadline is published. For signing workloads you control end-to-end, such as internal pipelines, document authentication, and code signing, neither constraint applies, and ML-DSA is deployable today.
SLH-DSA
FIPS 205A stateless hash-based digital signature algorithm, standardized from SPHINCS+. Its security rests on hash function properties, specifically one-wayness and collision resistance, rather than the lattice mathematics underpinning ML-DSA and FN-DSA. That distinction is deliberate: NIST published SLH-DSA alongside ML-DSA specifically so the security of the post-quantum signature ecosystem doesn't rest on a single mathematical assumption. If a weakness in lattice-based signatures surfaces, SLH-DSA is unaffected.
Signature sizes are larger, and the exact size depends on which parameter set you choose. SHAKE-128s (the small variant) produces ~8 KB signatures but signs more slowly. SHAKE-128f (the fast variant) produces ~17 KB signatures but signs in 10–50 ms, fast enough for serverless workloads, impractical for high-frequency operations regardless of variant. For once-per-record signing, the fast variant is typically the right choice: the extra 9 KB of storage per record is irrelevant against a 10-year retention horizon, and signing latency matters more than signature size in most system designs.
One underappreciated practical advantage: the SLH-DSA public key is 32 bytes. Compare that to ML-DSA-65's ~1,952-byte public key. When the public key lives in a certificate field, a database column, or needs to be independently verified by a third party a decade from now, that size difference is real. The signature is large; the key used to verify it is not.
The standard production signing pattern: compute a SHA-256 hash of the document or transaction metadata, then sign the hash, not the raw document. The signature proves the hash existed and was authenticated at signing time, without the document content ever touching the signing layer. This is lightweight, privacy-preserving, and correct for systems where the document lives elsewhere (object storage, a content-addressed ledger, an encrypted archive). SLH-DSA is in active deployment on a document integrity platform built on this architecture. See the architectural breakdown for the key management design details.
Tooling exists today. @noble/post-quantum is a production-quality TypeScript/Node implementation. Open Quantum Safe (OQS) provides reference implementations in C, Python, Go, and Rust. The implementation surface is well-covered across the major runtime environments.
FN-DSA
FIPS 206 (forthcoming)A digital signature algorithm based on the NTRU lattice using fast Fourier techniques over integer rings. FN-DSA was selected in August 2024 as part of the same NIST process, and its signature size advantage is significant: approximately 650 bytes at security level 128, compared to ML-DSA's ~2.4 KB. For bandwidth-constrained environments such as IoT device attestation, DNSSEC records, and blockchain transactions, that size difference is operationally meaningful.
The implementation risk is documented at the academic level. FN-DSA's signature generation requires Gaussian sampling over the integers using floating-point arithmetic. A 2025 Eurocrypt paper demonstrated a key recovery vector against implementations using standard floating-point arithmetic, including FN-DSA's reference implementation. NSA has not included FN-DSA in CNSA 2.0. Broader implementation guidance and ecosystem support are expected to mature through late 2026 and into 2027.
For most production deployments, the implementation complexity risk outweighs the signature size benefit until that guidance matures. In practice, the right posture is to name the specific workload where 650-byte signatures create a real operational constraint, such as DNSSEC record signing, IoT device attestation, or blockchain transaction signing, and write down two concrete deployment criteria: NSA CNSA 2.0 inclusion, and a production-ready constant-time implementation available in the cryptographic library the target stack uses. Tracking means watching OQS release notes for a constant-time Gaussian sampler and monitoring NSA guidance updates for a policy inclusion signal. When both criteria are met, the deployment decision is already made.
ML-KEM
FIPS 203A key encapsulation mechanism based on the Module Learning With Errors (MLWE) lattice problem. ML-KEM replaces the key exchange function that ECDH performs in TLS and other encrypted channel protocols. It is the primitive that establishes a shared secret before data transmission begins.
Deployment is real and broad. Google Chrome adopted ML-KEM for TLS 1.3 key exchange in 2024. Signal and Apple's iMessage have both deployed it. CNSA 2.0 includes ML-KEM-1024 as the approved key agreement algorithm for national security systems, with compliance required for new NSS acquisitions by January 1, 2027.
Cloudflare has integrated ML-KEM directly into its edge network, enabling hybrid TLS (X25519 paired with ML-KEM) by default across all zones. The hybrid design is deliberate: pairing classical X25519 with ML-KEM means that if an undiscovered flaw in ML-KEM's lattice math surfaces, classical security holds. It also means supporting clients (Chrome 130+, recent Firefox and Safari builds) negotiate ML-KEM while non-supporting clients fall back to X25519 without connection failure. Any site behind Cloudflare with TLS 1.3 enabled is already negotiating ML-KEM hybrid key exchange with supporting clients without application code changes. The pq_keyex zone setting surfaces this explicitly in Cloudflare's API and Terraform provider, so teams managing zones as infrastructure as code can track and enforce it consistently across zones.
To verify it's active on a zone you manage: open Chrome DevTools on any Cloudflare-proxied page, go to the Security tab, and check the key exchange algorithm listed under Connection. A Chrome client negotiating with Cloudflare will show a hybrid that includes an ML-KEM component alongside X25519. The same detail surfaces in curl -v --tlsv1.3 output under the SSL connection line.
One important framing: Cloudflare covers the public-facing edge hop. A production stack has more hops: the reverse proxy layer, internal service-to-service TLS, Kubernetes API server communication, SSH. Each of those requires its own explicit configuration. "ML-KEM at the edge" and "ML-KEM across the transit layer" are meaningfully different postures.
The Decision Layer: Matching Algorithm to Use Case
The use cases map cleanly to algorithm properties once the readiness context is in place. Each algorithm addresses a distinct use case. The decision is matching the right one to the problem in front of you.
Signing code, models, and documents
ML-DSA
General-purpose digital signatures: code signing in deployment pipelines, AI model artifact signing, document authentication, certificate issuance. ML-DSA is NIST's primary recommendation for this category, with reasonable signature sizes, fast verification, and CNSA 2.0 approval. Most signing migrations across existing infrastructure start here. The lattice-based foundation is shared with ML-KEM, which means your team's implementation experience transfers.
High-assurance, long-lived integrity
SLH-DSA
Records that need cryptographic validity over a multi-year or multi-decade horizon: notarization records (10-year statutory retention in many jurisdictions), healthcare records under HIPAA's 6-year minimum, regulatory filing archives, SOC 2 audit trails. These are live retention obligations generating signed records today that need to verify in 2035.
The hash-based security foundation provides a hedge against lattice vulnerabilities. If ML-DSA's mathematical basis surfaces a problem in 2033, SLH-DSA signatures remain valid because they rest on different math entirely. The stateless design eliminates the state management risk that makes XMSS and LMS harder to deploy: each signing operation is independent, deterministic, and concurrent-safe, with no state file, no locking, and correct behavior in serverless and horizontally scaled deployments. Signature size matters less when signing happens once at record creation.
If the system also uses a ledger or blockchain for timestamping, SLH-DSA and the ledger address separate concerns: SLH-DSA provides cryptographic proof of authenticity; the ledger provides tamper-evident availability and an independent timestamp. They're complementary, not redundant.
Bandwidth-constrained signing
FN-DSA (when finalized for broad deployment)
The right long-term answer for IoT device attestation, DNSSEC record signing, and blockchain transaction signatures, environments where 650-byte signatures matter and ML-DSA's 2.4 KB creates real constraints. The use case is real and the algorithm addresses it well. The correct posture today is to identify the workload, define the deployment criteria (specifically: NSA CNSA 2.0 inclusion and ecosystem support in the relevant cryptographic libraries), and wait for the implementation guidance to mature rather than treating it as equivalent to the other three.
Protecting data in transit
ML-KEM
TLS key exchange, VPN tunnel establishment, encrypted messaging channels. ML-KEM replaces the ECDH function in these protocols without requiring architectural changes to the surrounding system. It's the highest-deployment algorithm in the set with the most mature tooling across cryptographic libraries, and the transition path for most encrypted channel protocols runs directly through it. For infrastructure running behind Cloudflare, hybrid ML-KEM TLS is already active at the edge by default, requiring no code changes and verifiable through a cipher suite inspection. If ECDH is anywhere else in the encryption layer, ML-KEM is the first migration step.
What Readiness Actually Looks Like
The framing that makes PQC migration feel like a single large undertaking is treating all four algorithms as one decision. They're four separate decisions, tied to four separate use cases, operating on different implementation timelines.
Crypto-agility is the design property that makes this tractable: abstracting the cryptographic layer from the application architecture so algorithm transitions don't require rebuilding surrounding infrastructure. It's what allows an ML-KEM deployment and an SLH-DSA deployment to happen independently, on their own timelines, without coupling to each other.
There is also a threat model distinction worth making explicit, because it drives the implementation order. HNDL is a retroactive threat: encrypted traffic captured today can be decrypted later, once a capable quantum computer exists. That makes key exchange, specifically ML-KEM, the first-priority migration. If an adversary has already captured your ciphertext, no future action undoes that exposure.
The signature threat model has a parallel worth naming: Sign-Today-Forge-Tomorrow (SFTF), sometimes framed as Trust-Now-Forge-Later. It's worth being precise about how it relates to HNDL. Forgery attacks require quantum capability at the time of the attack. There is no passive collection equivalent to recording encrypted traffic. The public keys, however, are already public. Any ECDSA key that has appeared in a certificate, a signed transaction, or a published document is permanently on the record. When a capable quantum computer exists, private key derivation from those public keys becomes feasible without any pre-Q-Day capture step. SFTF is a structural exposure that already exists in the current key record: the threat emerges at Q-Day, but the vulnerable keys are already public.
The hardware root-of-trust case sharpens this. ePassports, industrial control systems, and satellites frequently embed long-lived signing keys with no viable field update path, because update infrastructure doesn't reach them, or physical access at scale is impractical. These assets can't migrate on a software update schedule. The cryptographic exposure at Q-Day is locked in at manufacturing. For new systems entering service now, deploying with ML-DSA or SLH-DSA from the start avoids inheriting that fixed exposure window.
The migration priority ordering holds: HNDL creates an active collection window where delay has compounding cost. Traffic captured today is stored, and no future action closes that window. SFTF doesn't carry the same retroactive risk, and NIST's own transition guidance acknowledges that signature migration is less time-sensitive than key exchange for this reason. The urgency for signing migration comes from a different constraint: PKI infrastructure takes years to replace across a full stack, and hardware-embedded keys with no update path have a vulnerability window that is fixed at manufacturing. The case for deploying ML-DSA and SLH-DSA in new systems now is lead-time, not collection risk.
Across the four-algorithm set, here is current operational state, algorithm by algorithm:
Running in the transit layer. Key exchange migrated. CNSA 2.0 compliant at the channel encryption layer.
Running in the document integrity signing layer, with crypto-agile architecture: algorithm selection abstracted at the signing layer, not baked into application logic. Long-lived records are accumulating under hash-based signatures.
Parameter selection complete. Library evaluation done. Integration path defined for the general-purpose signing pipeline. Implementation follows scoping, not the other way around.
Use case identified (bandwidth-constrained signing workloads). Deployment criteria defined: NSA CNSA 2.0 inclusion and library support in the target stack. Not scheduled until those criteria are met.
Two algorithms running in production. One in active scoping. One tracked against defined deployment criteria. Each algorithm has a clear status, a mapped use case, and a specific next decision, not a vague "we'll address it when quantum becomes real."
That structure is what crypto-agility looks like when it's a deliberate design property. The HNDL exposure window on data in transit is closed. Long-lived records are accumulating under hash-based signatures. The general signing layer has a defined migration path. The bandwidth-constrained case has deployment criteria rather than an open question. Nothing is waiting on a threat becoming urgent before someone starts the design work.
Sources
- NIST FIPS 203: Module-Lattice-Based Key-Encapsulation Mechanism Standard (ML-KEM)
- NIST FIPS 204: Module-Lattice-Based Digital Signature Standard (ML-DSA)
- NIST FIPS 205: Stateless Hash-Based Digital Signature Standard (SLH-DSA)
- NIST CSRC: FN-DSA (Falcon): FIPS 206 Algorithm Overview and Status (forthcoming standard)
- NSA: Commercial National Security Algorithm Suite 2.0 (CNSA 2.0, May 2025)
- CISA / NSA / NIST: Quantum-Readiness: Migration to Post-Quantum Cryptography (August 2023)
- NIST IR 8547: Transition to Post-Quantum Cryptography Standards (Initial Public Draft, 2024)
- Cloudflare: State of the Post-Quantum Internet (2025)
- IETF: Hybrid Key Exchange in TLS 1.3 (draft-ietf-tls-hybrid-design)
- Lin et al.: Do Not Disturb a Sleeping Falcon: Floating-Point Error Sensitivity of the Falcon Sampler (Eurocrypt 2025)
The edge layer is the same starting point at any stack size.
Cloudflare's ML-KEM integration is active by default across every zone. A single-person operation and a prime contractor managing a hundred domains have the same edge posture. Post-quantum key exchange at the transit layer isn't a large-team problem.
What sits behind that edge is a different question for every stack. Signing pipelines, long-retention records, certificate infrastructure, internal service-to-service TLS: each carries its own exposure profile. See how the web and API protection service maps to your architecture, or start a conversation about what the full stack looks like.
See Edge SecurityRelated
Facing FIPS 140-3 on regulated work?
FEDLIN does the execution: rebuilding the platform on FIPS-validated modules, bringing every function back on approved cryptography, and carrying the post-quantum layer as it arrives. Built to the requirement ahead of the contract.
Subscribe to Security Insights
Get enterprise security tips, compliance guides, and best practices delivered to your inbox.