Kerberos RC4 enforcement lands in July 2026: the 9 events that tell you what will break

Summary. Microsoft's Kerberos RC4 hardening for CVE-2026-20833 runs in 3 phases, and the third starts with the Windows updates released in or after July 2026. Those updates remove support for the RC4DefaultDisablementPhase registry value, which has been the rollback switch since 13 January 2026. Audit mode goes with it. The behavioural change already happened on 14 April 2026, when the default DefaultDomainSupportedEncTypes for KDC operations became AES-SHA1 only, 0x18, for any account with no explicit msDS-SupportedEncryptionTypes attribute. July removes the ability to step back. Domain controllers running Windows Server 2012 through 2025 log 9 warning and error events, IDs 201 to 209 from source Kdcsvc in the System log, naming exactly which accounts still depend on RC4. If those events are firing in your environment, something authenticates today that will stop authenticating. This is how to read them, and how to fix the accounts before the switch disappears.

One caveat up front, stated plainly because it changes how you should read the rest: Microsoft's KB for this change was last revised on 14 April 2026. Everything below about July is Microsoft's published plan as of that revision, not a post-release confirmation of what shipped.

What CVE-2026-20833 actually is

It is an information disclosure vulnerability in the Kerberos authentication protocol. Microsoft's description is that it might allow an attacker to obtain service tickets with weak or legacy encryption types such as RC4, then run offline attacks to recover a service account password. That is Kerberoasting, and the reason the fix is a protocol default change rather than a patch is that the weakness is in what the KDC is willing to issue.

The Windows updates released on and after 13 January 2026 contain the protections. There is a sentence in Microsoft's KB that a lot of teams missed, and it matters:

"Installing updates released on or after January 13, 2026, will NOT address the vulnerabilities described in CVE-2026-20833 for Active Directory domain controllers by default."

Patching in January did nothing on its own. The default only moved in April. Full mitigation required enabling Enforcement mode, which is exactly what July automates.

Affected platforms are Windows Server 2012 and 2012 R2 under Extended Security Updates, and Windows Server 2016, 2019, 2022, version 23H2 and 2025. Third-party KDCs are not affected: Microsoft's FAQ states the change only impacts Windows domain controllers, and Kerberos trust and referral flows with other Windows DCs or third-party KDCs are unaffected.

The three phases

The important thing to understand about phase 3 is that it is not a new block. The block arrived in April. July removes the escape hatch.

Microsoft's own text on this point is not perfectly consistent between its "Timing of updates" and "Take action" sections, so read the timing section as authoritative: April flipped the default while leaving a manual way back, and July takes the way back away.

The registry value that is about to stop existing

RC4DefaultDisablementPhase is a temporary gate. Microsoft says it "is temporary and will no longer be read after the enforcement date."

Do not confuse this with DefaultDomainSupportedEncTypes, which is a different value in a different hive: HKEY_LOCAL_MACHINE\System\CurrentControlSet\services\KDC, also REG_DWORD. That one is not going away. Microsoft's FAQ answers the question directly, saying it will not remove the ability to configure it and will honour any configuration explicitly set by an administrator.

So after July you still control encryption types. What you lose is the ability to put the domain back into audit mode and think about it later.

The 9 events, and what each one means

All nine come from source Kdcsvc in the System event log on domain controllers running Windows Server 2012 and later.

The pairs matter more than the individual IDs. A warning today becomes a failure tomorrow along four fixed paths: 201 becomes 203, 202 becomes 204, 206 becomes 208, and 207 becomes 209. If you are seeing 201, 202, 206 or 207 in your System log right now, those are the authentications that break.

Event 205 is the exception. It logs when DefaultDomainSupportedEncTypes is defined as anything other than AES-SHA1 only, it fires each time KDCSVC starts, and Microsoft states it will never turn into an error. Treat it as a configuration notice, not a countdown.

One detection gap worth knowing: events 201 and 202 are not logged if DefaultDomainSupportedEncTypes is manually defined. A domain that set that value years ago gets a quieter log than a domain that never touched it, and quieter is not the same as safer.

The hex values that catch people out

This is where remediation goes wrong, because Microsoft publishes two different tables and the same hex value means different things in each.

Read that table twice. 0x17 in a ticket field means RC4-HMAC, which is the thing you are trying to eliminate. 0x17 in the account attribute means DES plus RC4 plus AES 256, which is a different statement about the same account. 0x18 is worse: in the attribute it is the secure AES-only value Microsoft is moving everyone to, and in a ticket field it is RC4-HMAC-EXP. Always know which field you are reading before you act on the number.

