In This Article
A sysadmin on Reddit ran a quick PowerShell query last month and found 11 service accounts in their Active Directory environment still requesting RC4-encrypted Kerberos tickets. Accounts nobody had touched in years. Accounts tied to line-of-business applications, NAS devices, and a Java-based loan origination system. Every one of them will stop authenticating after April 14, 2026.
That Reddit post pulled 213 upvotes and dozens of comments from admins finding the same thing in their own environments. The top comment was blunt: "The failure mode is bad. Authentication just stops. If you have NAS devices, old line of business apps, or service accounts nobody has looked at in years, you'll find out when something stops working."
Microsoft's January 2026 security update (KB5073381) started the clock on a three-phase deprecation of RC4 encryption in Kerberos. Phase 1 was audit-only. Phase 2, shipping April 14, changes the default encryption to AES and disables the implicit RC4 fallback that has been silently protecting legacy accounts since Windows Server 2003. If your financial institution hasn't audited msDS-SupportedEncryptionTypes on every service account, you have days to fix what could become hours of downtime.
What CVE-2026-20833 Actually Changes
CVE-2026-20833 is a CVSS 5.5 information disclosure vulnerability in Windows Kerberos. The core problem: when a service account has no explicit msDS-SupportedEncryptionTypes attribute set, the Key Distribution Center (KDC) has been issuing RC4-encrypted service tickets by default. RC4 is a broken cipher. An attacker who captures those tickets can crack them offline through Kerberoasting, recovering the service account password without triggering a single alert.
The speed difference between cracking RC4 and AES tickets makes this more than an academic concern. Modern GPUs process billions of RC4 keys per second, turning weak passwords into plaintext in minutes to hours. AES-256 tickets are roughly a million times slower to crack on equivalent hardware, processing only thousands of keys per second. For any password longer than 7 or 8 characters, AES cracking is computationally infeasible with current hardware.
This isn't theoretical. In May 2024, Ascension Health, one of the largest hospital systems in the United States, was hit by ransomware after attackers cracked service account credentials through Kerberoasting using RC4 tickets. The breach disrupted 140 hospitals and exposed data from 5.6 million patients. U.S. Senator Ron Wyden pressed the FTC to investigate Microsoft's security defaults. Financial services organizations face similar exposure: 65% of financial institutions reported ransomware impact in 2024, with an average recovery cost of $5.9 million per incident. For a broader look at how attackers exploit vendor and identity weaknesses, see our analysis of the Marquis breach and what it teaches financial institutions about vendor risk.
The April 14 update changes one critical default: DefaultDomainSupportedEncTypes shifts from "RC4 is acceptable" to "AES-SHA1 only" (0x18). Every service account that was relying on the implicit RC4 fallback will now be treated as AES-only. If that account doesn't have AES key material (because its password was never reset after the domain functional level was raised to 2008 R2), authentication fails.
What Breaks on April 14
Service accounts with null msDS-SupportedEncryptionTypes that only have RC4 keys. NAS devices and SMB file shares using Kerberos keytabs exported with RC4 keys. FSLogix profile containers on SMB storage (Microsoft published a specific warning for VDI environments). Java, Tomcat, JBoss, and WebLogic applications with krb5.ini configured for RC4. Network printers with RC4-only Kerberos libraries. Legacy line-of-business applications with hardcoded RC4 Kerberos settings. Non-Windows devices (Linux and macOS clients with older Kerberos libraries) that only support RC4 in their Kerberos implementation.
The Three-Phase Timeline
Microsoft designed this rollout to give organizations time to find and fix RC4 dependencies before enforcement becomes permanent. The January update introduced nine new KDCSVC event IDs (201 through 209) in the System event log, each tracking a specific RC4 usage pattern. Events 201 and 202 are the audit-mode alerts that flag accounts still requesting or receiving RC4 tickets. Events 203 and 204 are the enforcement-mode versions that indicate a blocked authentication attempt.
The window between Phase 2 and Phase 3 is your safety net. During those three months, you can set the registry key RC4DefaultDisablementPhase to 1 on your domain controllers to revert to audit-only mode while you remediate remaining accounts. After July, there is no rollback.
KB5073381 ships with 9 new KDCSVC event IDs (201-209). The registry key RC4DefaultDisablementPhase is introduced. No authentication behavior changes. Organizations can monitor Events 201 and 202 to identify accounts still using RC4.
DefaultDomainSupportedEncTypes default changes to AES-SHA1 only (0x18). Implicit RC4 fallback is disabled. Events 201/202 become blocking errors 203/204. Manual rollback available via registry (RC4DefaultDisablementPhase = 1).
The RC4DefaultDisablementPhase registry key is removed. No rollback. Only accounts with RC4 explicitly set in msDS-SupportedEncryptionTypes can still use RC4, and Microsoft strongly discourages this.
The 15-Minute Audit That Prevents the Outage
You don't need a weekend maintenance window to find your RC4 dependencies. Microsoft published two PowerShell scripts in their Kerberos-Crypto GitHub repository specifically for this audit: List-AccountKeys.ps1 and Get-KerbEncryptionUsage.ps1. Combined with your Security event log, you can identify every affected account in 15 minutes.
Search Event IDs 4768 and 4769 for encryption type 0x17 (RC4-HMAC). Every match is a service account still requesting or receiving RC4 tickets. On domain controllers running the January update, also check the System log for KDCSVC Events 201 and 202, which flag these accounts directly with the service name and client IP.
Use the Active Directory PowerShell module to find service accounts where msDS-SupportedEncryptionTypes is null or includes the RC4 bits (0x4 or 0x8). Filter on accounts with a ServicePrincipalName set, since those are the accounts that receive Kerberos service tickets. Export the results so you have a remediation checklist. For a cloud-side parallel process, see our Entra ID security assessment with 7 PowerShell queries that catches similar identity drift in hybrid environments.
Identifies accounts that lack AES key material entirely. These accounts need a password reset before April 14, not just an attribute change. The script checks both user and computer accounts and flags any that would fail under the new AES-only default.
This tells the KDC to use AES128 + AES256. Set this on every service account identified in steps 1 through 3. The value 24 is the decimal equivalent of 0x18 (bits 3 and 4 set). Do not set this to 28 (0x1C) unless you specifically need RC4 fallback, because that keeps the vulnerability open.
Critical for accounts that predate the 2008 R2 domain functional level. A password reset generates AES key material. Without it, the attribute change alone won't work. Use a strong password (30+ characters, random) and consider migrating long-lived service accounts to Group Managed Service Accounts (gMSAs) that rotate automatically.
Non-Windows services (Java, Linux, NAS devices) need updated keytab files exported with AES encryption. Update krb5.ini to specify AES cipher suites. Re-export any keytab that was generated before the password reset, since the old keytab contains only the RC4 key hash.
After the April update, these events indicate blocked authentication attempts. Any new 203/204 events mean you missed an account. Check the event detail for the specific service name, client IP, and advertised encryption types so you can remediate quickly without rolling back the entire domain.
One critical edge case from the Reddit threads: service accounts that have never had a password change since before the domain functional level was raised to 2008 R2 are a special case. They have no AES key material at all. Setting msDS-SupportedEncryptionTypes on those accounts won't work. They need two sequential password resets to generate proper AES keys. The first reset generates the key material. The second ensures replication has propagated the new keys to all domain controllers. This is the kind of latent configuration drift that makes identity the new security perimeter for every financial institution running Microsoft 365.
What the Encryption Values Mean
The msDS-SupportedEncryptionTypes attribute is a bitmask. Each bit represents a specific encryption type. Getting the value wrong can leave accounts vulnerable or break authentication entirely. Here are the values you will encounter during this migration and what each one means in practice.
| Value (Decimal) | Value (Hex) | Encryption Types | Status After April 14 |
|---|---|---|---|
| 0 or null | 0x0 | Unset (defaults applied) | Breaks: default changes to AES-only |
| 4 | 0x4 | RC4-HMAC only | Breaks: RC4-only accounts fail |
| 8 | 0x8 | AES128 | Works: AES is accepted |
| 16 | 0x10 | AES256 | Works: AES is accepted |
| 24 | 0x18 | AES128 + AES256 | Works: recommended target value |
| 28 | 0x1C | AES128 + AES256 + RC4 | Works but keeps RC4 vulnerability open |
The recommended target value for all service accounts is 24 (0x18). This enables both AES128 and AES256 while excluding RC4. If you have a legacy application that genuinely cannot support AES, you can set the account to 28 (0x1C) as a temporary workaround. Microsoft has also set up the email address stillneedrc4@microsoft.com for organizations with devices that cannot support AES, to help plan a migration path. Any account left at 0x1C should be treated as a tracked exception with a documented remediation deadline.
When auditing your environment, use PowerShell's bitwise AND operator (-band) to check for RC4 bits. An account with msDS-SupportedEncryptionTypes containing bit 2 (0x4) or bit 3 (0x8 for RC4-HMAC-EXP) is advertising RC4 support. Filter with -band 0xC to catch both RC4 variants in a single query.
Test Before You Patch
The January 2026 update gave you a registry key that simulates enforcement before the April patch makes it the default. Set RC4DefaultDisablementPhase to 2 on a single domain controller in a test environment. This forces that DC to behave as if the April update is already installed: AES-only defaults, RC4 fallback disabled. Route a subset of your service accounts through that DC and monitor for authentication failures.
April 14 arrives. The patch auto-installs overnight. Monday morning, your loan origination system stops authenticating. FSLogix profiles on virtual desktops fail to load. A NAS device serving shared drives loses Kerberos access. Your help desk gets 40 tickets before 9 AM, and the root cause isn't obvious because the error messages say "authentication failed," not "RC4 was blocked."
You simulate enforcement on one DC in the lab. Within an hour, KDCSVC Events 203 and 204 identify three service accounts and a NAS device that need remediation. You fix the encryption attributes and reset passwords during a planned window. April 14 arrives, and nothing breaks because every account already has AES keys.
Microsoft's recommended testing procedure has five steps. First, deploy the January 2026 update to all domain controllers and monitor KDCSVC Events 201 through 209 for at least two weeks. Second, run the PowerShell audit from the previous section and remediate every account it flags. Third, set RC4DefaultDisablementPhase=2 on a test DC to simulate enforcement. Fourth, validate that all critical services still authenticate: SMB file shares, FSLogix profiles, printers, legacy applications, and any non-Windows devices with Kerberos integration. Fifth, once you confirm zero Events 203/204 across a full business cycle, you're ready for the April patch.
Pay special attention to FSLogix. Microsoft published a dedicated warning for VDI environments because FSLogix profile containers on SMB storage authenticate using the computer account's Kerberos credentials. If that computer account has null msDS-SupportedEncryptionTypes, profile loads will fail when the April patch changes the default. Every Azure Virtual Desktop host and Citrix server in your environment needs its computer account checked. Hardening checklists like our Microsoft 365 security checklist for credit unions include service account encryption review as a standing control so these gaps get caught before a Patch Tuesday forces the issue.
What Guardian Monitoring Catches
Running the 15-minute audit once fixes today's problem. But RC4 misconfigurations drift back. Someone creates a new service account and forgets to set the encryption attribute. A vendor deploys an application with legacy Kerberos settings. A password that hasn't been rotated in three years quietly loses its AES key material during a domain migration.
Guardian's continuous tenant monitoring checks 160+ security controls across every client's Microsoft 365 and Active Directory environment. The Kerberos encryption assessment is part of the standard 80-policy baseline that deploys across every client environment. When a service account starts requesting RC4 tickets, Guardian flags it before the next Patch Tuesday turns that configuration gap into an outage. The same monitoring foundation shows up in our Microsoft 365 security audit checklist for community banks, which walks through the controls examiners care about most.
After the April patch, Guardian monitors KDCSVC Events 203 and 204 across every domain controller. A single Event 203 means a client account tried to authenticate with RC4 and was blocked. A single Event 204 means a service account lacks AES keys and its ticket request was denied. Guardian surfaces both events with the affected account name, the source IP, and the encryption types that were advertised, giving your team enough detail to remediate without guesswork.
Partner Intelligence: Identity Is the #1 Attack Vector
78% of all ransomware incidents exploit Active Directory vulnerabilities, and 30% of all intrusions in 2024 involved stolen or abused credentials. Kerberoasting, the specific attack that RC4 enables, has been documented since 2014 but remains effective because most organizations never changed the default encryption type on their service accounts. The April 2026 enforcement finally closes this gap at the platform level, but only for organizations that prepare their service accounts in advance. For a deeper look at how credit union cybersecurity has to move beyond basic tooling to catch this class of attack, see our broader analysis.
Sources: Mandiant 2025 Threat Report; IBM X-Force Threat Intelligence Index 2025
Modern GPUs crack RC4 tickets at billions of keys per second. AES-256 tickets process at thousands per second on the same hardware. The migration doesn't just fix a CVE. It makes your service account credentials fundamentally harder to steal.
Frequently Asked Questions
Only for service accounts that rely on the implicit RC4 fallback and lack AES key material. Accounts with explicit msDS-SupportedEncryptionTypes set to include AES will continue working normally. The patch changes the default assumption, not the protocol itself.
Yes, during Phase 2 (April through July 2026). Set the registry key RC4DefaultDisablementPhase to 1 on your domain controllers to revert to audit-only mode. This rollback option is permanently removed in the July 2026 update.
Filter your Security event log for Event IDs 4768 and 4769 with encryption type 0x17 (RC4-HMAC). Microsoft also published two PowerShell scripts in their Kerberos-Crypto GitHub repository: List-AccountKeys.ps1 identifies accounts lacking AES key material, and Get-KerbEncryptionUsage.ps1 shows current encryption type usage across your domain.
The CVE-2026-20833 changes target on-premises Active Directory and hybrid environments where Kerberos is used for authentication. Pure cloud-only M365 authentication uses Entra ID (Azure AD) with modern protocols and is not directly affected. However, hybrid environments with on-premises domain controllers syncing to Entra ID are fully impacted.
You can explicitly set msDS-SupportedEncryptionTypes to include RC4 (value 28 or 0x1C) on that specific account. This is a temporary workaround and leaves the account vulnerable to Kerberoasting. Microsoft has also set up the email address stillneedrc4@microsoft.com for organizations with devices that genuinely cannot support AES, to help plan a migration path.
Yes, where possible. Group Managed Service Accounts (gMSAs) automatically rotate passwords on a 30-day cycle and always generate AES key material. They eliminate the risk of stale passwords and forgotten encryption attributes. Any Windows service that supports gMSAs should be migrated. Non-Windows services that rely on keytab files will still need manual keytab rotation, but the underlying AD account can still be a gMSA.
Is Your Tenant Ready for April 14?
ABT's tenant hardening process includes Kerberos encryption assessment across all service accounts, plus continuous monitoring that catches RC4 drift before the next patch cycle turns it into an outage. 750+ financial institutions trust ABT to keep their Active Directory secure.