Windows Kills RC4 for Good in July 2026: Active Directory Logins May Break Without Warning

What happened to RC4 on Kerberos

Kerberos is the heart of authentication on Active Directory. Every time a user or service requests access to a domain resource, the Domain Controller (DC) issues a "ticket" encrypted with the target account's key. Several encryption algorithms can be used for this, and one of them is RC4-HMAC — a legacy holdover from the Windows 2000 era. The problem is that RC4 is cryptographically weak: its key is derived directly from the NTLM hash of the password, making it vulnerable to Kerberoasting and offline ticket cracking.

The vulnerability that triggered this round of changes is CVE-2026-20833 — a Kerberos information-disclosure flaw tied to DCs still issuing service tickets with RC4. Microsoft therefore decided to retire RC4 permanently for service-account ticket issuance, rolling out enforcement in phases until administrators can no longer roll it back.

What makes this more dangerous than a typical patch is that it is not a "fix and forget" flaw — it removes a capability that many systems still silently depend on. This especially affects non-Windows devices and apps whose Kerberos settings were configured years ago and never touched again.

The 3-phase timeline: from warning to permanent enforcement

Microsoft did not turn RC4 off overnight. Enforcement was split into three phases to give organizations time to adapt. The trap is that many organizations ignored the first two phases because "the system still worked" — only to hit the final, irreversible phase.

Who breaks, and what the symptoms look like

Windows machines that join the domain normally usually already support AES, so they are rarely affected. The highest-risk group is non-Windows devices and services using old Kerberos keytabs that contain only RC4 keys, or service accounts flagged to force RC4.

Encryption types compared: RC4-HMAC vs AES

To understand why AES is necessary, compare the encryption types Kerberos uses. The etype number in parentheses is the code you'll see in logs and in the klist tool.

Check before it breaks: Event IDs 201–209 on the DC

The good news is that the DC already logs every RC4 usage to the System event log (source: Microsoft-Windows-Kerberos-Key-Distribution-Center), so you can tell in advance which accounts will break by looking at Event IDs in the 201–209 range. These events name the accounts still requesting tickets with RC4.

To pull these events with PowerShell on the DC:

Get-WinEvent -FilterHashtable @{
  LogName = 'System'
  ProviderName = 'Microsoft-Windows-Kerberos-Key-Distribution-Center'
  Id = 201,202,203,204,205,206,207,208,209
} -MaxEvents 200 | Format-Table TimeCreated, Id, Message -AutoSize

Run it on every DC (the logs are not centralized) and collect the account names that appear — that is your fix-before-enforcement list. Watching logs this way follows the same principle we recommend in our article on the Disaster Recovery every organization needs: know about the problem before the system goes down, not after.

Pre-update checklist: commands to inspect keytabs and encryption types

Regenerate a keytab with AES support

When you find that a keytab has only RC4 keys, the fix is to regenerate it with AES keys. The method differs by platform.

On Windows (ktpass): run it on a DC or a machine with RSAT. Example for the service account svc_app:

ktpass -princ HTTP/app.example.com@EXAMPLE.COM ^
  -mapuser svc_app ^
  -crypto AES256-SHA1 ^
  -ptype KRB5_NT_PRINCIPAL ^
  -pass * ^
  -out app-aes.keytab

This resets the account password and produces a keytab containing an AES256 key. Deploy app-aes.keytab in place of the old file on the target server.

On Linux (MIT ktutil): to add AES entries to the existing keytab:

ktutil
ktutil:  addent -password -p HTTP/app.example.com@EXAMPLE.COM -k 1 -e aes256-cts-hmac-sha1-96
ktutil:  addent -password -p HTTP/app.example.com@EXAMPLE.COM -k 1 -e aes128-cts-hmac-sha1-96
ktutil:  wkt /etc/krb5.keytab
ktutil:  quit

Then test with kinit -k -t /etc/krb5.keytab HTTP/app.example.com and klist -e to confirm you get an aes256-cts ticket.

How this ties into ERP systems bound to AD

Many organizations connect their ERP to Active Directory so staff use a single account (Single Sign-On). This change therefore directly affects ERPs running on Linux/Java that do Kerberos SSO. If the keytab your ERP uses contains only RC4 keys, users may be unable to log in on the day you update the DCs — impacting month-end closing, document approvals, and daily operations.

For Saeree ERP, we always recommend inspecting the keytab and encryption type of every AD-bound touchpoint before you update Windows. And if an organization wants to reduce its dependence on AD for authentication, Saeree ERP supports managing user permissions inside the system directly, by the organization's own administrators — adding users, setting them inactive, or defining a validity window (valid from–to) themselves. That gives you an option to control access without relying entirely on an external mechanism, consistent with defense-in-depth measures like two-factor authentication (2FA) that we use in real deployments. See the full picture on our technology & security page.

The key point is that this is not an ERP problem per se — it is an infrastructure-level change to Active Directory that any AD-dependent system must prepare for. Planning ahead and checking the Event Log is the safest approach.

"Retiring RC4 isn't a fix-and-forget patch — it closes a door many systems are still standing behind without realizing it. The organizations that check the Event Log and move to AES first are the ones that won't wake up to a downed system on Monday morning."

- Saeree ERP Security Team

References

• Microsoft Support — How to manage Kerberos KDC usage of RC4 for service account ticket issuance (CVE-2026-20833), Jul 2026