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 not rebuilding Kerberos, it’s 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.

Source: IETF, “Advanced Encryption Standard (AES) Encryption for Kerberos 5,” RFC 3962, February 2005, RFC 3962.

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. The certificates PKINIT trusts are issued by Active Directory Certificate Services, whose signing keys and issued certificates are RSA or elliptic-curve, 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.

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 honest 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 supports the three ML-DSA parameter sets, ML-DSA-44, ML-DSA-65, and ML-DSA-87, so the domain’s CA can begin issuing post-quantum certificates for scenarios like certificate logon.
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.

Source: Microsoft, “New Windows Features to Secure Today’s Data in a Post-Quantum World,” Microsoft Security Blog, Microsoft Windows PQC.

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 hybrid or composite certificates during the overlap so a certificate carries both a classical and a post-quantum signature, letting old clients validate the classical half while new ones validate the post-quantum half. This is the standard bridge for a PKI mid-migration.

---

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 the work I do, and there’s an alignment briefing for it.

Last verified 2026-07-14 · Maintained by Addie LaMarr, LaMarr Labs.