up:: In the Protocols MOC

PQC in Kerberos and Active Directory

PQC in Kerberos and Active Directory is the post-quantum migration question for the protocol that authenticates most enterprise Windows environments, and the answer splits sharply in two: the symmetric core of Kerberos, which encrypts tickets with AES keys, is largely quantum-resistant because Grover’s algorithm only weakens symmetric encryption modestly, while the public-key surfaces bolted onto it, chiefly PKINIT certificate-based pre-authentication and the certificate authority that issues those certificates, are broken by Shor’s algorithm like any other RSA or elliptic-curve deployment. So the quantum work in an Active Directory estate is finding and migrating the certificate-based edges and the PKI underneath them, which Microsoft’s Windows post-quantum roadmap is now adding support for.

The short version:

1. Kerberos is symmetric at its core. Tickets are encrypted with symmetric keys, and a modern deployment uses AES-256, which keeps a strong margin against Grover.
2. That symmetric core is a strengthen-in-place item, not a replace item. Grover against AES-256 leaves an effective 128-bit security level, which is comfortable, so the base protocol doesn’t need a new algorithm.
3. The exposed surface is public-key. PKINIT (RFC 4556) adds certificate-based pre-authentication using RSA and Diffie-Hellman, and those are exactly what Shor’s algorithm breaks.
4. The PKI behind it inherits the risk. Active Directory Certificate Services issues the certificates PKINIT and smart-card logon rely on, so the CA and its whole chain are quantum-vulnerable public-key surfaces.
5. Microsoft is shipping the pieces. ML-KEM and ML-DSA are now available in Windows Server 2025 and Windows 11, and AD Certificate Services supports the ML-DSA parameter sets, so the migration is issuing post-quantum certificates rather than reinventing Kerberos.

Picture a bank vault whose door is a heavy combination lock, and next to it a guard who checks a photo ID before letting anyone near the door. The combination lock is the symmetric core, and a quantum computer barely dents it, so the vault door itself stays strong. The weak point is the ID the guard trusts. Those IDs are printed and signed by a machine (RSA and elliptic-curve signatures) that a quantum computer can forge, so instead of cracking the vault an attacker walks up with a perfect fake ID the guard accepts. The migration replaces the ID-signing machine with one whose signatures can’t be forged, and leaves the vault door alone.

What is Kerberos and how does Active Directory use it?

Kerberos is a network authentication protocol that lets a user prove their identity to services across an untrusted network using a trusted third party, and it’s the default authentication protocol for Windows domains, which is where Active Directory comes in. The trusted third party is the Key Distribution Center (KDC), and in a Windows environment the domain controllers running Active Directory are the KDC.

The flow, in brief, is that a user authenticates once to the KDC and receives a ticket-granting ticket, then presents that ticket to get service tickets for the specific resources they access, so they don’t re-authenticate to every service. Active Directory builds its entire domain logon, service access, and single-sign-on model on this, which is why Kerberos sits at the center of enterprise Windows security. The base protocol is specified in RFC 4120.

Source: IETF, “The Kerberos Network Authentication Service (V5),” RFC 4120, July 2005, RFC 4120.

The reason Kerberos matters for quantum planning is its blast radius. It authenticates a huge share of enterprise access, so its cryptography is load-bearing across the whole estate, and understanding exactly which parts are quantum-exposed is what keeps the migration focused on the right edges instead of a costly rebuild of something that’s already resistant.

Why is the Kerberos core largely quantum-resistant?

Because Kerberos authenticates using symmetric-key cryptography, and symmetric encryption stays standing under quantum attack with only a modest reduction in strength. RFC 4120 states that Kerberos performs authentication using conventional (shared secret key) cryptography, meaning tickets and the session keys inside them are encrypted with symmetric keys shared between the principals and the KDC. A modern deployment uses AES for that encryption, per RFC 3962.

The quantum threat to symmetric encryption is Grover’s algorithm, which speeds up brute-force key search quadratically. Against AES-256 that turns a 256-bit search into an effective 128-bit one, and 128 bits of security is a comfortable margin that no foreseeable machine reaches, which is the whole argument in Grover against AES. So the symmetric heart of Kerberos is a strengthen-in-place surface: make sure it’s using AES-256 rather than a legacy cipher like RC4, and it needs no new algorithm.

