How authentik is handling post-quantum cryptography

· 17 min read
Connor Peshek
Connor Peshek
Fun-end Developer and DevRel at Authentik Security Inc

authentik is an open source Identity Provider that unifies your identity needs into a single platform, replacing Okta, Keycloak, and Ping. Authentik Security is a public benefit company building on top of the open source authentik project.

Post-quantum cryptography has been getting a lot of attention lately, and most of it is either very academic or very vague. This post is the version for people who run an identity provider: what post-quantum cryptography is, why preparing now matters even before quantum computers become a practical threat, what the government compliance requirements say, and what authentik supports now and what's coming. At the end there's a longer look at where the standards are for anyone who wants it.

A large enough quantum computer would break the public-key cryptography behind every login, token and certificate an identity provider hands out. The replacements for those algorithms are standardized now, and they've started showing up in browsers, TLS libraries and compliance deadlines.

authentik has been using the X25519MLKEM768 hybrid key exchange in its TLS stack for a while. Starting with version 2026.11, authentik can also generate and store ML-DSA certificates, accept ML-DSA passkeys, and sign and verify OIDC tokens with ML-DSA. If those names don't mean anything to you yet, that's fine. The next section explains what they are, and the rest of the post covers what each one does for you and when.

What is post-quantum cryptography?​

Post-quantum cryptography (PQC) is a new generation of asymmetric cryptographic algorithms designed to resist attacks from quantum computers. It isn't a third category alongside symmetric and asymmetric cryptography. Instead, it provides quantum-resistant alternatives to the asymmetric algorithms used for key exchange and digital signatures, while existing symmetric encryption can largely remain unchanged.

Symmetric keys are what you use for encryption. AES is the common example. A quantum computer running Grover's algorithm can, on paper, halve the effective key length of a symmetric cipher, and early post-quantum guidance told everyone to double their key sizes because of it. That advice has softened since. Grover needs a long run of sequential steps that doesn't parallelize well, so NIST still considers AES-128 safe against known quantum attacks. CNSA 2.0 requires AES-256 for national security systems anyway, which makes it the safer default if you have to pick one.

Asymmetric keys are what you use for sending a symmetric key to the other side, for key agreement in a handshake, and for signing things like certificates, tokens and passkey assertions. RSA, elliptic curves and Diffie-Hellman all rest on math problems that are easy to do forwards and hard to do backwards, and a large enough quantum computer running Shor's algorithm does the backwards part quickly.

The replacements that NIST has standardized are ML-KEM for key exchange and ML-DSA for signatures, with SLH-DSA and FN-DSA as alternatives for signatures that we'll get to at the end. For key exchange they're usually deployed as hybrids, where classical and post-quantum algorithms run side by side so an attacker has to break both. That's what the X25519MLKEM768 in the intro is: X25519, which you've been using for years, next to ML-KEM-768.

Quantum computers aren't here yet, should I wait?​

No. Even if quantum computers are still years away, waiting carries risks today. There are two reasons to start preparing now.

Harvest now, decrypt later. An attacker can record encrypted traffic today and store it until quantum computers become powerful enough to decrypt it. By breaking the asymmetric cryptography used during the initial key exchange, they could recover the session keys and decrypt everything they captured. The symmetric encryption itself isn't broken; it's bypassed because the key exchange is no longer secure. This means sensitive data transmitted today using methods like RSA or ECDH key exchange could be exposed years or even decades later.

Compliance. Governments are already setting deadlines for migrating to post-quantum cryptography. The US set federal migration requirements in 2022 and moved the deadlines up in 2026, the EU published its roadmap in 2025, and the NSA has stricter requirements for national security systems. If your customers include government agencies, contractors, or other organizations subject to these requirements, they'll expect your identity provider to be ready. The next section breaks down those requirements.

What the compliance requirements say​

