Kerberos RC4 Is Gone: What Microsoft’s July 2026 Deadline Means for Mobile SSO

Lukas Schönbächler · July 2026 · 7 min read

In June we walked through Microsoft’s plan to disable NTLM and what it does to mobile fleets. NTLM is not the only legacy authentication Microsoft is dismantling in 2026. The other one, RC4 encryption inside Kerberos itself, just reached its point of no return: with the July 2026 cumulative update, the last escape hatch is permanently removed. Here is what changed, why it matters for Kerberoasting, and where it can quietly break mobile single sign-on.

What changed on July 14, 2026

This is the final phase of a rollout Microsoft started in January 2026 in response to CVE-2026-20833, documented in KB5073381:

• January 13, 2026 (Phase 1): Domain controllers start logging audit events (Kdcsvc events 201 to 209 in the System log) whenever a ticket depends on RC4. The RC4DefaultDisablementPhase registry value under HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\Kerberos\Parameters is introduced so admins can opt into enforcement early.
• April 14, 2026 (Phase 2): The default domain cipher suite flips to AES-SHA1 only (0x18). Accounts with no explicit encryption types set stop getting RC4 tickets. Anything that broke could be rolled back to audit mode via the registry value.
• July 14, 2026 (Phase 3): The rollback value is removed and no longer read. Enforcement is permanent.

Microsoft’s AskDS engineering team put it plainly: “On installing the July 2026 Windows Cumulative Updates, the behavior will be identical to April 2026, however you will no longer be able to roll back to audit mode.” RC4 now only works for accounts where it is explicitly set in msDS-SupportedEncryptionTypes, a per-account exception Microsoft explicitly discourages.

Figure 1: The three-phase RC4 removal. Since July 14, 2026 there is no domain-wide way back to RC4.

Why RC4 had to die: Kerberoasting

The attack that killed RC4 is Kerberoasting. Any authenticated domain user, no elevated privileges required, can request a Kerberos service ticket for any account with a service principal name (SPN). That ticket is encrypted with the service account’s key, and the request triggers no alert. The attacker takes the ticket offline and brute-forces the password out of it.

The cipher decides whether that attack is practical. An RC4-HMAC ticket is encrypted with a key derived directly from the account’s NT password hash, which commodity GPUs attack at enormous speed; moderately complex passwords fall within hours. AES keys are derived through PBKDF2 with thousands of iterations and a salt, slowing the same attack by orders of magnitude. A service account with RC4-only key material can be cracked offline at leisure, and service accounts tend to come with broad access.

There is a compliance angle too: NIST SP 800-131A disallowed RC4 back in 2016, PCI-DSS 4.0 requires documented remediation plans for weak ciphers, and cyber insurers have started asking about Kerberos encryption posture in 2026 renewal questionnaires.

Two removals, one playbook

If the pattern feels familiar, it should. The RC4 removal follows the same three-step playbook as the NTLM removal: audit events first, defaults flipped second, escape hatch deleted last. RC4 just ran the whole cycle in six months. Treat it as the dress rehearsal for what NTLM enforcement will feel like.

	NTLM removal	Kerberos RC4 removal
Audit phase	Events 4020 / 4022 / 4032 (Win 11 24H2, Server 2025)	Kdcsvc events 201 to 209 (January 2026)
Default flip	BlockNTLMv1SSO to Enforce, October 2026 (KB5066470)	AES-only default (0x18), April 14, 2026
Escape hatch	Group Policy re-enable (until next LTSC)	RC4DefaultDisablementPhase registry key
Point of no return	Next Windows Server LTSC (projected 2027)	July 14, 2026: key removed
Typical casualties	Mobile devices, workgroup and legacy clients	Service accounts, printers, appliances, third-party apps
Detection	Event 8003 / 4022 on app servers	Event 4769 with ticket encryption type 0x17
Fix for mobile flows	PKINIT certificates through your MDM	AES key material on the accounts behind your apps

What this means for mobile Kerberos SSO