Source: IETF, “The Kerberos Network Authentication Service (V5),” RFC 4120, §1, July 2005, RFC 4120, for Kerberos resting on shared-secret cryptography: it “performs authentication under these conditions as a trusted third-party authentication service by using conventional (shared secret key) cryptography.” RFC 4120 does not mention quantum computing or Grover’s algorithm, and its single mention of RC4 classifies enctypes rather than deprecating any.

Source: IETF, “Advanced Encryption Standard (AES) Encryption for Kerberos 5,” RFC 3962, February 2005, RFC 3962, for the AES enctypes aes128-cts-hmac-sha1-96 (17) and aes256-cts-hmac-sha1-96 (18).

Source: NIST, “Report on Post-Quantum Cryptography,” NISTIR 8105, April 2016, §2, NISTIR 8105, for Grover’s quadratic speedup and the doubling remedy: “Grover’s algorithm provides a quadratic speed-up for quantum search algorithms,” and “if it is, doubling the key size will be sufficient to preserve security.” The preference for AES-256 over legacy Kerberos enctypes is the Guide’s own recommendation; see Grover on AES.

This is the reassuring half of the picture and the part people miss when they assume “quantum breaks Kerberos.” The password-derived and ticket-encrypting symmetric keys are the resistant part. The exposure comes entirely from the public-key machinery layered on top for certificate and smart-card authentication.

Where is Kerberos actually quantum-vulnerable?

The vulnerable surface is PKINIT, the extension that adds public-key cryptography to Kerberos’s initial authentication, because PKINIT uses RSA and Diffie-Hellman, and both are broken by Shor’s algorithm. Password-based Kerberos derives the user’s key from a password and stays symmetric, but certificate-based and smart-card logon go through PKINIT instead, and that’s where asymmetric cryptography enters.

1. PKINIT pre-authentication (RFC 4556). PKINIT lets a client authenticate with an X.509 certificate and its private key instead of a password. The client signs pre-authentication data, and the exchange establishes a key using either Diffie-Hellman or RSA key transport. Both the signature and the key establishment are classical public-key operations that a quantum computer defeats.
2. Smart-card and certificate logon. Windows smart-card logon is built on PKINIT, so every smart-card authentication is a certificate-based, quantum-vulnerable exchange.
3. The certificate authority behind it. In a Windows estate the certificates PKINIT trusts are issued by Active Directory Certificate Services, and a CA deployed before its May 2026 ML-DSA support signs with classical public-key algorithms, so the entire CA hierarchy is a quantum-exposed PKI.

Source: IETF, “Public Key Cryptography for Initial Authentication in Kerberos (PKINIT),” RFC 4556, June 2006, RFC 4556, for the X.509 and RSA/Diffie-Hellman pre-authentication, which it specifies with rsaEncryption and RSAES-PKCS1-v1_5. RFC 4556 mentions neither Active Directory Certificate Services nor elliptic curves; for ADCS as the enterprise PKI issuing those certificates, and its May 2026 ML-DSA support, Microsoft, “New Windows Features to Secure Today’s Data in a Post-Quantum World,” Microsoft Security Blog, Microsoft Windows PQC: “Active Directory Certificate Services (ADCS) support for issuance of ML-DSA certificates in Windows Server 2025 is now generally available as of May 2026,” and “PQC support requires newly deployed CAs (as existing CAs cannot be upgraded in place).”

The important nuance is that this is a forge-later signature and authentication surface, not a harvest-now one in the way TLS key exchange is. Forging a PKINIT authentication or a CA signature needs a quantum computer live at the moment of use, so the surface is ranked by blast radius, and the CA’s blast radius is enormous, because a forged CA signature can mint certificates the whole domain trusts. That’s what makes the PKI the highest-priority piece.

What does the krbtgt account have to do with the blast radius?

