The April 14, 2026 cumulative update changed Kerberos authentication behavior across every fully patched Windows domain controller. The Microsoft TechCommunity thread documenting post-patch failures received hundreds of responses within days. The r/sysadmin community generated 370+ comments. Engineers who thought they understood what changed are still diagnosing failures weeks later.
Most of the guidance published so far describes what broke. This post explains why - including a failure mode that generates no error code for the application to retry against and that continues to affect environments even after rolling back to Phase 1.
If your team is spending hours diagnosing Kerberos failures, correlating event logs across domain controllers, and trying to figure out why some applications are still broken after the rollback, this is the precise technical answer.
What the April 14 Update Actually Changed
The April 14, 2026 cumulative update implemented Phase 2 of CVE-2026-20833. The change is to the KDC's compiled-in default behavior - the encryption types it assumes when no explicit override has been set. Before the April patch, the compiled default permitted RC4 as a fallback. After the April patch, the compiled default is AES-only.
This is controlled by DefaultDomainSupportedEncTypes at HKLM:\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\Parameters. In most environments this key will not be explicitly set — the KDC uses its compiled-in default based on the installed cumulative update. Any explicitly set value is a red flag regardless of what it contains. It masks the true account-level encryption state, creates a hidden domain-wide dependency, and causes confusion during future remediation and audits. The correct remediation for RC4 exposure is always at the account level via msDS-SupportedEncryptionTypes, not a domain-wide registry override.
Before April 14, the KDC permitted RC4 as an implicit fallback for any account without explicit encryption type configuration. Per Microsoft's March 14, 2026 TechCommunity post: "RC4 will no longer be implicitly accepted by the KDC." This is not a change to whether RC4 exists as a cipher. It is a change to the KDC's default behavior when an account's msDS-SupportedEncryptionTypes attribute is not explicitly set, which describes the majority of accounts in most enterprise environments.
Microsoft refers to this overall change as Kerberos RC4 hardening. Understanding exactly what was hardened - and what wasn't - determines whether your remediation targets accounts, applications, or both.
The Two Distinct Failure Modes - And Why One Is Completely Invisible
This is where most published guidance falls short. There are two completely different failure modes after April 14. They look similar from the surface but require entirely different remediation, and treating them the same wastes weeks of effort while leaving environments partially broken.
Failure Mode A: Silent Ticket Substitution
This is the failure mode most organizations encountered first and found hardest to diagnose. It also continues after rolling back to Phase 1, which is why some environments are still partially broken weeks after the rollback.
Per RFC 4120, the Kerberos protocol specification, the KDC follows this rule: "the KDC SHOULD use the first valid strong etype for which an encryption key is available." The KDC does not simply honor whatever the client requests. After April 14, when a client requests an RC4 Kerberos ticket for a service account that has AES key material in the KDC, the KDC does not reject the request - it issues an AES-encrypted ticket instead.
The client receives a ticket it did not expect. It attempts to decrypt using its RC4 decryption capability. Decryption fails. The application logs a generic authentication error with no Kerberos error code. Without an explicit failure signal, most applications have no mechanism to trigger a retry. Legacy systems, appliances, and embedded devices virtually never do.
Event 201 fires at the domain controller, but it is worth understanding why it gets missed in almost every post-incident review. Event 201 is classified as a Warning, not an Error. Engineers scanning event logs for authentication failures filter for errors and never see it. The DC logs it as a successful ticket issuance - because from the KDC's perspective, it was. The failure happens entirely on the client side, in a layer the DC has no visibility into. This is what makes Mode A genuinely invisible at the infrastructure layer: the DC is healthy, the event log shows a warning that looks like an informational note, and the application is broken for a reason that appears nowhere in the Kerberos audit trail.
Common sources of Mode A failures include legacy NAS devices and storage appliances with Kerberos authentication, older Java applications with default_tkt_enctypes = rc4-hmac set in krb5.ini, network printers using Kerberos, Linux and Unix systems with keytab files containing only RC4 key material, and RADIUS or 802.1X implementations with hardcoded RC4 negotiation.
Failure Mode B: Explicit KDC Rejection
This is the failure mode most documentation describes and it is the more straightforward one to diagnose.
When an account has no AES key material in the KDC credential store -meaning its password has never been changed on a patched domain controller - the KDC cannot issue an AES ticket because the keys simply do not exist. In this case the KDC returns KDC_ERR_ETYPE_NOSUPP, a defined Kerberos protocol error code. A well-written Kerberos client can receive this error, update its encryption type list, and retry. Most legacy applications, appliances, and embedded systems do not implement this retry logic and fail permanently.
Event 203 fires at the domain controller, indicating the account has no AES keys.
Mode B affects service accounts with passwords that have never been changed on a domain controller running the November 2022 or later cumulative updates, regardless of how recently the account last authenticated. It also affects admin accounts configured with "password never expires" whose passwords predate patched DCs being in place, and any account that appears active and healthy in AD but whose password was set before AES key generation was possible in the environment.
The Critical Distinction
The table below shows why getting this wrong wastes remediation effort. Mode A and Mode B look similar from a help desk ticket but require completely different fixes.
That last row explains something important. If your team rolled back to Phase 1 after April and applications are still broken, that is Mode A. The rollback resolved Mode B by allowing RC4 again for accounts with no AES keys. It did not touch Mode A at all, because Mode A affects accounts that already have AES keys — the KDC is doing exactly what it is supposed to do. The remediation target is the application, not the account.
What Rolling Back to Phase 1 Actually Restores
Many organizations rolled back from April enforcement by setting RC4DefaultDisablementPhase = 1 at HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\Kerberos\Parameters. Per KB5073381, value 1 means warning events are logged on default RC4 usage — the KDC permits RC4 but generates KDCSVC warning events. This is the supported rollback mechanism, but it does not return the environment to its pre-April state.
The rollback restores RC4 ticket issuance for accounts with no AES key material, which means Mode B accounts are no longer rejected and can authenticate again. KDCSVC warning events continue to accumulate, which is useful audit evidence.
What it does not restore is implicit RC4 acceptance for accounts that already have AES keys. Those accounts still receive AES tickets per the KDC's compiled-in default. Mode A failures - applications receiving AES tickets they cannot decrypt - continue regardless of the Phase 1 rollback state. The pre-April compiled default behavior is not coming back.
What July 14, 2026 Actually Changes
July 14, 2026 does not introduce new or stricter enforcement behavior. Per Microsoft's AskDS engineering blog: "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."
July 14 enforcement behavior is identical to April 14. What changes is that RC4DefaultDisablementPhase is removed by the July update entirely. Setting it to 1 will no longer return DCs to Phase 1. Per Microsoft: "RC4 will only function if explicitly configured" per account via msDS-SupportedEncryptionTypes.
Explicitly re-enabling RC4 per account after July 14 remains technically possible, but it constitutes a deliberate security regression. In regulated environments - HIPAA, PCI-DSS, SOC 2, CMMC - that explicit per-account RC4 configuration is a compliance finding. For organizations with cyber insurance, it is precisely the kind of known-vulnerability re-enablement that coverage exclusion language is written to address.
The urgency of July 14 is not about new behavior. It is about the permanent removal of RC4DefaultDisablementPhase - the mechanism organizations used to roll back in April.
Why AES Keys Are Not Generated by Logging In
This is the most common source of confusion in post-April diagnostics.
Per Microsoft AskDS: "During a password change, new keys are generated automatically with all the available Kerberos Encryption Types." This confirms password change as the AES key generation trigger. Microsoft does not explicitly state that interactive logon generates AES keys - the AskDS documentation describes password change as the mechanism, with no equivalent statement for logon events.
An account that authenticates daily, shows a recent last-logon date, and appears completely healthy in Active Directory may have no AES key material at all if its password has never been changed on a patched domain controller. This is why so many service accounts failed in April. They were authenticating every day via RC4, the environment looked fine, and the April update exposed a gap that had been silently accumulating for years.
What This Means for IT Leadership
If you are responsible for IT infrastructure, security, or compliance in an organization with Active Directory, the April 14 update created a situation your team may not have the bandwidth or tooling to fully diagnose on their own.
The problem is not simply finding which accounts need remediation. It is distinguishing Mode A from Mode B failures, which requires correlating Event 201 and Event 203 data across every DC against application failure events. It is confirming AES key presence from KDC event evidence rather than inferring it from AD attributes, which show configuration intent but not what the KDC will actually do. It is mapping service account dependencies before rotating any passwords, because rotating a service account without knowing what depends on it breaks the application. And it is producing documentation that satisfies compliance auditors and cyber insurance underwriters - not a CSV export, but a dated report with per-account findings and methodology.
Your team is capable of this work. The question is whether the time required to do it correctly is time they have between now and July 14.
Know Exactly Where You Stand
Our 2-minute RC4 Self-Assessment surfaces your specific risk profile without requiring hours of internal investigation.
Start with the self-assessment: https://www.presidetech.com/rc4-assessment/rc4-self-assessment/
If the results indicate deeper exposure, our full RC4 Deprecation Assessment delivers per-account AES key presence confirmed from KDC event evidence, Mode A and Mode B failure identification, service account dependency mapping, and a sequenced remediation plan - delivered as a dated, audit-ready report your compliance team and insurer can use. 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 - bringing deep experience leading large-scale transformative changes across enterprise and regulated environments.
Learn about the full RC4 Deprecation Assessment: https://www.presidetech.com/rc4-assessments/
PresideTech partners with enterprises, MSPs, and MSSPs to lead transformative technology changes - from complex infrastructure migrations to identity and security modernization. Technical claims in this post are sourced to primary Microsoft documentation: KB5021131, Microsoft AskDS (January 26, 2026), Microsoft TechCommunity "Kerberos and the End of RC4" (March 14, 2026), and RFC 4120. CVE-2026-20833 documentation is available via the Microsoft Security Response Center.
You must be logged in to post a comment.