If You Delayed or Rolled Back the April 2026 Kerberos Patch: What It Meant

Organizations that faced the April 2026 Windows cumulative update ended up in one of two positions.

Some installed the update, hit failures, and either rolled back or kept diagnosing. Others held it.

Both positions were understandable. Each carried a different kind of exposure, and this post covers both.

What the April Update Changed

The April 14, 2026 cumulative update (KB5082063 for Windows Server 2025, with equivalent updates for other supported server versions) implemented Phase 2 of Microsoft’s Kerberos RC4 hardening under CVE-2026-20833. The change was to the default authentication behavior of the Key Distribution Center (KDC), the Kerberos service on each domain controller, for accounts without an explicit encryption type. The April 14 post covers the change in detail, including Microsoft’s March 14, 2026 statement that RC4 would no longer be implicitly accepted by the KDC.

Accounts without AES long-term key material in the KDC could fail authentication, regardless of what their msDS-SupportedEncryptionTypes attribute showed. Service accounts were the most exposed, because service account passwords rarely rotate. A service account created before AES-SHA1 support whose password was never reset could break on April 14 because it had no AES keys, even if it authenticated daily via RC4.

Microsoft AskDS says: “During a password change, new keys are generated automatically with all the available Kerberos Encryption Types.” Microsoft does not state that logging in generates AES keys. A password change on a patched domain controller does.

If You Rolled Back

Setting RC4DefaultDisablementPhase = 1 at HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\Kerberos\Parameters returned domain controllers to Phase 1, where RC4 was permitted again with warning events logged. The April update stayed installed, and the affected service accounts could authenticate again.

The rollback resolved the failures caused by missing AES keys. It did not resolve the second failure type, described below. It also did not fix the RC4 exposure behind the first one. Every account that failed because it lacked AES keys was still on RC4-only key material. The Kerberoasting exposure that existed before April still existed after the rollback. Kerberoasting is an attack in which someone captures a service ticket and cracks the account password offline.

There was also a specific failure type the rollback could not address. When a client requests RC4 for an account that already has AES keys, the KDC issues an AES ticket instead, per RFC 4120. The application rejects it and fails with no Kerberos error code. The domain controller records only a warning event. If a team was still seeing application failures after rolling back, this was a likely reason. The rollback restored RC4 issuance for accounts with no AES keys. It did not restore implicit RC4 acceptance for accounts that already had them.

The rollback also had an end date. Microsoft’s documentation said: “The Windows updates released in or after July 2026 will remove support for the registry subkey RC4DefaultDisablementPhase.” Microsoft’s AskDS blog added that, after the July updates, behavior would match April but without the roll back to audit mode. That meant the Phase 1 rollback was available only until the July updates, which Microsoft scheduled for July 14, 2026.

Teams that rolled back also had a list of the accounts that broke in April. That list showed which accounts needed AES keys or explicit configuration.

If You Held the April Patch

Holding the April update left a different kind of exposure.

Domain controllers that did not receive the update kept RC4 as a permitted fallback. Service accounts with RC4-only key material stayed exposed to Kerberoasting. Microsoft’s documentation describes this attack and says changing the default to AES-SHA1 helps protect against it.

The April cumulative update also carried other fixes, so holding it meant holding those as well. Because cumulative updates stack, an organization that held April could not take later updates without taking the RC4 change with them.

Microsoft scheduled the July 2026 update to remove the rollback option. An organization that had not remediated by then faced the same choice it avoided in April: install the update and risk failures, or hold it and keep accumulating exposure.

Why Rolling Back Was a Partial Fix

When a security update caused operational disruption, the instinct was to delay it. The disruption from the RC4 change did not go away with waiting, because Microsoft scheduled the change to become permanent in July.

A more durable sequence was to roll back if needed, identify which accounts broke and why, remediate those accounts, and redeploy the patch. That sequence got an organization current on patching without sacrificing operational continuity. It also took more work than rolling back. It required knowing which accounts lacked AES key material, which service account passwords needed to be rotated in coordination with application owners, and what order the fixes had to happen in so that authentication did not break again mid-remediation.

What a Clean April Deployment Needed

A deployment was more likely to go cleanly when the team knew which accounts were at risk before the update shipped.

That meant confirming AES key presence from KDC event evidence, not inferring it from AD attributes. It meant mapping service account dependencies before rotating any passwords, rotating the KRBTGT account twice (the account the KDC uses to protect tickets), verifying AZUREADSSOACC$ (the account Microsoft Entra Seamless SSO uses) in environments that run it, and confirming per-DC enforcement state before deployment.

All of it depends on knowing the state of the KDC credential store per account. The attributes do not show it. The KDC’s behavior when the account authenticates does.

The Remediation Sequence

Whether a team rolled back, held the patch, or applied it and kept seeing intermittent issues, the sequence was the same.

The first step was to identify every account that needed remediation. Teams that rolled back had a partial list from what broke in April. Teams that held the patch had to build it from scratch. A sound method combined KDCSVC event data from every DC over a long enough period with password-age analysis. That caught the silent population: accounts that authenticate infrequently, never appeared in event logs, and would have failed once enforcement applied.

The second step was to map what depended on each service account before touching it. Every application, scheduled task, IIS application pool, and Windows service that authenticates against that account had to be identified before a password rotation. Rotating without this mapping can break everything that depends on the account at once. This step usually took longer than any other.

Service accounts were remediated first, with explicit encryption attributes set and password rotations coordinated with application owners. KRBTGT came second, with two rotations and a wait between them at least as long as the maximum ticket lifetime (10 hours by default). The wait is for existing tickets to expire, not for replication, so replication was verified separately. AZUREADSSOACC$ required running Update-AzureADSSOForest, not just an AD password change. User accounts with passwords that predated AES support came last.

Once remediated, the last step was to confirm AES key presence from KDC event evidence for every account before installing a current cumulative update. Setting the attribute was not verification. What the KDC reported about available keys was.

Sources

• Microsoft: Managing Kerberos KDC usage of RC4 (CVE-2026-20833, KB5073381)
• Microsoft: KB5082063, April 14, 2026 cumulative update for Windows Server 2025
• Microsoft TechCommunity: Phase 2 of Kerberos RC4 hardening (April 2026)
• Microsoft TechCommunity: Kerberos and the End of RC4 (March 14, 2026)
• Microsoft AskDS: What is going on with RC4 in Kerberos
• Microsoft Learn: Detect and Remediate RC4 Usage in Kerberos
• RFC 4120: The Kerberos Network Authentication Service (V5)
• MITRE ATT&CK T1558.003 Kerberoasting