The krbtgt account is the domain’s master Kerberos key, and its blast radius is total, which is why it belongs in any full picture of Kerberos risk even though the krbtgt key itself is symmetric and quantum-resistant. Every ticket-granting ticket in the domain is encrypted and signed with the krbtgt key, so anyone who obtains it can forge tickets for any user, including domain administrators, the attack known as a golden ticket.

For quantum planning the krbtgt teaches a scoping lesson rather than adding a quantum exposure. The krbtgt key is a symmetric key, so Shor’s algorithm doesn’t recover it and Grover only halves its effective strength, so it’s not the quantum weak point. The quantum weak point is the public-key path an attacker could use to get a foothold that leads to krbtgt compromise, and the reason the CA matters so much is that a forged CA signature or a forged PKINIT authentication is one such path. The concentration of trust in a single domain key is a classic reason a small cryptographic failure becomes a domain-wide one, and it’s why the public-key edges that lead inward deserve priority even though the innermost key is symmetric.

What does migrating Kerberos and Active Directory to PQC look like?

It looks like a public-key migration of the certificate surfaces, with Microsoft supplying the algorithms in Windows itself, and the symmetric core left in place. The work concentrates on the PKI and the PKINIT edges, sequenced the way any PQC deployment is.

1. Post-quantum algorithms are in Windows. Microsoft made ML-KEM and ML-DSA generally available in Windows Server 2025 and Windows 11, through the Cryptography API: Next Generation (CNG) and certificate functions, so the operating system can generate and validate post-quantum keys and certificates.
2. AD Certificate Services supports ML-DSA. Active Directory Certificate Services support for issuing ML-DSA certificates in Windows Server 2025 became generally available in May 2026, across the three ML-DSA parameter sets, ML-DSA-44, ML-DSA-65, and ML-DSA-87. Microsoft is explicit that this requires newly deployed CAs, because existing CAs cannot be upgraded in place, so the practical route is a parallel CA hierarchy standing alongside the production one.
3. The symmetric core stays. Confirm Kerberos is using AES-256 rather than legacy ciphers, and that surface is done. There’s no post-quantum algorithm swap for the ticket encryption, because AES-256 already resists Grover.
4. Sequence the edges by blast radius. The CA hierarchy and PKINIT certificate logon are the quantum-exposed surfaces, so the migration is issuing post-quantum CA and end-entity certificates, using hybrid or composite certificates during the overlap so old and new clients interoperate.

Source: Microsoft, “Post-Quantum Cryptography APIs Now Generally Available on Microsoft Platforms,” Microsoft Security Blog, Microsoft PQC APIs, for ML-KEM and ML-DSA general availability in Windows Server 2025, Windows 11 and .NET 10, and for the hybrid/composite deployment guidance (“In some cases, this means deploying PQC in hybrid or composite modes, combining a post-quantum algorithm with a traditional one such as RSA or ECDHE”). This post discusses neither Kerberos nor PKINIT, and the blast-radius sequencing in item 4 is LaMarr Labs’ engagement practice rather than Microsoft guidance.

Source: Microsoft, “New Windows Features to Secure Today’s Data in a Post-Quantum World,” Microsoft Security Blog, Microsoft Windows PQC, for the ADCS status in item 2: “Active Directory Certificate Services (ADCS) support for issuance of ML-DSA certificates in Windows Server 2025 is now generally available as of May 2026,” “ADCS supports three ML-DSA parameter sets (ML-DSA-44, ML-DSA-65, ML-DSA-87),” and “PQC support requires newly deployed CAs (as existing CAs cannot be upgraded in place).”

The table sorts the Kerberos and AD surfaces into what’s resistant and what needs to move, which is the whole planning picture on one screen.

Surface	Cryptography	Quantum status	The move
Ticket / session-key encryption	Symmetric AES	Resistant (Grover only)	Confirm AES-256, retire RC4
krbtgt domain key	Symmetric	Resistant	No algorithm change; protect it as always
PKINIT certificate pre-auth	RSA / Diffie-Hellman (RFC 4556)	Broken by Shor	Post-quantum certificates + key establishment
Smart-card logon	Certificate-based, via PKINIT	Broken by Shor	Post-quantum certificates
AD Certificate Services (the CA)	CA signing keys, RSA / ECC	Broken by Shor, huge blast radius	Issue ML-DSA certificates

