Microsoft shipped security updates on July 14, 2026, that put Windows domain controllers into full enforcement of Kerberos RC4 hardening for CVE-2026-20833. The updates strip out the temporary registry switch that allowed administrators to revert to audit-only mode, closing a six‑month escape hatch many organizations used to buy time while testing applications. After these patches, any Kerberos service ticket that relies on RC4 encryption by default will be blocked outright unless the administrator has explicitly configured the service account to accept it.

The change, detailed in Microsoft’s support article KB5073381 (originally published January 13, 2026, and last updated for the July milestone), completes a staged rollout that began with auditing in January and flipped the default encryption type to AES‑SHA1 in April. The final phase removes the RC4DefaultDisablementPhase registry value under HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\Kerberos\Parameters, meaning domain controllers will no longer read that key. Attempting to change it back to 1 (warning only) or removing it entirely will not restore the earlier behavior.

A hard stop for RC4 fallback, not a blanket ban

The July update does not strip every RC4 configuration from Active Directory. Administrators can still set the msDS-SupportedEncryptionTypes attribute on individual service accounts to explicitly include RC4, and the domain‑wide DefaultDomainSupportedEncTypes registry value is still honored—accompanied by a persistent warning event (Event ID 205) that flags the risky configuration. What’s gone is the implicit assumption that if nothing is specified, the Key Distribution Center (KDC) should try RC4.

Before April, an account with no encryption type configuration would be treated as if RC4 were available. The April update changed the default DefaultDomainSupportedEncTypes to 0x18 (AES‑SHA1 only), but administrators could still set RC4DefaultDisablementPhase to 1 to log warnings without blocking requests. July’s enforcement means that temporary rollback is dead: KDCs no longer assume RC4 by default, and there is no way to make them go back to the pre‑January behavior.

Microsoft left one door open for emergency compatibility: the bitmask 0x24 on msDS-SupportedEncryptionTypes. That value tells the KDC to encrypt the service ticket with RC4 while still using AES for session keys. It is weaker than full AES enforcement but far safer than a domain‑wide rollback, because it limits exposure to specific accounts and leaves an audit trail via Event ID 205 when DefaultDomainSupportedEncTypes is misconfigured.

The immediate operational risks

Organizations that used the audit phase to clean up service accounts and keytabs should see minimal disruption. Trouble will land on environments where the absence of an explicit encryption type was treated as an implicit RC4 compatibility policy. The most common failure scenarios are:

  • Service accounts created long ago that never had an AES key generated. Resetting or rotating the password generates the missing keys, but every application or script that uses those credentials must be coordinated.
  • Kerberos keytabs on Linux services, network appliances, Java applications, or storage systems that contain only RC4 keys. Even if the Active Directory account has AES keys, the KDC may now issue an AES ticket that the service cannot decrypt, producing puzzling authentication failures (password prompts, access denied errors, or hung connections) that show no errors on the domain controller logs.
  • Azure Files identity‑based SMB access that still relies on RC4. Microsoft’s Azure documentation specifically names the July Windows Server change as a compatibility deadline for configurations that depend on the older encryption default.
  • Clients advertising only RC4 (for example, an old printer or a misconfigured Linux client) that request a ticket for a service with no explicit msDS-SupportedEncryptionTypes. The KDC will now flat‑out reject that request, logging Event ID 203.

For home users and small offices running a single domain controller for a handful of PCs and maybe a NAS, the likelihood of hitting an RC4 dependency is lower, but not zero: a legacy VPN appliance or an ancient multifunction printer could trigger failures. The telltale sign will be an authentication prompt that never succeeds, typically after the July updates install and the server restarts.

Nine event IDs to watch across every domain controller

Since January, Windows Server 2012 and later domain controllers have been writing new Kdcsvc events to the System event log. During the audit phase (RC4DefaultDisablementPhase=1), IDs 201, 202, 206, and 207 were warnings. Under enforcement (value=2, or after July when the value is effectively gone), those same conditions become hard errors with different event IDs:

  • Event ID 203: The client advertised only RC4, and the target service has no explicit encryption configuration. Ticket denied.
  • Event ID 204: The service account itself has only insecure (RC4) keys and no explicit encryption type set.
  • Event ID 208: The client offered only RC4, but the service or domain policy is set to AES‑SHA1 only (via msDS-SupportedEncryptionTypes or DefaultDomainSupportedEncTypes).
  • Event ID 209: The account is configured for AES‑SHA1 but lacks actual AES keys.
  • Event ID 205: This one is different. It fires when DefaultDomainSupportedEncTypes contains something other than pure AES‑SHA1, and it remains a warning even after enforcement—Microsoft will not override an administrator’s explicit domain‑wide downgrade. It does not indicate a failure, but it looks like a giant signpost that the entire domain is exposed to the vulnerability the whole update was designed to patch.

