Cloudflare Workers Post-Quantum Web Crypto Adds ML-KEM and ML-DSA

Cloudflare Workers can now use two of the main cryptographic building blocks designed for the post-quantum era directly through its Web Crypto implementation. The October 1 update adds ML-KEM for establishing shared secrets and ML-DSA for digital signatures, but the support is deliberately opt-in and incomplete because the underlying Web Crypto proposal is still evolving.

That distinction matters more than the algorithm names. Developers can now test post-quantum protocols without shipping another cryptography implementation inside their Workers applications, yet Cloudflare is not presenting the new interface as a drop-in replacement for existing security systems. The useful story is therefore less about quantum computers arriving and more about the web runtime beginning to expose the primitives needed to prepare for them.

Cloudflare Workers now exposes the primitives developers were missing

The new support sits inside Web Crypto, the browser and server-side JavaScript interface used for low-level cryptographic operations such as key generation, signing, verification and encryption. Cloudflare Workers already implements Web Crypto through the crypto.subtle interface, but its newly added modern-algorithm layer is controlled by a separate webcrypto_modern_algorithms compatibility flag. That keeps applications on the existing behavior unless their developers explicitly choose the experimental API.

Cloudflare lists ML-KEM-768 and ML-KEM-1024 for key encapsulation, alongside ML-DSA-44, ML-DSA-65 and ML-DSA-87 for signatures. The update also adds operations for encapsulating and decapsulating key material, public-key extraction, capability detection through SubtleCrypto.supports(), and JSON Web Key support using the new algorithm type. In practical terms, this gives a Worker application native access to the mathematical pieces that higher-level secure protocols can build around.

ML-KEM and ML-DSA solve different parts of the problem

ML-KEM is a key-encapsulation mechanism, which means it lets two parties establish shared secret material over a public connection. That shared material can then be fed into conventional symmetric encryption rather than being used as the message encryption itself. NIST standardized ML-KEM in FIPS 203 in 2024 and defined three parameter sets, with ML-KEM-768 and ML-KEM-1024 offering different security and performance trade-offs.

ML-DSA handles a different job. It is a digital-signature algorithm used to prove that data was signed by the holder of a private key and that the signed data has not been altered. NIST standardized ML-DSA in FIPS 204, making it one of the finalized post-quantum signature standards alongside the separate SLH-DSA standard. That makes the Workers update more useful than simply adding another encryption option: developers can experiment with both post-quantum key establishment and authentication primitives in the same Web Crypto environment.

Why native Web Crypto support changes the development trade-off

Before this kind of runtime support, a JavaScript project wanting to experiment with newer post-quantum primitives could bundle a third-party implementation or use another execution layer. That approach can work, but it leaves application developers responsible for carrying and maintaining cryptographic code that ideally belongs underneath the platform's standard cryptography interface. Cloudflare says its native implementation is intended to reduce that burden while giving library authors something concrete to test.

The advantage is not simply fewer lines in an application's dependency tree. Web Crypto provides a standardized interface while the runtime supplies the underlying implementation, allowing developers to write against cryptographic operations rather than embedding an entire algorithm library in their application. Cloudflare says Workers implements the new algorithms through its open-source workerd runtime and BoringSSL primitives, with additional Web Platform Tests and Workers-specific tests covering the new API behavior.

The biggest limitation is that this is still a moving web API

Cloudflare's implementation is a subset of an evolving Modern Algorithms proposal rather than a completed Web Crypto standard. The current Workers support therefore should not be treated as if every browser or JavaScript runtime already understands the same algorithm names and methods. Cloudflare explicitly warns that the API can change as the draft develops, which is why the compatibility flag exists in the first place.

That portability problem is significant for libraries. A package intended to run across Workers, browsers, Node.js and other JavaScript environments cannot simply assume that ML-KEM-768 or ML-DSA-44 exists everywhere. Capability detection becomes part of the design, and Cloudflare's addition of SubtleCrypto.supports() is aimed at precisely that problem. A library can check what the current runtime provides instead of discovering support only after a cryptographic operation fails.

Cloudflare is not implementing the whole proposal yet

