The July 2026 Patch Tuesday made headlines for its size — a record 622 CVEs, several under active attack (BleepingComputer). But for anyone running Active Directory, the change that will cause the most real-world outages is not a CVE at all. The same July update completes the final deployment phase of Kerberos RC4 hardening tied to CVE-2026-20833, and once your domain controllers take it, the environment-wide escape hatch for RC4 is gone (Cybernews). If anything in your estate still leans on RC4 Kerberos tickets, it stops authenticating.
This is not a surprise deadline. Microsoft has staged it since January 2026. But “we’ve known for months” and “we’ve verified our service accounts” are different sentences, and plenty of teams ran through Audit mode without ever reading the audit results. As your domain-controller patch rings roll out, this is your last cheap chance to catch up.
What actually changed
Microsoft rolled this out in deliberate phases: audit mode in January 2026, enforcement in April 2026 (accounts with no AES key material began failing), and now July, which removes the last of the opt-outs (Microsoft AskDS):
- Audit mode is removed. There is no longer a “log but allow” setting for RC4 service-ticket issuance.
- The
RC4DefaultDisablementPhaseregistry override stops working. Updates from July 2026 onward ignore it, so the domain-wide deferral lever — and any supported rollback — disappears (Falcon Internet). - Enforcement is the default and it is permanent. The KDC will not issue RC4 service tickets except where you have explicitly set a per-account exception.
Two clarifications worth keeping straight: RC4 is not being ripped out of the protocol, and per-account overrides via msDS-SupportedEncryptionTypes still function. This is about defaults and about closing the environment-wide escape hatch, not about deleting RC4 outright.
What tends to break
Service accounts with no AES keys
An account only gains AES keys when its password is set after the domain supported AES. A service account whose password has not changed since, say, 2014 may have no AES key at all. These are your highest-probability breakages — and the fix (a password reset, or correcting msDS-SupportedEncryptionTypes) has to happen before enforcement, not mid-outage.
Legacy operating systems and appliances
Windows Server 2012 R2, lingering Windows 7 ESU machines, older NAS devices, printers, and network appliances with dated Kerberos stacks. Anything that joined the domain a decade ago and “just works” earns suspicion this week.
Third-party and non-Windows Kerberos
SAP, Oracle, Java middleware with hand-edited krb5.conf files, Linux hosts joined via older Samba or SSSD configurations, and MIT/Heimdal realms with cross-forest or cross-realm trusts. These often had RC4 pinned in a config file years ago by someone who has since moved on. Cayosoft’s analysis covers the AD-side mechanics well.
How the failures show up
Watch two signatures on your domain controllers. Event 4769 with encryption type 0x17 (RC4-HMAC) shows which accounts and services are still negotiating RC4 — effectively your answer key. Event 4769 with failure code 0x19 (KDC_ERR_ETYPE_NOSUPP) is the KDC refusing to issue an RC4 ticket — that is the enforcement break, surfacing to users as “can’t reach the file share or app since this morning.”
Why this belongs in an endpoint-security conversation
RC4 in Kerberos is not just a compatibility relic — it is an attacker’s friend. RC4 ticket hashes are the ones Kerberoasting cracks quickly offline, turning a low-privileged foothold into a service-account credential and then lateral movement. Killing RC4 fallback closes an escalation-adjacent door that has been propped open for years. The operational pain this week is the price of a real security win, and it sits in the same project as removing local admin: cut the cheap paths from “any account” to “privileged account.”
What to do now
- Read your audit data while it still exists. Pull the audit-phase events and 4769/0x17 events from your domain controllers going back to January. That list of RC4-dependent principals is the entire answer key — do not guess.
- Reset stale service-account passwords. AES key material is generated on password change; an account with pre-AES credentials will keep failing until you rotate its secret.
- Correct
msDS-SupportedEncryptionTypeson suspect accounts so AES is included — deliberately, not discovered at 9am on a Wednesday. - Check cross-forest trusts and confirm each supports AES rather than relying on RC4.
- Inventory non-Windows Kerberos clients (SAP, Oracle, Java, Samba/SSSD, MIT/Heimdal) and have their owners confirm AES support and test in a ring.
- Stage domain-controller updates ring by ring with the service desk briefed on what a Kerberos encryption failure looks like in a ticket. With no rollback key left, you cannot re-enable RC4 fallback after the fact.
- If something breaks anyway, fix it surgically. Set
msDS-SupportedEncryptionTypeson the specific account, or reset its password to generate AES keys. Resist re-enabling RC4 broadly — every account you exempt stays on the Kerberoasting menu, so put a date on retiring each exception.
Teams that spent Audit mode actually reading their logs will find July boring. If that is not you, you have until your domain controllers take this update to catch up — and it is far cheaper to spend that time now than during an authentication outage.
