November 4, 2026
authentik’s November 3 roadmap assigns ML-DSA support for certificates, OIDC signatures and WebAuthn to version 2026.11. Hybrid X25519MLKEM768 TLS key exchange has already shipped.
At our November 4 check, GitHub’s release list still marked 2026.8.5, released October 21, as Latest. Treat the signature features as planned capabilities.
Separate the cryptographic jobs
NIST’s ML-DSA standard concerns signatures: detecting changed data and authenticating its signer. NIST considers it resistant to attacks using large quantum computers. Applying a signature does not encrypt the signed content.
Key exchange needs its own check. Go 1.24’s TLS documentation describes X25519MLKEM768 as enabled by default, but configuration can change that. It also records handshake timeouts with servers that mishandle larger records. Our recommendation: inspect the negotiated connection through your real proxy path, including older clients.
The dependencies behind a successful login
Certificates target controlled deployments: outposts verifying these certificates need 2026.11 or newer; public certificate authorities and browsers do not yet support these certificates; authentik’s FIPS mode blocks ML-DSA key generation pending a suitable validated module.
Yubico offers an evaluation beta covering ML-DSA passkeys, explicitly excluding production use.
WebAuthn’s algorithm selection depends on client and authenticator support. Our takeaway: authentik’s planned server acceptance still requires a compatible end-to-end combination.
RFC 9881 defines ML-DSA usage in X.509 certificates and revocation lists. Our implementation takeaway: track certificate format support, verification support and the intended trust chain separately. A format specification alone cannot establish whether a particular client will accept your certificate.
RFC 9964 defines ML-DSA representations for JOSE and COSE, including algorithm identifiers and keys. Our recommendation is to inventory every token validator, its library version and its accepted algorithms. The smallest ML-DSA signature is 2,420 bytes before text encoding. Include complete token size and intermediary header limits in staging checks.
authentik specifically requires compatible JWT libraries before switching token signing.
OpenSSL’s provider documentation warns that some releases lack a validated FIPS provider. For constrained deployments, verify the exact module and version rather than treating an algorithm’s standardization as proof of module validation.
Make the first change small and reversible
Our operational recommendation is to prepare a staging exercise before changing production sign-in settings:
- Draw the path: browser, edge proxy, identity service, outposts and applications. Give each connection and token consumer an owner.
- Define acceptance: successful sign-in, expected rejection of invalid tokens, key rotation and a documented rollback procedure.
- Keep evidence: record versions, configurations and observed results. Mark untested combinations explicitly instead of extending one successful test to the whole estate.