If you're reading this, you're probably in one of two situations.
You applied the April 2026 cumulative update, something broke, and you either rolled back or you're still diagnosing. Or you watched what happened to other organizations, decided to hold the patch, and now you're sitting on an undeployed update wondering how long you can wait.
Both situations are understandable. Both are getting more expensive every week.
What the April Update Actually Changed
The April 14, 2026 cumulative update (KB5082063 for Windows Server 2025, with equivalent KBs for Server 2022, 2019, and 2016) implemented Phase 2 of Microsoft's Kerberos RC4 hardening under CVE-2026-20833. The change was to the KDC's compiled-in default authentication behavior. Per Microsoft: "RC4 will no longer be implicitly accepted by the KDC."
Accounts without AES long-term key material in the KDC began failing authentication, regardless of what their msDS-SupportedEncryptionTypes attribute showed. Service accounts were hit hardest, precisely because service account passwords rarely rotate. A service account created in 2019, authenticating daily via RC4, broke on April 14 because the AES keys that would have been generated at password change had simply never been generated.
Per Microsoft AskDS: "During a password change, new keys are generated automatically with all the available Kerberos Encryption Types." Logging in every day does not generate AES keys. Only 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 your DCs to Phase 1, RC4 permitted again with warning events logged. The April update remains installed. Your broken service accounts are authenticating.
Here is the honest picture of what that fixed and what it did not.
The rollback resolved the immediate authentication failures. Users can log in, services are running, the help desk calls stopped. What it did not fix is the RC4 exposure that caused the break in the first place. Every account that failed in April is still operating on RC4 key material only. The Kerberoasting risk that existed before April still exists today.
There is also a specific failure type the rollback cannot address at all. When a client requests RC4 for an account that already has AES keys, the KDC issues an AES ticket instead, per the Kerberos protocol specification. The client cannot decrypt it. The application fails silently with no Kerberos error code and no obvious log entry. If your team is still seeing application failures after rolling back, this is almost certainly why. The rollback restores RC4 issuance for accounts with no AES keys. It does not restore implicit RC4 acceptance for accounts that already have them.
The bigger problem: the RC4DefaultDisablementPhase registry key will not exist after the July 14 update. Per Microsoft: "On installing the July 2026 Windows Cumulative Updates, the behavior will be identical to April 2026, however you will no longer roll back to audit mode." That key is removed by the July update. You have used your last Phase 1 rollback. July will look exactly like April, with no registry key to pull you back.
You also now have a documented list of exactly which accounts broke in April. That is genuinely useful information, but only if you act on it. Every week you wait is a week that list sits unused while the July deadline closes in.
If You're Holding the April Patch
Not deploying the April update is a position that gets harder to justify with each passing week, for four compounding reasons.
Your domain controllers are still operating with RC4 as a permitted fallback. Service accounts with RC4-only key material are Kerberoastable today. An attacker who captures an RC4 Kerberos service ticket can attempt offline password cracking at speeds that make moderately complex passwords vulnerable within hours on commodity hardware. Kerberoasting is not a theoretical risk; it is an actively documented technique in credential-based breaches.
April Patch Tuesday bundled the RC4 hardening change with security fixes for other Windows components. Those CVE details went public on release day. Security researchers have had a month to analyze them. Every day you remain unpatched is another day those vulnerabilities sit open in your DC estate.
May Patch Tuesday has also shipped since April. If you held the April patch and held May as well, you are now two months behind on cumulative Windows security updates across your domain controllers, which are the most sensitive systems you operate.
July 14 is a hard wall. The July cumulative update makes the April behavior permanent and removes the rollback option. It bundles another set of publicly disclosed CVEs. If you are not RC4-ready by then, you face the same choice you avoided in April: apply the update and break things, or hold it and continue accumulating exposure. The difference is that in July there is no registry key to fall back on.
Why the Rollback Was the Wrong Response
When a security update causes operational disruption, the instinct is to delay it. The problem is that the disruption from the RC4 change does not go away by waiting. It is identical in July. What does accumulate is the security debt from everything else bundled in April, May, and June patches that you have not applied.
The correct response to the April patch breaking things was to roll back, identify which accounts broke and why, remediate those accounts, and redeploy the patch. That is the sequence that gets an organization current on patching without sacrificing operational continuity. Most organizations skipped it because it requires knowing which accounts lack AES key material, which service account passwords need to be rotated in coordination with application owners, and what order the fixes need to happen in to avoid breaking authentication again mid-remediation. That work is harder than rolling back. It is also the only work that actually solves the problem.
What Clean April Deployments Had in Common
The organizations that applied the April update without authentication failures shared one characteristic: they knew which accounts were at risk before the update shipped.
They had confirmed AES key presence from KDC event evidence, not inferred it from AD attributes. They had mapped service account dependencies before rotating any passwords. They had rotated KRBTGT with the required two-pass rotation. They had verified the AZUREADSSOACC$ account if they were running Entra Seamless SSO. They had confirmed per-DC enforcement state before deployment.
None of this is complicated in retrospect. All of it requires knowing the actual state of your KDC credential store per account, not what the attributes say, but what the KDC will actually do when the account tries to authenticate.
The Remediation Sequence
Whether you rolled back, held the patch, or applied it and are still seeing intermittent issues, the sequence is the same.
Start by identifying every account that needs remediation. If you rolled back, you already have a partial list from what broke in April. If you held the patch, you need to build it from scratch. The right method combines KDCSVC event data from every DC during the audit window with password-age tier analysis to catch the silent population, the accounts that never appeared in event logs because they authenticate infrequently, but will still fail in July.
Before touching any service account, map what depends on it. Every application, scheduled task, IIS application pool, and Windows service that authenticates against that account needs to be identified before a password rotation happens. Rotating without this mapping breaks everything that depends on the account simultaneously. This step takes longer than anything else and cannot be skipped.
Remediate service accounts first, setting explicit encryption attributes and coordinating password rotations with application owners. KRBTGT second, two rotations with a minimum 10-hour wait between them. The wait is for existing tickets to expire, not for replication; verify replication separately. AZUREADSSOACC$ requires running Update-AzureADSSOForest, not just an AD password change. User accounts with passwords predating the AES crossover date come last.
Once remediated, confirm AES key presence from KDC event evidence for every account before redeploying the April update. Setting the attribute is not verification. What the KDC reports about available keys is. Then deploy updates in sequence and get current before July 14.
The Window
Today is May 14, 2026. July 14 is 61 days away.
That is enough time to do this correctly if you start now. It is not enough time if the next month is spent deciding whether to start.
The Case for Outside Help
Building the queries, correlating the data sources, mapping service dependencies, sequencing the fixes, and producing documentation your compliance team and insurers will actually accept takes weeks of skilled AD engineering time. Most teams do not have that bandwidth spare between now and July 14 alongside everything else they are managing.
The question is not whether your team is capable. It is whether they have the hours, and whether the output will meet the standard that auditors and underwriters require. A PowerShell export does not satisfy either. A dated, third-party assessment report with per-account findings does.
Take the 2-minute RC4 Self-Assessment to see where your environment stands: https://www.presidetech.com/rc4-assessment/rc4-self-assessment/
Learn about the full RC4 Deprecation Assessment: https://www.presidetech.com/rc4-assessments/
Our team includes a Microsoft Enterprise Strategy Consultant who advised Fortune 50 organizations and worked directly with Microsoft product and engineering teams to help scale and improve identity and security products. The assessment delivers per-account findings, dependency mapping, and a sequenced remediation plan your team can execute rather than research.
PresideTech partners with enterprises, MSPs, and MSSPs to lead transformative technology changes. All technical claims are sourced to primary Microsoft documentation: KB5021131, KB5082063, Microsoft AskDS (January 26, 2026), Microsoft TechCommunity "Kerberos and the End of RC4" (March 14, 2026). CVE-2026-20833 documentation available via Microsoft Security Response Center.