A mobile Kerberos flow has two halves. First the device obtains a ticket-granting ticket (TGT) for the user. This half is fine. Hypergate Authenticator negotiates AES by default, so there is no app update, no managed-configuration change, and nothing to prepare on the device for this deadline. The one exception: if you ever forced legacy ciphers through a custom Kerberos configuration, remove that override as part of this cleanup. Then, for every internal application the user opens, the device requests a service ticket for that app’s SPN, and that ticket is encrypted with the service account’s key.

That second half is where July 14 bites. If the account fronting your intranet, your on-premises SharePoint, or a line-of-business API only has RC4 key material, the KDC can no longer issue a ticket for it. The app returns 401 in a loop. The user experience is identical to an NTLM block, which is exactly why this is easy to misdiagnose: teams that recently migrated mobile from NTLM to Kerberos will suspect the migration, when the actual culprit is an AD account whose password was last set in 2009.

One distinction narrows the search considerably. SPNs registered on computer accounts are usually fine: machine accounts rotate their passwords every 30 days and generated AES keys long ago. The exposure concentrates on user-type service accounts, the kind typically behind SAP, legacy web apps, or an IIS application pool that was configured once and never touched again. Their keys only refresh when the password changes, and for some of these accounts that has never happened.

Figure 2: The device gets its AES TGT without issue. The break happens one step later, when the service ticket for an app’s SPN depends on a service account that never got AES keys.

Find your RC4 dependencies

Two places tell you where you stand. On domain controllers, the System event log carries the Kdcsvc events from KB5073381: 201 and 202 are the audit warnings, 203, 204, 208 and 209 mean a ticket was actually refused. In the Security log, event 4769 with ticket encryption type 0x17 identifies every service ticket still issued with RC4 (AES256 shows as 0x12).

On the directory side, list every account that carries an SPN and check its encryption types:

# All service accounts (SPN set) and their Kerberos encryption types
Get-ADUser -Filter 'ServicePrincipalName -like "*"' `
    -Properties ServicePrincipalName, msDS-SupportedEncryptionTypes |
    Select-Object Name,
        @{N='EncTypes';E={'0x{0:X}' -f [int]$_.'msDS-SupportedEncryptionTypes'}},
        @{N='SPNs';E={$_.ServicePrincipalName -join ', '}}

Reading the values: 0x18 means AES only, which is the new default and where you want to be. 0x4 means RC4 only, which stopped working on July 14. 0x0 (never set) now defaults to AES, but only helps if the account actually has AES keys; accounts whose password predates the domain’s move to Windows Server 2008 functional level never generated them. 0x24 is the documented interoperability fallback (RC4 with AES session keys) and should be treated as temporary.

The fix: AES keys, not exceptions

For every account the audit surfaces, the fix is the same and takes minutes:

1. Reset the account password. A password reset generates fresh key material, including the missing AES keys. This is the whole fix for most accounts.
2. Set msDS-SupportedEncryptionTypes to 0x18 on critical service accounts so the configuration is explicit rather than inherited from a default.
3. Verify from the mobile side. Open the Kerberos-protected apps your fleet uses and confirm 4769 events now show encryption type 0x12 for their SPNs.
4. Where you own the service, consider a gMSA. Group Managed Service Accounts rotate 240-character random passwords automatically, carry AES keys by design, and leave no human-chosen password for an attacker to crack.

What you should not do is scatter per-account RC4 exceptions. Every exception recreates the exact Kerberoastable target this whole exercise removes, and Microsoft’s guidance is explicit that the exception path is a last resort for legacy appliances, not a migration strategy.

Where this leaves you

The direction is one-way: RC4 lost its rollback in July, NTLMv1 gets blocked in October (KB5066470), and network NTLM goes dark with the next Windows Server LTSC. Every step lands in the same place, which is Kerberos with AES and, increasingly, certificates instead of passwords. For mobile fleets the good news is that a PKINIT-based setup already speaks AES end to end, so the remaining work is Active Directory hygiene on the accounts behind your apps. Audit the 4769 encryption types now and reset the stragglers, and the next legacy-protocol deadline will pass without anyone noticing.

---