Cloudflare Workers: ML-KEM and ML-DSA support in Web Crypto, behind a flag

Cloudflare has added opt-in support for post-quantum algorithms to Web Crypto on Workers. Developers writing code on Workers who want to start testing the post-quantum transition no longer need to bring along a separate cryptographic implementation in JavaScript or WebAssembly: they can now use the native primitives exposed by the runtime.

What actually changes

Cloudflare Workers is adding support for quantum-resistant algorithms within Web Crypto, aimed at developers preparing for the post-quantum transition: opt-in APIs that make it easier to experiment with ML-KEM and ML-DSA without having to include a separate cryptographic implementation. Cloudflare makes clear that this isn't a complete migration path, but rather basic building blocks that can be used to validate an integration.

The official changelog confirms it: the Workers Web Crypto API now supports ML-KEM-768, ML-KEM-1024, ML-DSA-44, ML-DSA-65 and ML-DSA-87. ML-KEM establishes shared secrets, while ML-DSA signs and verifies data.

To enable the new APIs, simply add the flag to your configuration file:

{
 "$schema": "./node_modules/wrangler/config-schema.json",
 "compatibility_flags": [
 "webcrypto_modern_algorithms"
 ]
}

Cloudflare's technical documentation provides a compatibility table by algorithm and operation: ML-DSA-44/65/87 support sign/verify, generateKey, exportKey and importKey; ML-KEM-768/1024 support encapsulate/decapsulate operations as well as generateKey, exportKey and importKey. ML-KEM-512, on the other hand, is not supported for any of the listed operations. The source notes that without these APIs, developers building on Workers could still experiment with post-quantum code, but had to bring their own separate implementation.

Where the limits currently lie

The flag only covers a subset of the broader draft specification. It enables the Workers subset of the evolving Modern Algorithms in the Web Cryptography API proposal, which includes ML-KEM and ML-DSA, the key encapsulation and decapsulation methods, getPublicKey() and SubtleCrypto.supports(), and JSON Web Keys (JWK) with the AKP key type. Still missing, for now, are SHA-3, ChaCha20-Poly1305, cSHAKE, TurboSHAKE and direct HPKE support: anyone who needs these will still have to bundle them in.

For those running Workers-based services that touch on JWT signing, tokens or key exchanges, now is the time to start testing in a non-production environment, checking behaviour with the flag enabled before considering wider adoption.

No Prime Software products are involved in this story.