Today marks the last phase of a rollout Microsoft has been running quietly since January. RC4 fallback in Kerberos authentication, tied to CVE-2026-20833, reaches full enforcement on every Windows domain controller as of the July 2026 security update. The registry key that let administrators postpone the change, RC4DefaultDisablementPhase, is removed entirely in this release. There is no dial to turn back.
Three phases, and the last one has no opt-out
The rollout started in January 2026 with an audit-only phase that logged which accounts were still negotiating RC4 tickets without blocking anything. April 2026 brought phase two: domain controllers began defaulting to AES-SHA1 for accounts without an explicit Kerberos encryption type configured, while still tolerating RC4 where it was in active use. Today’s update closes the loop. Enforcement mode is now active on every domain controller, and connections from accounts or devices that cannot negotiate AES are blocked outright.
For organisations that used the January to June window to inventory their environment, this is a formality. For everyone else, it is the day legacy service accounts, older Unix and Linux Kerberos integrations, network appliances with hardcoded encryption settings, and applications nobody has touched since a previous IT team built them all start failing authentication at once.
Why this keeps catching European IT teams off guard
RC4 has been a known weak point in Kerberos for years, and Microsoft has been broadcasting this timeline since January. The problem is not warning, it is inventory. Many mid-sized organisations running Active Directory in Europe do not have a clean list of which service accounts, printers, backup appliances, and third-party integrations are quietly relying on RC4 because nobody explicitly set msDS-SupportedEncryptionTypes when the account was created five or ten years ago. Those accounts worked fine right up until the fallback disappeared.
The practical fix is straightforward but time-sensitive: pull Directory Service and Kerberos event logs (Event ID 4769 and related) for accounts still requesting RC4 tickets, set explicit AES encryption types on every service account and computer object, and test authentication against any network appliance or legacy application that talks Kerberos before assuming it will keep working. Doing this reactively, after helpdesk tickets start arriving, is a far worse position than doing it as a planned change window.
If your organisation has not audited its Active Directory environment against this deadline, or you are already seeing authentication failures today, contact Excello Digital. We help European IT teams inventory Kerberos encryption dependencies, remediate legacy accounts before they become outages, and keep Active Directory environments aligned with Microsoft’s hardening timelines instead of reacting to them after the fact.