Most of the dates that matter come from a handful of US federal documents, and if you sell to the federal government, or to a state agency or contractor that follows federal guidance, these are the terms that show up in security questionnaires:

  • NSM-10 (National Security Memorandum 10, May 2022) is where it started. It sets the goal of mitigating as much quantum risk as feasible by 2035 and told agencies to start inventorying their cryptography.
  • OMB M-23-02 (November 2022) turned that into a requirement. Every federal agency has to keep an inventory of systems that use quantum-vulnerable cryptography and update it every year. An identity provider is on that inventory.
  • The Quantum Computing Cybersecurity Preparedness Act (Public Law 117-260, December 2022) put it into law and requires OMB to prioritize migrating federal IT systems to post-quantum cryptography.
  • CNSA 2.0 (September 2022) is the NSA's suite for national security systems. It wants post-quantum algorithms preferred now, web servers and cloud services on them exclusively by 2033, everything by 2035. It specifies ML-KEM-1024, ML-DSA-87, AES-256 and SHA-384 or SHA-512.
  • NIST IR 8547 sets the deprecation schedule for everyone else: RSA, ECDSA, EdDSA and ECDH are deprecated after 2030 and disallowed after 2035.
  • Executive Order 14144 (January 2025) and Executive Order 14306 (June 2025) kept the post-quantum work going across administrations, though EO 14306 dropped the original requirement to put post-quantum cryptography in procurement solicitations. They require agencies to support TLS 1.3 by January 2030 and told CISA to publish a list of product categories where post-quantum capable products are widely available.
  • CISA's product categories list (January 2026) is that list. Browsers, web servers, cloud platforms and endpoint security are marked as widely available, which means agencies should only buy post-quantum capable products in those categories from now on. Identity, Credential, and Access Management (ICAM) software, which is what an identity provider is, is in the "transitioning" table, where CISA encourages vendors to implement and test post-quantum capabilities now. We expect ICAM to move to the widely available list, and when it does, agencies will be required to buy post-quantum capable identity providers.

Outside the US, the EU's coordinated roadmap asks member states to have a national transition plan started by the end of 2026, high-risk systems moved by the end of 2030, and medium-risk systems moved by the end of 2035 with low-risk ones done as far as feasible, and Germany's BSI and France's ANSSI both recommend hybrid signatures during the migration.

There's one piece of this that's awkward right now, which is FIPS 140-3. FedRAMP and most federal deployments require FIPS 140-3 validated cryptographic modules, and the validated OpenSSL FIPS provider doesn't implement ML-DSA yet. That's why ML-DSA key generation in authentik is unavailable when FIPS compliance mode is turned on. We'll lift that restriction as soon as a validated module includes it.

2030 sounds far away, but certificate rotations, library upgrades and getting every application in an organization onto a new signature algorithm is the kind of thing that takes years, so it's better to have the pieces in place early.

What is authentik doing about it?​

Key exchange was the first thing the industry moved, because it's the one that closes the harvest now, decrypt later problem. Chrome, Firefox, OpenSSL, Go and OpenSSH all turned on hybrid post-quantum key exchange by default over the last couple of years, and if you opened this page in a current browser the session key was most likely agreed with X25519MLKEM768 without you noticing. It was the first thing we moved too.

Already shipped: post-quantum key exchange​

authentik's TLS stack uses the X25519MLKEM768 hybrid key exchange in the server, the outposts and the embedded proxy. Traffic to and from authentik is already protected against harvest now, decrypt later, and has been for a while.

In 2026.11: post-quantum signatures​

This release moves signatures, which is the other half of the problem. It adds ML-DSA in three places, certificates, OIDC tokens and passkeys, and it raises the default symmetric encryption for SAML.

ML-DSA certificates. authentik generates and stores ML-DSA-44, ML-DSA-65 and ML-DSA-87 certificates right next to the RSA, ECDSA, Ed25519 and Ed448 ones you can already create. These are for TLS between components you control, so outposts, mutual TLS against a private certificate authority, and RADIUS with EAP-TLS 1.3. Outposts need to be on 2026.11 or newer to verify them. Public certificate authorities and browsers don't accept ML-DSA certificates yet, so this isn't for your public login page. As mentioned above, generating ML-DSA keys doesn't work with FIPS compliance mode turned on until a validated module includes ML-DSA.