Two more values you will meet. 0x0 means the attribute is not defined, so the account falls back to DefaultDomainSupportedEncTypes, which is the whole mechanism at issue. 0x24 is RC4 with AES session keys, and Microsoft names it as the last-resort fallback for devices that cannot do AES. Microsoft's note on it is unambiguous: this configuration is insecure, and it leaves all accounts in the domain vulnerable to CVE-2026-20833.

How to find the accounts still using RC4

There are two detection surfaces and they answer different questions.

The KDCSVC 201 to 209 events tell you what the KDC is about to refuse. The Security log tells you what is actually happening on the wire.

For the Security log, event 4768 is a ticket-granting ticket request and 4769 is a service ticket request. These carry RC4 detail on Windows Server 2019 and later; Windows Server 2016 gained it in the January 2025 cumulative update. The fields to read are MSDS-SupportedEncryptionTypes and Available Keys under account and service information, Advertized Etypes under network information for what the client claims to support, and Session Encryption Type plus Ticket Encryption Type under additional information.

Microsoft publishes two PowerShell scripts for this in the microsoft/Kerberos-Crypto repository on GitHub:

            # Enumerate available encryption keys per account from the event logs
.\List-AccountKeys.ps1

# Show Kerberos encryption types in use, filtered to RC4
.\Get-KerbEncryptionUsage.ps1 -Encryption RC4
          

Both need permission to read the Security event logs on domain controllers and the ActiveDirectory PowerShell module. To read the attribute directly on one account:

            $accountName = "<computer account name>"
$parameters = @{
     Filter     = "Name -eq '$($accountName)' -and (ObjectClass -eq 'Computer' -or ObjectClass -eq 'User')"
     Properties = "msDS-SupportedEncryptionTypes"
}
Get-ADObject @parameters | FL "DistinguishedName","msDS-SupportedEncryptionTypes","Name","ObjectClass"
          

That returns decimal, not hex. A result of 28 is 0x1C, which is RC4 plus AES 128 plus AES 256.

Now the trap that wastes a day. On Windows Server 2022 and earlier, msDS-SupportedEncryptionTypes in the event always shows DES and RC4 to keep compatibility with older domain controllers, regardless of your actual settings. Available Keys shows RC4 regardless of usage. Only from Windows Server 2025 do the displayed values narrow to AES-SHA1 and stronger. The event is showing you a processed value, not the raw attribute, so cross-check with Get-ADObject before concluding an account is misconfigured.

Remediation, in the order Microsoft recommends

Four steps: update, monitor, mitigate, enable.

Update every domain controller with a January 2026 or later update. Monitor the System log for any of the 201 to 209 events. Mitigate whatever is blocking. Enable Enforcement mode once warning, blocking and policy events have stopped appearing, by setting RC4DefaultDisablementPhase to 2. After July, that last step happens whether or not you did the first three.

For the mitigation itself, the preferred fix is per-account rather than domain-wide. Define msDS-SupportedEncryptionTypes explicitly on the accounts that need it, so they never fall back to the domain default. Microsoft's guidance on editing DefaultDomainSupportedEncTypes is a caution: the right method depends on your risk tolerance, because changing that value changes behaviour for every account that has no value of its own.

Three specific fixes cover most of what you will find.

An account with no AES-SHA1 keys because it predates AES support gets them from a password change. AES-SHA1 support arrived in Windows Server 2003, so an account created before then, or one whose password has not rotated since, may simply lack the keys. Changing the password generates them.

User accounts without a service principal name do not need msDS-SupportedEncryptionTypes set at all.

Legacy devices that genuinely cannot do AES need replacing or upgrading, particularly anything on Windows Server 2003 or earlier. For a third-party device stuck on RC4, Microsoft asks you to contact the vendor first, and publishes stillneedrc4@microsoft.com for cases where that fails.

To set encryption types by policy, the setting is Network security: Configure encryption types allowed for Kerberos, at Computer Configuration, Policies, Windows Settings, Security Settings, Local Policies, Security Options. The checkboxes are AES128_HMAC_SHA1, AES256_HMAC_SHA1 and RC4_HMAC_MD5. For AES only, tick the first two. Scope the GPO to the right OUs, restart the devices, then verify with the two scripts above. A machine updates its msDS-SupportedEncryptionTypes in the directory after a restart.

The registry equivalent for the domain default is DefaultDomainSupportedEncTypes set to 0x18 under HKEY_LOCAL_MACHINE\System\CurrentControlSet\services\KDC, which allows only AES128_HMAC_SHA1 and AES256_HMAC_SHA1.

What failure looks like

Knowing the error strings saves an hour of guessing when a ticket starts coming back the wrong shape.

An SMB share where the account's only supported type is RC4 produces a network error on access. A remote PowerShell session fails at New-PSSession with "WinRM cannot process the request. The following error with errorcode 0x80090342 occurred while using Kerberos authentication: An unknown security error occurred."

