Your browser went quantum-safe two years ago. Your signatures are only now catching up

Open any major website in a current browser and look at the handshake. There is a good chance the session key was agreed with X25519MLKEM768: a classical elliptic-curve exchange running next to ML-KEM-768, the lattice-based key encapsulation mechanism NIST standardized in FIPS 203. Nobody announced it with a banner. Chrome, Firefox, OpenSSL and OpenSSH just turned it on, and the internet kept working.

That was the first half of the post-quantum migration, and it moved first for a simple reason. Key exchange is the part an attacker can exploit retroactively. Record encrypted traffic today, store it, and decrypt it years from now when a large enough quantum computer exists. That is the harvest now, decrypt later threat, and it is the reason NIST's final transition report, IR 8547, published on October 27, 2026, treats key exchange as the urgent half.

The second half is signatures, and it is only now starting to ship in real software.

Why signatures lagged behind

A signature does a different job from a key exchange. It proves that a certificate, a token, a login, a passkey assertion or a software update really came from who it claims to come from. A forgery is only useful while the verifier still trusts the key, so there is no harvest now, decrypt later pressure on signatures. Nobody rushes to replace something that only breaks in the future.

The real blocker was size. An Ed25519 signature is 64 bytes. An ML-DSA-65 signature is about 3.3 kilobytes, and its public key is close to 2 kilobytes. Put that in every certificate in a TLS chain, every JSON Web Token, every passkey assertion, and everything gets fat. Handshakes grow, tokens grow, and the protocols that carry them were never designed for signatures that big.

That is why, two years after NIST finalized ML-DSA in FIPS 204, no browser-trusted certificate authority issues ML-DSA certificates yet, and no browser accepts one. The standards exist: RFC 9881, published in October 2025, defines ML-DSA in X.509 certificates, and RFC 9935, from March 2026, does the same for ML-KEM keys. The plumbing is there. The public trust part is not.

What actually shipped this month

On November 3, authentik, the open source identity provider, shipped version 2026.11, and it is the clearest example I have seen of the signature half moving from roadmap to release. It adds ML-DSA in three places:

First, certificates. It can generate and store ML-DSA-44, ML-DSA-65 and ML-DSA-87 certificates next to the RSA, ECDSA and Ed25519 ones it already supports. These are for the parts you control: TLS between your own components, mutual TLS against a private certificate authority, and RADIUS with EAP-TLS 1.3. They are explicitly not for your public login page, because public CAs and browsers do not accept them yet.

Second, OIDC tokens. OAuth2 providers can now sign ID tokens, access tokens and client assertions with an ML-DSA certificate, and the proxy outposts verify ML-DSA signed tokens from upstream identity providers. This is the part that puts actual logins onto post-quantum signatures. The honest catch, which authentik states plainly: applications that validate tokens themselves need a JWT library that understands ML-DSA before you switch a provider over. Check that first.

Third, passkeys. WebAuthn registration and login accept ML-DSA credentials. No shipping authenticator supports ML-DSA yet, and some browsers error if you suggest an algorithm they do not know, so authentik puts ML-DSA at the bottom of the accepted list. Only an authenticator that offers nothing else will use it. That sounds useless until you think about it the other way: the support is in place and tested before the hardware shows up, instead of after.

The same release raises the default symmetric encryption for SAML to AES-256-GCM. AES-128 is not broken by a quantum computer, but Grover's algorithm eats into its safety margin, and the NSA's CNSA 2.0 suite requires AES-256 for national security systems. Moving to 256 bits costs nothing, so they did it.

And the release is equally honest about what is still blocked. ML-DSA key generation does not work when authentik's FIPS compliance mode is on, because the validated OpenSSL FIPS provider does not implement ML-DSA yet. SAML signing waits on XML Signature publishing an algorithm identifier for ML-DSA. Encrypting OIDC tokens and SAML assertions with ML-KEM waits on JOSE and XML Encryption defining how to carry it. Those are standards gaps, not code gaps, and the team chose to wait for the specs rather than ship something that has to change when they land.

The certificate problem has a candidate answer

The size problem has one serious proposal. On September 29, Cloudflare announced it intends to become a public certificate authority, acquiring publicly trusted root CA key material from GlobalSign, and said production issuance of a new certificate type, Merkle Tree Certificates, is scheduled for the first quarter of 2027.

The idea is straightforward. Instead of a CA signing every certificate individually with a large post-quantum signature, it signs a batch of certificates once, as a Merkle tree. A server then presents an inclusion proof instead of a full signature chain. The draft, draft-ietf-plants-merkle-tree-certs, was at revision 08 on November 2, 2026. It is still a draft, not an RFC, and Cloudflare's applications to the Chrome, Apple, Microsoft and Mozilla root programs are pending. Nothing is approved. But it is the first concrete plan for how public post-quantum certificates could work at internet scale, and the date on it is next quarter, not next decade.

What I learned putting ML-DSA in my own messenger

I have a small stake in this half of the migration. In my own end-to-end encrypted messenger, I put ML-DSA-65 identity signatures in before anything else, in October 2026. The key exchange was already a hybrid of ML-KEM-768 and X25519, so the handshake was covered. The identity key was the part users actually compare when they verify each other, the safety number, so that was the signature that mattered most.

The practical lesson was the same one authentik hit: size decides where a signature belongs. A 3.3 kilobyte signature is fine for an identity key you exchange once and then trust for months. It is a bad fit for signing every message, which is why you sign keys, not messages, and let the ratchet do the per-message work. If you are designing a protocol and you reach for ML-DSA, ask first how often the signature travels. Once per session is free. Once per message is a tax your users pay on every send.

The other lesson is about honesty in what a signature proves. My safety numbers cover the ML-DSA identity key directly. The exchange key is covered only indirectly, on the outgoing path. A signature is a claim about one specific key, not a blanket guarantee about the whole system, and anyone building with ML-DSA should say exactly which key their signatures cover.

What to do now

The deadlines are published and they are not close enough to ignore. NIST IR 8547 deprecates RSA, ECDSA, EdDSA and elliptic-curve Diffie-Hellman after 2030 and disallows them after 2035. The EU roadmap asks member states to have national transition plans started by the end of 2026. CISA's January 2026 product categories list marks browsers, web servers and cloud platforms as widely available for post-quantum capable products, which means federal buyers should only buy capable products in those categories from now on. Identity software sits in the transitioning table, where CISA encourages vendors to implement and test now.

If you run an identity provider, an internal CA, or a service that signs tokens, the work this year is unglamorous and specific: inventory every certificate and signing key by algorithm, the way authentik now lets you filter by key type in its admin interface; put ML-DSA support in place where you control both ends, internal TLS, mutual TLS, service-to-service tokens; check your JWT libraries before you switch any public-facing provider; and keep Ed25519 where size still rules, on constrained devices, until FN-DSA, the compact lattice signature NIST expects to finalize in late 2026 or early 2027, is ready.

Key exchange was the urgent half, and it shipped quietly while nobody was looking. Signatures are the slow half, and the slow half is finally moving in real releases with real limits stated on the page. That is what progress looks like here: not a flag day, but one identity provider, one certificate format, one token at a time.

Sources: authentik blog, "How authentik is handling post-quantum cryptography" (November 3, 2026); NIST IR 8547, "Transition to Post-Quantum Cryptography Standards" (final, October 27, 2026); Cloudflare press release on its public CA plans and Merkle Tree Certificates (September 29, 2026); RFC 9881 and RFC 9935.