ML-DSA for OIDC. This is the part that gets the actual logins onto post-quantum signatures. OAuth2 providers can sign ID tokens, access tokens and client assertions with an ML-DSA certificate, the proxy outpost and OAuth sources verify ML-DSA signed tokens (so authentik can federate with an upstream IdP that signs with ML-DSA), and DPoP proofs can be bound to ML-DSA keys. Applications that validate tokens themselves need a JWT library that understands ML-DSA before you switch a provider over, so check that first.

ML-DSA passkeys. WebAuthn registration and login accept ML-DSA credentials. No shipping authenticator supports ML-DSA yet, and some browsers throw an error if you suggest an algorithm they don't know, so we put it at the bottom of the list of accepted algorithms. In practice that means only an authenticator that offers nothing else will use it, which is fine for now. The point is to have it in place and tested before those authenticators show up.

AES-256-GCM for SAML. This is the symmetric side of the story from earlier. AES-128 isn't broken by a quantum computer, but Grover's algorithm eats into its safety margin and CNSA 2.0 requires AES-256. Moving to 256 bits costs nothing, so we did. You can now pick the assertion encryption algorithm on SAML and WS-Federation providers, and new providers default to AES-256-GCM. Existing providers keep AES-128-CBC until you change them, so it's worth a look. SAML sources now tell the upstream IdP to use AES-256-GCM too.

Waiting on the specs: SAML signing and ML-KEM encryption​

Two pieces are left, and both are blocked on standards rather than on us. SAML signing with ML-DSA will follow once XML Signature publishes an algorithm identifier for it, which is the one thing keeping SAML behind OIDC. Post-quantum encryption is further out on both protocols: encrypting OIDC tokens and SAML assertions needs ML-KEM, and neither JOSE nor XML Encryption has defined how to carry it yet. We'd rather wait for those than ship something that has to change when the spec lands.

Where that leaves authentik​

Put against the requirements from the previous section:

  • Harvest now, decrypt later. Closed by X25519MLKEM768, which is already on everywhere authentik terminates TLS.
  • TLS 1.3 by 2030 (EO 14144 and 14306). The server, the outposts and the embedded proxy all speak TLS 1.3 today, and ML-DSA certificates require it anyway.
  • AES-256 (CNSA 2.0). New SAML and WS-Federation providers default to AES-256-GCM in 2026.11, and SAML sources ask the upstream IdP for it.
  • RSA and ECDSA deprecated after 2030 (NIST IR 8547). ML-DSA certificates and ML-DSA token signing in 2026.11 get the parts you control onto post-quantum signatures well ahead of that date. SAML signing follows when XML Signature does.
  • Cryptographic inventories (OMB M-23-02). Every certificate in authentik shows its key type in the admin interface and the API, and you can filter by it, so finding what's still RSA or ECDSA is a filter rather than a project.
  • CISA's ICAM "transitioning" category. What CISA asks of identity vendors right now is to implement and test post-quantum capabilities, which is what the ML-DSA certificate, WebAuthn and OIDC work in 2026.11 is. When ICAM moves to the widely available list, we want to already be there.
  • FIPS 140-3 and FedRAMP. authentik's FIPS compliance mode is unchanged, with the one caveat that ML-DSA key generation waits on a validated module.

That covers what's shipping and when. The rest of this post is for anyone who wants to know what's behind the algorithm names above, which ones are usable right now, and what's still moving.

The state of post-quantum cryptography​

The NIST standards​

NIST finalized three standards in August 2024 and has a fourth in draft:

AlgorithmStandardJobBasisStatus
ML-KEMFIPS 203Key encapsulation, replaces ECDH and RSA key transportLatticeFinal
ML-DSAFIPS 204Signing, replaces RSA, ECDSA and EdDSALatticeFinal
SLH-DSAFIPS 205Signing, conservative backup to ML-DSAHashFinal
FN-DSAFIPS 206Signing, compact signatures for constrained environmentsLatticeDraft, final expected late 2026 or early 2027