Chasing it down: klist get HOST/vm01.contoso.com returns 0xc00002fd, "The encryption type requested is not supported by the KDC." On the domain controller, event 4769 then shows Failure Code 0xE, which is KDC_ERR_ETYPE_NOTSUPP.

The place this bites most often, per Microsoft, is Kerberos keytabs. If a keytab was exported with RC4 keys only, but the target service account has AES-SHA1 keys and no msDS-SupportedEncryptionTypes defined, authentication to that service can fail. The failure surfaces from the target service rather than from the KDC, which is why it gets misdiagnosed as an application problem. If you run Linux or Java services joined to Active Directory, your keytabs are the first thing to check.

One architectural constraint that predates all of this and catches people planning a Windows Server 2025 upgrade: from Windows Server 2025, domain controllers do not issue RC4 ticket-granting tickets at all. You can still authenticate to a legacy device with RC4, but the legacy device cannot authenticate using Kerberos. If you need that, those DCs have to stay on an earlier version.

The warning most teams will trip over

Microsoft is explicit that a quiet log is not a clean bill of health:

"Audit events related to this change are only generated when Active Directory is unable to issue AES-SHA1 service tickets or session keys. The absence of audit events does not guarantee that all non-Windows devices will successfully accept Kerberos authentication after the April update."

The recommendation attached to that is to validate non-Windows interoperability by testing before enabling the behaviour broadly. Microsoft also states it has limited visibility into why a given non-Windows device may fail after the April change, and that the primary recommendation is to work with the device vendor.

That is the real risk profile here. Windows-to-Windows authentication mostly sorts itself out. The appliances, the storage controllers, the Java middleware and the network gear that joined the domain years ago are where this lands, and none of them generate a KDCSVC event until they fail.

Microsoft has also published a separate advisory flagging that this Kerberos hardening may affect FSLogix profiles on SMB storage. If you run FSLogix, read that advisory alongside this one before enforcing.

The honest engineering read: the accounts you can find in the logs are not the problem. The devices that never appear in them are.

India-specific considerations

For Indian enterprises and the GCCs running Active Directory for a global parent, two things are worth flagging.

Domain controller estates here are often older than the org chart suggests, because AD is one of the few systems nobody wants to touch. Windows Server 2012 and 2012 R2 are in scope only through Extended Security Updates, so an estate on those versions carries both a licensing dependency and this change at the same time.

The second is the shared-service pattern. Where one AD forest serves multiple client environments or business units, a domain-wide change to DefaultDomainSupportedEncTypes touches every tenant at once. The per-account approach costs more effort and is the right call, because the blast radius of getting it wrong is the whole forest. Teams that run this as an inventory exercise first, then a per-account remediation, then enforcement, do not end up explaining an outage. For organisations building their broader hardening programme, this pairs with the access and identity work covered in our corporate IT compliance auditing guide.

FAQ

How eCorpIT can help

eCorpIT runs identity and infrastructure hardening work for organisations that cannot take an authentication outage, and our senior engineering teams design environments aligned with Microsoft's published security baselines. We inventory Kerberos encryption usage across domain controllers, service accounts and keytabs, remediate per account rather than per domain, and stage enforcement so failures surface in test rather than production. If RC4 events are appearing in your System log, contact us and we will scope the remediation against your actual account inventory.

References

1. How to manage Kerberos KDC usage of RC4 for service account ticket issuance changes related to CVE-2026-20833 (KB5073381) - Microsoft Support, published 13 January 2026, last revised 14 April 2026.

1. Detect and remediate RC4 usage in Kerberos - Microsoft Learn, Windows Server security documentation.

1. microsoft/Kerberos-Crypto - Microsoft's PowerShell scripts for enumerating Kerberos encryption usage.

1. How to Manage RC4 Hardening: Definitive Guide - Microsoft Core Infrastructure and Security Blog.

1. What Changed in RC4 with the January 2026 Windows Update and Why it is Important - Microsoft Core Infrastructure and Security Blog.

1. Kerberos and the End of RC4: Protocol Hardening and Preparing for CVE-2026-20833 - Microsoft Security discussion.

1. What is going on with RC4 in Kerberos? - Microsoft Ask the Directory Services Team blog.

1. Manage Kerberos KDC usage of RC4 for service account ticket issuance - Microsoft Q&A.

1. Change to Kerberos Encryption for Active Directory: RC4 to AES - Microsoft Q&A.

1. Action required: Windows Kerberos hardening (RC4) may affect FSLogix profiles on SMB storage - Microsoft FSLogix Blog.

1. Azure Files RC4 encryption impact - Microsoft Q&A.

Last updated: 20 July 2026.