Administrators must check all domain controllers, not just one, because events are generated only on the KDC that processes the ticket request. A silent absence of events does not guarantee safety; Microsoft explicitly warns that non‑Windows devices might accept a ticket from the KDC but then fail when presented with an AES‑encrypted service ticket later. The only reliable way to catch those is to inspect the application or appliance logs on the target service.

How we got here: a three‑stage security rollout

Microsoft’s path to removing RC4 defaults began with a straightforward vulnerability: CVE‑2026‑20833 is an information disclosure bug in the Kerberos protocol that makes service tickets encrypted with weak legacy ciphers susceptible to offline brute‑force attacks. An attacker who can request a ticket for a service principal name (SPN) can perform an efficient password‑cracking attack without generating repeated authentication requests—the classic Kerberoasting technique. RC4‑encrypted tickets are particularly vulnerable because the ticket key is derived directly from the account password and is quick to attack with modern hardware.

The fix had to be rolled out in phases because millions of corporate applications were built on the assumption that RC4 would always be available as a fallback. The timeline:

  • January 13, 2026: Initial deployment phase. Updates introduced the RC4DefaultDisablementPhase registry key with three values (0=off, 1=warnings, 2=assume RC4 not supported). Administrators could set the value to 1 to get audit events, then move to 2 only after cleaning up their environment.
  • April 14, 2026: Enforcement with manual rollback. The default DefaultDomainSupportedEncTypes changed to 0x18 (AES‑SHA1), and the KDC automatically treated unspecified accounts as AES only, redirecting any RC4‑only requests to error events 203, 204, 208, 209. But admins could still flip RC4DefaultDisablementPhase back to 1 to return to warning‑only mode.
  • July 14, 2026: Permanent enforcement. The RC4DefaultDisablementPhase registry value is ignored; the KDC behaves as if it were permanently set to 2. No more audit escape hatch.

This staged approach gave organizations roughly six months to inventory RC4 dependencies and fix them.

What to do right now

  1. Audit before you patch. Check the System event log on every domain controller for event IDs 201–209. Focus especially on any errors (203, 204, 208, 209) that may already be present because you enabled enforcement early. If you are still running in audit mode (phase 1), the warning events 201, 202, 206, and 207 tell you exactly which accounts and clients will break after the July update.
  2. Review service account keys. For each service account flagged by an event, verify that it possesses AES keys. If it does not, reset the account password (coordinating with service owners) to generate them. In Active Directory, you can inspect the msDS-SupportedEncryptionTypes attribute and the available key types.
  3. Inspect keytabs on non‑Windows services. A Linux box, NAS, or Java application that holds a keytab with only RC4 entries will fail when the KDC hands out an AES ticket. Regenerate the keytab with AES keys included. The Azure Files hybrid authentication setup (AzFilesHybrid) is a known sensitive area.
  4. If you must keep an RC4‑only device temporarily, set the service account’s msDS-SupportedEncryptionTypes attribute to 0x24. This is a targeted, logged exception that lets you keep that single service running while you plan a proper migration. Avoid the nuclear option of setting DefaultDomainSupportedEncTypes to 0x24 across the domain—that silences the error but leaves every account relying on the default exposed to Kerberoasting, and it will be flagged by Event ID 205 forever.
  5. Test before broad deployment. Even if the event log is clean, stand up a test domain controller with the July update and exercise critical applications. Microsoft cautions that some non‑Windows implementations might not fail at the KDC but will fail later when processing an AES ticket. The January support article explicitly recommends validating through testing before enabling enforcement broadly.

What’s next

Microsoft is unlikely to remove the ability to explicitly configure RC4 completely, because too many legacy systems would break permanently. But the direction is clear: RC4 is being pushed into a corner where it can only exist by conscious administrator choice, accompanied by a glaring warning event. Future Kerberos hardening changes will almost certainly follow a similar pattern of long audit periods ending in enforced defaults. Meanwhile, organizations that have not yet modernized their service accounts and keytabs should treat the July update as the final deadline—no more rollback switches, no more quiet deprecation, just a hard cutover to modern encryption defaults.