ML-KEM is the only one of the four that does key exchange. The other three are all signatures, and the reason there are three of them comes down to the "Basis" column. To see why that column matters, it helps to look at what the old algorithms were built on and how that went wrong.

What's broken and what isn't​

Every public-key algorithm rests on a math problem that's easy in one direction and hard in the other. RSA rests on integer factoring: multiply two big primes and nobody can get them back out of the product. Diffie-Hellman, DSA and elliptic curves (ECDH, ECDSA, Ed25519, X25519) rest on the discrete logarithm problem: raise something to a secret power, or multiply a curve point by a secret number, and nobody can recover the secret from the result. On a classical computer, both problems take longer than the age of the universe at today's key sizes.

Shor's algorithm solves both of them in polynomial time on a large enough quantum computer. It doesn't care whether the key is RSA-4096 or Ed25519, and bigger keys only make it slower, not meaningfully harder. Once such a machine exists, every classical public-key algorithm in use today is broken at the same time. The only fix is to move to a problem that Shor doesn't solve, and the post-quantum standards use two of them.

Lattice-based schemes (ML-KEM, ML-DSA and FN-DSA) rest on finding short vectors in a high-dimensional lattice, which neither classical nor known quantum algorithms are much good at. They're fast, often faster than RSA, their keys and signatures are a few kilobytes, and the family can do both signing and key exchange, which is why ML-KEM and ML-DSA are what everyone is deploying first. The catch is that they're harder to implement correctly. Timing side channels, rejection sampling bugs and, in FN-DSA, constant-time floating-point math have all caused problems in shipping code.

Hash-based schemes (SLH-DSA) rest on one assumption, which is that you can't invert the hash function. That's the same assumption every use of SHA-2 already makes, which makes SLH-DSA the most conservative option with very few implementation hazards. The cost is that it's slow, the signatures are big, and it can only sign. It can't encrypt or exchange keys.

NIST standardized one of each on purpose. RSA and elliptic curves fell to the same attack because they share the same kind of math, and every lattice scheme shares the same math too, so a new attack on lattices would weaken ML-KEM, ML-DSA and FN-DSA together. SLH-DSA shares none of it and would be fine.

What you can use today​

Of the four, ML-KEM and ML-DSA are the only two that are usable in production right now. ML-KEM is the one already in your browser, and ML-DSA has a final X.509 standard and is showing up in TLS libraries and certificate tooling.

SLH-DSA is a final standard, but library and protocol support is thin enough that most stacks can't use it yet. FN-DSA, which used to be called Falcon, is still a draft with no widely used implementation. Its signatures are the smallest of the group at roughly 0.7 KB to 1.3 KB, which matters for embedded devices and size-constrained protocols like DNSSEC, so expect it to show up in those places first.

Where the protocol specs stand​

The algorithms themselves are mostly settled. The protocol layer above them, which is what decides when each part of an identity provider can switch, is a mix of finished and still moving:

  • X.509 is done. ML-DSA has its certificate identifier in RFC 9881, which is why certificates are the first thing we're shipping.
  • JOSE and COSE, which carry OIDC tokens and WebAuthn assertions, are done for signing. They got their ML-DSA signature identifiers in RFC 9964 in May 2026. That covers signing only, and it's what the ML-DSA passkey support and OIDC token signing in 2026.11 build on. Encrypting tokens with ML-KEM is a separate draft that hasn't landed.
  • XML Signature and XML Encryption, which SAML depends on, are not done. Neither has anything published yet, which is why SAML is last on our list.
  • Composite ML-DSA is not done either. It pairs an ML-DSA key with a classical key in one certificate so a verifier has to check both, and it's still an IETF draft. Germany's BSI and France's ANSSI both recommend hybrid signatures during the migration, so we expect composite certificates to become the common form once that draft is final, and we'll support it when it is.

That's why the roadmap above is ordered the way it is. Each piece ships as soon as its spec is settled enough to build on, and we're shipping as quickly as those specs allow, keeping up with new standards as they emerge and staying at the forefront of post-quantum adoption.

If you have questions about any of this, or you're running into something in your own post-quantum migration, you can find us on GitHub and Discord.

Learn more​