Common misconceptions

1. “Quantum computers break Kerberos.” The symmetric core of Kerberos is largely resistant, since Grover against AES-256 leaves a 128-bit margin. What breaks is the public-key machinery bolted on for certificate logon, chiefly PKINIT and the CA.
2. “Kerberos uses no public-key cryptography, so quantum doesn’t apply.” Password-based Kerberos is symmetric, and PKINIT (RFC 4556) adds RSA and Diffie-Hellman for certificate and smart-card logon, which is quantum-vulnerable. Whether you’re exposed depends on whether you use certificate-based authentication.
3. “The krbtgt key is the quantum weak point.” The krbtgt key is symmetric, so Shor’s leaves it standing, and its blast radius is total. The quantum-exposed paths that lead to compromising it are the public-key certificate surfaces, so those are the priority.
4. “We have to replace Kerberos with something post-quantum.” The protocol structure and its symmetric core stay. The migration issues post-quantum certificates for the PKINIT and CA surfaces, so it’s a PKI migration inside Active Directory, not a new authentication protocol.
5. “There’s no post-quantum support for Windows authentication yet.” Microsoft made ML-KEM and ML-DSA generally available in Windows Server 2025 and Windows 11, and AD Certificate Services supports the ML-DSA parameter sets, so the building blocks are shipping.

Questions people ask

Is Kerberos quantum-safe? Its symmetric core is largely resistant, because AES-256 keeps a 128-bit margin against Grover. The parts that aren’t safe are the public-key surfaces, PKINIT certificate pre-authentication and the CA that issues the certificates, which Shor’s algorithm breaks.

Do I need to migrate Kerberos itself, or just the certificates? Mostly the certificates. The base protocol and its symmetric encryption stay in place, and the migration issues post-quantum certificates for PKINIT, smart-card logon, and the Active Directory CA. Confirm AES-256 is in use and that surface is done.

What is PKINIT and why does it matter for quantum? PKINIT (RFC 4556) is the Kerberos extension that adds certificate-based initial authentication using RSA and Diffie-Hellman, which is what smart-card logon runs on. Those public-key operations are exactly what a quantum computer breaks, so PKINIT is Kerberos’s quantum-exposed edge.

Is this a harvest-now-decrypt-later problem? No, it’s a forge-later problem. Forging a PKINIT authentication or a CA signature needs a quantum computer live at the moment of use, so there’s nothing to harvest today, and the surface is ranked by blast radius, with the CA’s being the largest.

Does Windows support post-quantum authentication now? Microsoft made ML-KEM and ML-DSA generally available in Windows Server 2025 and Windows 11, and Active Directory Certificate Services supports the three ML-DSA parameter sets. So the domain CA can issue post-quantum certificates, which is the core of the migration.

Which ML-DSA parameter set should the AD CA use? Active Directory Certificate Services supports ML-DSA-44, ML-DSA-65, and ML-DSA-87, which trade signature and key size against security strength. The choice follows the same sizing logic as any ML-DSA deployment, balancing the larger post-quantum certificate sizes against the assurance level the domain needs.

What about legacy clients that don’t understand post-quantum certificates? Use dual-signature certificates during the overlap, where the classical and post-quantum signatures stay separable, so old clients validate the classical half while new ones can check both. Composite certificates fuse the two under one identifier and are rejected outright by a client that doesn’t recognize the format, so they solve a different problem and don’t cover the legacy population. This is the standard bridge for a PKI mid-migration.

Go deeper

• The Token-Key Question: asks which algorithm signs your identity tokens, and who holds that key.

---

Everything here is the map, given freely. When your team needs its Active Directory estate inventoried, its PKINIT and smart-card surfaces separated from its resistant symmetric core, and its certificate authority sequenced onto post-quantum signatures, that’s a working session with your team.

Last verified 2026-07-26 · Updated 2026-08-25 · Maintained by Addie LaMarr, LaMarr Labs.