The missing pieces show why this release should be viewed as a foundation rather than a finished post-quantum toolkit. Cloudflare says the initial implementation does not include other algorithms and constructions from the broader proposal, including SHA-3, cSHAKE, TurboSHAKE, ChaCha20-Poly1305 and Hybrid Public Key Encryption, or HPKE. Those omissions do not make ML-KEM and ML-DSA unusable, but they mean developers still need to assemble higher-level protocols carefully rather than assuming the new Web Crypto methods provide an entire secure messaging or transport protocol by themselves.

There is also a compatibility gap inside the ML-KEM family itself. Workers supports ML-KEM-768 and ML-KEM-1024, but not ML-KEM-512 because the version of BoringSSL used by Workers does not expose that variant. The difference is worth understanding because ML-KEM-512 is part of the NIST standard, so “Workers supports ML-KEM” does not mean that every standardized parameter set is available.

The larger issue is the size cost of post-quantum cryptography

Replacing an older cryptographic primitive is not only a question of whether the mathematics is secure. The data produced by the new algorithms can also be larger, and that affects protocols, stored keys, certificates, signatures and network messages. Cloudflare specifically notes that ML-DSA public keys and signatures are substantially larger than those produced by RSA or Ed25519. Native runtime support can reduce implementation overhead, but it cannot make those larger cryptographic objects disappear.

This is where post-quantum migration becomes an engineering problem rather than a simple security upgrade. A protocol may have to carry larger authentication data, store different key formats and account for clients that do not yet support the new primitives. The Web Crypto interface can make the algorithm available, but applications still have to decide how and where those primitives fit into an actual protocol.

Why the timing matters before quantum computers arrive

NIST's post-quantum standards are designed around the possibility that sufficiently capable quantum computers could threaten widely used public-key cryptography. ML-KEM addresses key establishment, while ML-DSA addresses digital signatures, giving developers standardized alternatives for two major jobs currently handled by conventional public-key systems.

The web standards community is also moving toward a broader cryptographic API that can accommodate evolving algorithms without forcing every application to invent its own interface. The current Web Cryptography Level 2 work remains a draft, and its purpose is to provide a common API for cryptographic operations rather than mandate that every implementation support every algorithm.

That makes Cloudflare's choice to keep the modern algorithms behind a compatibility flag sensible for this stage of the work. Developers can begin testing real libraries and protocols while the specification and implementation details continue to change. The useful milestone is not that Workers has suddenly become fully post-quantum; it is that one of the web's widely used cryptographic interfaces now has a practical place where developers can start finding the problems before those algorithms become unavoidable.

What developers can actually do with the new support

A Worker developer can enable the webcrypto_modern_algorithms compatibility flag and generate an ML-KEM or ML-DSA key pair through the familiar Web Crypto interface. With ML-KEM, the public key can be used to encapsulate shared key material while the private key performs decapsulation; with ML-DSA, a private key can sign data and the public key can verify the signature. Cloudflare's own examples demonstrate these operations, but the company stresses that the snippets are cryptographic building blocks rather than complete protocols.

For production applications, that distinction should guide the next step. A developer should first establish whether the target clients and other services support the same primitives, then test the complete protocol rather than only testing whether a key pair can be generated. The compatibility flag also means teams should avoid treating the current API surface as permanently frozen. Cloudflare is explicitly asking library authors to exercise the implementation and expose the rough edges before the interface is treated as stable.

The next step is interoperability, not simply more algorithms

The important question now is whether libraries and protocols can use these primitives consistently across the environments where web applications actually run. Cloudflare has supplied the low-level pieces, but browsers, runtimes, protocol libraries and application developers still need to converge on interoperable ways to use them. The presence of standardized ML-KEM and ML-DSA algorithms makes that work more concrete, while the draft status of the Web Crypto additions leaves room for changes before they become ordinary web-platform assumptions.

For now, the new Workers support is best understood as an early bridge between established web cryptography and the post-quantum standards already being developed outside the browser stack. It gives developers something they can test today without pretending that the migration is finished. The next meaningful milestone will be seeing those primitives move from compatibility flags and experiments into interoperable protocols that can survive across the wider web.