Kerberos RC4 hardening: after 14 July 2026 rollback is no longer possible

RC4 has been cryptographically obsolete for over a decade. Yet it is still running in the background of many Active Directory environments, hidden inside service accounts that have not been updated in years, printers that only accept RC4 Kerberos tickets, or applications whose vendors never updated the encryption. On 14 July 2026 Microsoft removes the last emergency brake: after that date the option to fall back to audit mode no longer exists.

This is not a soft announcement. It is the endpoint of a process Microsoft started in January 2026 with CVE-2026-20833 and that now enters its final phase. IT teams that install this update without preparation can expect authentication failures on systems still dependent on the weak RC4-HMAC algorithm.

Three phases, one endpoint

Microsoft has phased out RC4 in Kerberos step by step. In the first phase, from 13 January 2026, audit events were activated. Domain controllers logged warnings every time a service ticket was requested using RC4. IT teams gained visibility into RC4 usage without anything breaking yet.

In the second phase, with the April 2026 updates, actual enforcement began. Domain controllers defaulted to AES-SHA1 for accounts where the msDS-SupportedEncryptionTypes attribute was empty or undefined. Through the registry key RC4DefaultDisablementPhase, administrators could temporarily switch back to audit mode if an environment was not yet ready. That safety valve disappears on 14 July.

After the July 2026 update, RC4DefaultDisablementPhase no longer functions as a working mechanism. Enforcement is permanent. RC4 will only work if explicitly configured on the affected account or on the KDC itself.

Why RC4 is an active attack vector

RC4 in Kerberos is not merely outdated; it is a concrete attack vector. Attackers with access to the network can request Kerberos service tickets encrypted with RC4, known as Kerberoasting. Because RC4-HMAC is cryptographically weak, these tickets can be cracked offline with relatively modest compute power. A service account with a weak password that issues RC4 tickets can be compromised within hours.

Accounts cracked through Kerberoasting are then used for lateral movement through the network, privilege escalation, or ransomware deployment. For attackers, an environment that still permits RC4 is a welcome gift. The hardening Microsoft is enforcing closes this attack vector structurally.

Which systems are at risk?

The greatest impact falls on service accounts where the msDS-SupportedEncryptionTypes attribute is empty or contains only RC4. Where no explicit value is set, the KDC determines the permitted encryption types based on the domain policy. Since the April update, the default value is 0x18, meaning AES128 and AES256. Accounts that only support RC4 and have not generated AES keys will no longer be able to receive valid tickets.

Beyond service accounts, older printers, scanners, NAS devices, and embedded systems are vulnerable. Devices that only understand RC4 Kerberos tickets and whose firmware has not been updated in years will experience authentication failures. The same applies to some Linux systems and third-party applications using non-Windows Kerberos implementations without AES support.

SQL Server is also noteworthy: in certain configurations it still uses RC4 for Kerberos authentication to the database engine. Environments that authenticate SQL Server via Kerberos must explicitly verify this.

How to detect RC4 usage before 14 July

As long as the July update has not been installed, RC4 usage can still be observed via the Windows Security event logs. Search for Event ID 4769, Kerberos Service Ticket Operations. The event details include the field Ticket Encryption Type. The value 0x17 corresponds to RC4-HMAC. Every 4769 log with that value represents a system or account that may encounter problems after 14 July.

Domain controllers also log specific Kdcsvc system events, identifiable as Event ID 202 and 207. These are generated when an RC4 ticket request is processed for an account without an explicit AES configuration. A search across all domain controllers for those event IDs yields a direct list of vulnerable accounts.

Microsoft has published the detection steps on Microsoft Learn under 'Detect and Remediate RC4 Usage in Kerberos'. Searching the Microsoft Learn library for that page title leads directly to the relevant documentation.

Remediation steps for service accounts

Remediation consists of two steps per affected account. First, the Kerberos keys must be renewed so that the account has AES keys in Active Directory. This is done by resetting the service account password, which automatically creates new Kerberos keys including AES128 and AES256. Next, set the msDS-SupportedEncryptionTypes attribute explicitly to 0x18 (AES128 + AES256) via ADSI Edit, PowerShell, or your Active Directory management tool.

The PowerShell command to set the attribute is: Set-ADUser -Identity 'accountname' -KerberosEncryptionType 'AES128,AES256'. For computer accounts, use Set-ADComputer with the same parameter. For service accounts managed via gMSA (Group Managed Service Accounts), key renewal happens automatically because gMSA passwords are rotated periodically.

Note that a password reset for production service accounts must always be coordinated with the application teams. Services configured with the account must be updated with the new password or service identity. Plan this outside production hours.

Legacy devices and explicit RC4 permission

For devices and applications that technically cannot support AES Kerberos and for which no firmware or software update is available, Microsoft offers a temporary workaround: set the msDS-SupportedEncryptionTypes attribute to 0x24. This value combines AES with RC4 for session keys, which some older implementations require to function. This is not a desired situation but prevents production systems from entering an unrecoverable failure state.

Be aware of the implications: an account with explicitly permitted RC4 is a weaker account from an attacker's perspective. Ensure such accounts are monitored, that their passwords are long and complex, and that they are included in your inventory for future migration once the vendor releases an AES update.

What you need to do this week

With Patch Tuesday on 14 July, there are five working days left. Three concrete actions IT teams should prioritise now. First, run the Event ID 4769 query across the security logs of all domain controllers covering the past thirty days and export all accounts with Ticket Encryption Type 0x17. Second, check the msDS-SupportedEncryptionTypes value for each account found and reset the password if no AES keys exist. Third, create a list of legacy devices that may require RC4 and configure their service accounts with value 0x24 as a temporary measure.

Installing the July update without completing these checks is not a risk worth taking. An authentication failure on a critical system in the middle of a working day costs more time than a preventive check right now. Organisations that want support carrying out the RC4 audit or remediating service accounts are welcome to contact Zarioh.