Kerberoasting in 2026: What CVE-2026-20833 and RC4 Disablement Actually Change for Active Directory

If any service accounts in your Active Directory environment are still relying on RC4 for Kerberos ticket encryption, Microsoft’s phased rollout under CVE-2026-20833 has already reached full enforcement. As of Windows updates released July 2026 and later, RC4 disablement is no longer an audit-only warning, it is the enforced default, and the fallback registry value that let you delay this no longer works. If you have not specifically verified your environment’s encryption types, this is worth checking today, not after something breaks.

Why RC4 mattered to attackers in the first place

Kerberoasting is the technique of requesting a Kerberos service ticket for any service account in the domain, something any authenticated domain user can do by design, and then attempting to crack the ticket’s encryption offline to recover the service account’s password. Any domain user can trigger this, no elevated privileges are required to request the ticket itself, only to crack what comes back.

RC4-encrypted tickets (service ticket requests carrying TicketEncryptionType 0x17 in Windows Security Event ID 4769) are dramatically faster to crack offline than AES-encrypted ones, which is exactly why Kerberoasting tooling has always specifically requested RC4 tickets when the domain allows it. A service account with a weak or reused password, protected only by RC4 encryption, has historically been one of the more reliable paths from a single compromised standard user account toward broader domain compromise.

What CVE-2026-20833 actually changed

CVE-2026-20833 is an information disclosure vulnerability in Windows Kerberos (CVSS 5.5) rooted in the continued availability of RC4 as a supported encryption type. Rather than a single patch, Microsoft addressed it through a phased default change:

• January 13, 2026: domain controllers received new telemetry and audit controls specifically to surface accounts still using RC4, giving administrators visibility before anything changed functionally.
• April 2026: a second deployment phase moved further toward enforcement.
• July 2026 onward: full enforcement. The default changed to 0x18 (AES-SHA1 only) for any account without an explicit msDS-SupportedEncryptionTypes attribute set. Windows updates from this point on also removed support for the RC4DefaultDisablementPhase registry value administrators had been using to control the rollout pace, and removed Audit mode entirely, leaving Enforcement as the only available mode.

The practical consequence if you have not checked your environment: any service account that was quietly depending on RC4, whether because of legacy application requirements or simply because nobody had ever explicitly set its supported encryption types, is now either failing Kerberos authentication outright or has already been silently pushed to AES if it was compatible with that transition. Not knowing which of those two happened for a given account is the actual risk here.

How to check your current exposure

# Find accounts without an explicit supported-encryption-types attribute set
Get-ADUser -Filter * -Properties msDS-SupportedEncryptionTypes, ServicePrincipalName |
    Where-Object { $_.ServicePrincipalName -and -not $_.'msDS-SupportedEncryptionTypes' } |
    Select-Object Name, DistinguishedName

# Same check for computer accounts running services
Get-ADComputer -Filter * -Properties msDS-SupportedEncryptionTypes |
    Where-Object { -not $_.'msDS-SupportedEncryptionTypes' } |
    Select-Object Name, DistinguishedName

On your domain controllers, review recent Event ID 4769 entries for RC4 ticket requests specifically:

Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4769} -MaxEvents 500 |
    Where-Object { $_.Message -match 'Ticket Encryption Type:\s*0x17' } |
    Select-Object TimeCreated, @{N='Account';E={($_.Message -split "`n" | Select-String 'Account Name:')[0]}}

Any hits here after July 2026 either represent an account that has explicitly re-enabled RC4 (worth investigating why) or a domain controller that has not yet received the enforcing update, both of which need follow-up.

Fixing accounts still on RC4

Set the supported encryption types explicitly to AES for any account that needs it, rather than leaving it to the default:

Set-ADUser -Identity "svc-account" -Replace @{'msDS-SupportedEncryptionTypes' = 24}

A value of 24 (0x18) corresponds to AES128 plus AES256. Test this against a single account first if the underlying application’s compatibility with AES-only Kerberos hasn’t been explicitly verified, some legacy applications with hardcoded RC4 assumptions genuinely will break, and you want to find that out on one account, not the entire fleet at once.

Frequently asked questions

Can I still delay this rollout if I’m not ready?
Not through the mechanism that used to allow it. The RC4DefaultDisablementPhase registry value that previously let administrators control the pace of this rollout stopped being honored in Windows updates from July 2026 onward, and Audit mode (which logged without enforcing) was removed at the same time. If you have applications still depending on RC4, the immediate path is fixing those applications or explicitly configuring their service accounts, not delaying the platform-level change further.

Does this fully eliminate Kerberoasting as a risk once RC4 is disabled?
No, it substantially raises the cost of the attack rather than eliminating it. AES-encrypted tickets are far more computationally expensive to crack offline than RC4 ones, which meaningfully reduces the practicality of cracking a strong service account password, but a genuinely weak or short service account password can still eventually be cracked even from an AES-encrypted ticket. Strong, unique service account passwords (ideally 25+ characters, since service accounts are rarely typed by a human and don’t need to be memorable) remain a necessary complementary control, not a step this change makes optional.

How do I know if my domain controllers actually have the enforcing update installed?
Check the installed update history against the specific KB associated with CVE-2026-20833 in Microsoft’s Security Update Guide entry for that CVE, or check your patch management platform’s compliance report directly against that KB, rather than assuming a general “recent” patch level covers this specific change.