RC4 Deprecation (CVE-2026-20833)¶
This page covers the technical details of how RC4 is selected, what each control does, the enforcement phase behavior, and what you need to be true before enforcement is safe. For the step-by-step migration commands, see the AES Standardization Guide.
Why RC4 Is Being Removed¶
RC4 has been a known liability in Kerberos for over a decade:
- Kerberoasting: any authenticated domain user can request a service ticket for any SPN and crack it offline. AES tickets can be cracked but require enormous compute time with a strong password. RC4 tickets crack at roughly 800x the speed of AES — a weak password falls in hours. See Kerberoasting.
- Key = NTLM hash: the RC4 Kerberos key is derived identically to the NTLM hash. Compromising one gives the attacker both.
- No salt: RC4 keys are unsalted MD4 hashes. Rainbow tables work. AES keys are salted with 4,096 PBKDF2 iterations per account, making precomputation infeasible.
- Stream cipher weaknesses: RFC 7465 banned RC4 from TLS in 2015. RFC 8429 deprecated it for Kerberos in 2018.
Despite all this, RC4 remained the implicit default for any SPN-bearing account without an explicit msDS-SupportedEncryptionTypes value until April 2026.
Historical Context¶
| Date | Change | Reference |
|---|---|---|
| November 2022 | KDC defaults to AES session keys. Introduces AES256-CTS-HMAC-SHA1-96-SK flag and DefaultDomainSupportedEncTypes. |
KB5021131 |
| January 2025 | New fields in Events 4768/4769: Advertized Etypes, Available Keys, Session Encryption Type, msDS-SupportedEncryptionTypes. |
January 2025 CU |
| January 2026 | Audit phase begins. Kdcsvc events 201-209 introduced. RC4DefaultDisablementPhase registry key added. |
KB5073381 |
| April 2026 | Enforcement active by default. KDC defaults to AES-only (0x18) for accounts without explicit msDS-SupportedEncryptionTypes. |
KB5078763 |
| July 2026 | RC4DefaultDisablementPhase key removed. Rollback no longer possible. |
July 2026 CU |
How the KDC Selects a Service Ticket Encryption Type¶
Understanding this is the foundation for everything else on this page.
The decision algorithm¶
When a client requests a service ticket (TGS-REQ), the KDC selects the ticket encryption type using the target service account's declared encryption types, not the client's requested types. The sequence:
- Check
msDS-SupportedEncryptionTypeson the target account. If non-zero, this is the account's declared set. - If zero or unset: fall back to
DefaultDomainSupportedEncTypeson the DC. If that is also unset, use the internal default (0x27 pre-April 2026, 0x18 post-April 2026). - Apply the
SupportedEncryptionTypesGPO filter on the DC. This is a hard filter — the KDC will not issue a ticket with any etype excluded by this filter, regardless of what the account declares. - Pick the strongest etype from the resulting set that the KDC supports and the account has keys for.
The source client does not determine the service ticket etype¶
The client's etype list (what it advertises in the TGS-REQ) does not control which etype the KDC uses for the service ticket. The KDC picks the etype from the target account's configuration. A modern Windows 10/11 client on an AES-only domain will receive an RC4 service ticket for a legacy service account that is configured for RC4 — the client handles RC4 just fine, it simply did not drive the etype selection.
The practical implication: you do not need to configure the source machine to allow RC4 when adding RC4 exceptions for specific legacy services. The only configuration needed is on the DCs (the GPO filter must allow RC4) and on the target service account (its msDS-SupportedEncryptionTypes must include the RC4 bit).
Mixed-etype scenario
A user on a modern workstation logs in and gets an AES256 TGT (determined by the user account and the DC, not the target service). When that user accesses a legacy service whose account has msDS-SET = 60 (0x3C, RC4+AES+AES-SK), the KDC issues an AES256 service ticket (strongest available etype). If the legacy service's account has msDS-SET = 4 (RC4 only), the KDC issues an RC4 service ticket — and the modern workstation accepts it without issue.
The AES session key flag (bit 0x20)¶
The msDS-SupportedEncryptionTypes bitmask includes a special flag at bit 5 (0x20, value 32): AES256-CTS-HMAC-SHA1-96-SK. This flag does not add a new ticket etype — it instructs the KDC to use an AES256 session key even when the ticket body is encrypted with RC4.
This was introduced in November 2022 (KB5021131) as a transitional option. An account with msDS-SET = 36 (RC4 + AES-SK, value 0x24) receives an RC4-encrypted ticket body but an AES256 session key. The session key protects the actual communication between the client and service; encrypting it with AES reduces one of RC4's attack surfaces without requiring the service to support full AES ticket decryption.
The flag is included in the internal default 0x27 (which equals 0x7 | 0x20). Setting DefaultDomainSupportedEncTypes = 0x27 is equivalent to RC4+DES+AES-SK — it enables the session key upgrade for unconfigured accounts without changing the ticket etype.
TGT encryption type¶
The TGT encryption type is always determined by the krbtgt account's stored keys, not by msDS-SupportedEncryptionTypes on krbtgt. The KDC reads krbtgt's keys directly from ntds.dit. On any domain at functional level 2008 or higher, krbtgt has AES256 keys, so TGTs are always AES256 regardless of any registry setting or AD attribute.
Leave msDS-SupportedEncryptionTypes on the krbtgt account at 0 (unset). The KDC ignores this attribute for krbtgt and reads the stored keys directly. Setting it has no effect and may cause confusion.
The Four Controls¶
These are the levers that determine Kerberos encryption types. They interact and have different precedence. The AES Standardization Guide covers what to set these to; this section explains what each one actually does.
msDS-SupportedEncryptionTypes (AD attribute, per account)¶
The per-account declaration of which etypes the account supports. The KDC reads this when issuing service tickets for the account.
| Value | Meaning |
|---|---|
| blank / 0 | Not configured — KDC falls back to DDSET or enforcement default |
4 (0x04) |
RC4 only |
24 (0x18) |
AES128 + AES256 (recommended) |
60 (0x3C) |
RC4 + AES128 + AES256 + AES256-SK (recommended transitional) |
28 (0x1C) |
RC4 + AES128 + AES256 (transitional without AES-SK; prefer 0x3C) |
36 (0x24) |
RC4 + AES session key upgrade |
Computer accounts: auto-updated by the Kerberos GPO when gpupdate runs.
User accounts, gMSA, MSA: must be set manually via PowerShell or ADUC.
krbtgt: leave at 0 — the KDC ignores this attribute for krbtgt.
DefaultDomainSupportedEncTypes (registry, per DC)¶
Path: HKLM\SYSTEM\CurrentControlSet\Services\Kdc\Parameters, value name DefaultDomainSupportedEncTypes, REG_DWORD.
The KDC-side fallback etype set. Used when a target account's msDS-SupportedEncryptionTypes is blank or zero. Takes effect immediately — no KDC restart. Not replicated; must be set on every DC individually.
Per Microsoft's KB5073381, DCs with an explicitly defined DefaultDomainSupportedEncTypes are not functionally impacted by the April 2026 enforcement. The enforcement only changes the internal default for DCs where the key is absent. If you set DDSET to a value that includes RC4, the KDC uses that value as the fallback for accounts with msDS-SupportedEncryptionTypes = 0, and RC4 tickets can be issued for those accounts. Lab testing on the current CU build (KB5082137+, 2026-04-25) confirmed this behavior.
RC4DefaultDisablementPhase (registry, per DC)¶
Path: HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\Kerberos\Parameters, value name RC4DefaultDisablementPhase, REG_DWORD. Requires KDC restart.
| Value | Behavior |
|---|---|
| absent | Same as 2. After KB5078763, enforcement is active with no key present. |
| 0 | Full rollback — RC4 allowed for all accounts. See phase matrix below. |
| 1 | Audit — RC4 allowed for all accounts. Kdcsvc warning events logged per request. |
| 2 | Enforcement — RC4 blocked for accounts with blank/0 msDS-SupportedEncryptionTypes. |
Valid until July 2026. The July 2026 update removes this key; rollback is no longer possible after that.
SupportedEncryptionTypes GPO (per DC / per machine)¶
Group Policy: Computer Configuration → Windows Settings → Security Settings → Local Policies → Security Options → Network security: Configure encryption types allowed for Kerberos.
This writes SupportedEncryptionTypes to the registry at HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\Kerberos\Parameters. Requires KDC restart to take effect on DCs.
On a domain controller: acts as a hard KDC filter. The KDC will not issue a ticket with any etype not in this value, regardless of what the account's msDS-SupportedEncryptionTypes or DDSET says. Also controls what etypes the KDC accepts for pre-authentication.
On a workstation or member server: controls what etypes the client advertises. Also auto-updates the computer account's msDS-SupportedEncryptionTypes in AD.
Phase Behavior: What the Registry Setting Actually Does¶
Lab-verified results from matrix testing on KB5078763 + subsequent CUs (Build 20348 UBR 5020), testing Phase × DDSET × msDS-SET combinations.
What Phase controls — the actual etype returned (DDSET absent)¶
The table below shows what the DC issues when DefaultDomainSupportedEncTypes is not set — the KDC falls back to its internal default, which the enforcement phase controls. When DDSET is explicitly set, it overrides the internal default (see DDSET overrides the enforcement default below).
| Phase | blank / 0 (unconfigured) | msDS=4 (RC4-only) | msDS=24 (AES-only) | msDS=28 (RC4+AES) |
|---|---|---|---|---|
| absent / 2 | AES256 (RC4 blocked) | RC4 (AES blocked) | AES256 (RC4 blocked) | AES256 (DC picks strongest) |
| 0 / 1 | RC4 (even when AES requested) | RC4 (AES blocked) | AES256 (RC4 req returns AES256) | AES256 (DC picks strongest) |
Phase=absent and Phase=2 are operationally identical. Phase=0 and Phase=1 are operationally identical.
The DC ignores the requested etype. kw-roast's -e flag controls only what is asked for. The DC picks the strongest etype the account can support and returns that, independent of the request. Requesting RC4 for an AES-only account returns an AES256 ticket. Requesting AES256 for a blank/0 account under Phase=0/1 returns an RC4 ticket.
Phase=0/1 only affects blank/0 (unconfigured) accounts¶
Phase=0/1 reverts the enforcement default for blank/0 accounts from 0x18 (AES-only) back to 0x27 (old default: DES + RC4 + AES session key flag, but no AES128/AES256 ticket etypes). Because 0x27 contains no AES128 or AES256 bits, blank/0 accounts can only receive RC4 tickets — and the DC issues RC4 even when AES256 is explicitly requested.
Accounts with an explicit msDS-SupportedEncryptionTypes are not affected by Phase at all:
- msDS=24: DC returns AES256 in every phase. Requesting RC4 gets AES256.
- msDS=28: DC returns AES256 in every phase (strongest available).
- msDS=4: RC4 in every phase. AES blocked in every phase.
Phase=0/1 forces blank/0 accounts to RC4 for all requests
The rollback is not just "allows RC4 alongside AES." For blank/0 accounts, it forces
RC4 even when AES was the requested etype. Any service running against an unconfigured
account will switch from AES tickets to RC4 tickets as soon as the rollback is applied.
Explicitly configured accounts (any non-zero msDS-SupportedEncryptionTypes) are
unaffected.
DDSET overrides the enforcement default¶
An explicit DefaultDomainSupportedEncTypes value takes precedence over the enforcement default. The April 2026 enforcement only changes the internal default from 0x27 (RC4-capable) to 0x18 (AES-only) when the DDSET registry key is absent. If DDSET is explicitly set, the KDC uses the explicit value as the fallback for accounts with msDS-SupportedEncryptionTypes = 0.
Lab testing (KB5082137+, 2026-04-25) confirmed:
DefaultDomainSupportedEncTypes |
Result for blank/0 accounts | Event 4769 ServiceSupportedEncryptionTypes |
|---|---|---|
| not set | RC4 blocked — KDC uses internal 0x18 |
- (no value) |
| 4 (RC4 only) | RC4 allowed — ticket 0x17 (RC4) |
0x4 (RC4) |
| 24 (AES only) | RC4 blocked — ticket AES256 | - |
| 28 (RC4+AES) | RC4 available — ticket 0x12 (AES256, strongest), session 0x17 (RC4) |
0x1C (RC4, AES128-SHA96, AES256-SHA96) |
Event 205 fires at KDC start if DDSET includes insecure ciphers — this is a permanent warning, not an error.
DDSET re-enables RC4 for all unconfigured accounts
Setting DDSET to a value that includes RC4 (e.g., 0x3C or 0x4) re-enables RC4 for every account with msDS-SupportedEncryptionTypes = 0. This is a domain-wide change. Prefer setting msDS-SupportedEncryptionTypes on individual accounts to limit the blast radius.
Requirements Before Disabling RC4¶
These conditions must be true before enforcement is safe. If any are not met, accounts will fail to authenticate after the April 2026 update is installed (or after setting Phase=2 manually).
krbtgt account¶
krbtgt must have AES keys. This is true on any domain that has been at functional level 2008 or higher and has had krbtgt's password rotated at least once since the DFL upgrade. Verify:
Get-ADUser krbtgt -Properties PasswordLastSet |
Select-Object PasswordLastSet
# Check that this date is after the domain reached DFL 2008.
# For definitive key verification, use DSInternals:
Get-ADReplAccount -SamAccountName krbtgt -Server dc01.corp.local |
Select-Object -ExpandProperty Credentials | Select-Object Etype
If krbtgt lacks AES keys, rotate the password twice before proceeding. See Algorithms & Keys.
All SPN-bearing user service accounts¶
Every user account with a service principal name must have:
- AES keys in
ntds.dit(password reset after DFL 2008) msDS-SupportedEncryptionTypesset to a value that includes AES (24 or 28 recommended)
Accounts that have AES keys but msDS-SET = 0 (blank) will be treated as AES-only after enforcement — this is the correct behavior. Accounts that have msDS-SET = 4 (RC4-only) will continue getting RC4 tickets regardless of enforcement.
All computer accounts¶
Computer accounts auto-update their msDS-SupportedEncryptionTypes via the Kerberos GPO. Before enforcing:
- Deploy the AES Kerberos GPO to all workstation and server OUs.
- Verify every online machine has applied it (check
msDS-SupportedEncryptionTypesis non-zero). - Investigate any computer account still at 0 — it may be offline, in the wrong OU, or a non-Windows device.
Non-Windows services with keytabs¶
Any non-Windows service (Apache Kerberos, Java services, Linux with krb5.conf) using a keytab must have AES keys in the keytab. Generate new keytabs after resetting the service account password:
ktpass -out service.keytab \
-princ HTTP/web.corp.local@CORP.LOCAL \
-mapUser corp\svc_web -mapOp set \
-pass <password> \
-ptype KRB5_NT_PRINCIPAL \
-crypto AES256-SHA1
Regular user accounts (for AES-only DC GPO)¶
If you intend to apply an AES-only GPO to domain controllers (blocking RC4 at the KDC level), regular user accounts must also have AES keys, because the DC uses RC4 for the AS-REP encrypted portion of the TGT when the user's only key is RC4. Without AES keys, those users cannot log in.
If some regular user accounts still lack AES keys, use Path 2 (AES opportunistic with RC4 fallback), which keeps RC4 in the DC GPO for AS exchange while forcing AES for all service tickets.
Timeline¶
| Phase | Date | What Happens |
|---|---|---|
| Audit | January 13, 2026 | Kdcsvc events 201-209 introduced. RC4DefaultDisablementPhase registry key added. RC4 still works. Default behavior unchanged. |
| Enforcement with rollback | April 14, 2026 | KB5078763. KDC defaults to AES-only for unconfigured accounts. Rollback available via RC4DefaultDisablementPhase. |
| Final enforcement | July 2026 | RC4DefaultDisablementPhase key removed. No rollback. RC4 only available via explicit per-account msDS-SupportedEncryptionTypes. |
Kdcsvc Event Reference¶
Logged in the System event log on domain controllers, source Kdcsvc. Events fire per-request (201-204, 206-209) or per KDC start (205).
| Event | Phase | Trigger | Type | Result |
|---|---|---|---|---|
| 201 | 1 (audit) | Client RC4-only, service has no msDS-SET, no DDSET | Warning | RC4 ticket issued; event logged |
| 202 | 1 (audit) | Service lacks AES keys, no msDS-SET, no DDSET | Warning | RC4 ticket issued; event logged |
| 203 | absent/2 | Client RC4-only, service has no msDS-SET | Error | Ticket blocked |
| 204 | absent/2 | Service lacks AES keys, no msDS-SET | Error | Ticket blocked |
| 205 | any | DC has DDSET configured to include insecure ciphers | Warning (startup) | Never escalates to error |
| 206 | 1 (audit) | Service is AES-only (explicit msDS-SET=24), client RC4-only | Warning | RC4 ticket issued; event logged |
| 207 | 1 (audit) | Service is AES-only, account lacks AES keys | Warning | RC4 ticket issued; event logged |
| 208 | absent/2 | Service is AES-only (explicit msDS-SET=24), client RC4-only | Error | Ticket blocked |
| 209 | absent/2 | Service is AES-only, account lacks AES keys | Error | Ticket blocked |
Events 201/203 vs 205 distinction¶
Events 201/203 fire when the service account has no msDS-SupportedEncryptionTypes defined AND the DC has no DDSET defined. Event 205 fires when the DC does have DDSET defined and that value includes RC4. These are mutually exclusive conditions for a given request.
Events 201/203 vs 205
Events 201/203 fire when the DC has no DDSET defined and the service account has no msDS-SupportedEncryptionTypes. When DDSET is explicitly set, Event 205 fires at KDC start instead (if DDSET includes insecure ciphers), and the KDC uses the explicit DDSET value for etype selection.
Remediation reference¶
| Event pair | Root cause | Fix |
|---|---|---|
| 201/203 | Client RC4-only + service no explicit config | Enable AES on client, or set msDS-SET = 60 (0x3C) on service account |
| 202/204 | Account lacks AES keys + no explicit config | Reset password (twice if pre-DFL 2008) |
| 205 | DDSET includes RC4 | Set DDSET to 0x18 (AES-only) if safe; otherwise document the exception |
| 206/208 | Service is AES-only + client RC4-only | Upgrade client, or temporarily set msDS-SET = 60 (0x3C) on service |
| 207/209 | Service AES-only + account lacks AES keys | Reset password (twice if pre-DFL 2008) |
Post-July 2026: Keeping RC4 for Specific Services¶
After July 2026, the RC4DefaultDisablementPhase registry key no longer exists. Enforcement is permanent and covers all accounts with msDS-SupportedEncryptionTypes of blank or 0. The only supported way to issue RC4 service tickets is to explicitly configure the account and the DC.
Both conditions must be met:
- The target service account must declare RC4 in
msDS-SupportedEncryptionTypes(bit 0x4). The recommended value is60(0x3C = RC4 + AES128 + AES256 + AES256-SK) — this allows RC4 as a fallback while AES remains the preferred etype and enables the AES256 session key upgrade for any RC4 tickets issued. - The DC GPO must permit RC4 (
SupportedEncryptionTypesmust include the RC4 checkbox). The GPO is the hard KDC filter. If RC4 is not in the filter, the KDC will not issue RC4 tickets regardless of the account'smsDS-SET. A KDC restart is required after changing the GPO.
Scenario A: Legacy service as the target¶
A legacy application running under a service account that cannot be upgraded to AES. Modern clients connect to it.
| Component | Action |
|---|---|
| DC GPO | Include RC4 (RC4_HMAC_MD5 checkbox on) — restart KDC |
| Service account | msDS-SET = 60 (0x3C, RC4+AES+AES-SK) for user/gMSA/MSA; GPO for computer accounts |
| Client machines | No change needed — the KDC selects the ticket etype from the target account, not from the client |
The client gets an AES TGT (determined by the user and DC) and an RC4 service ticket (determined by the target service account). The modern client handles RC4 service tickets without any special configuration.
Scenario B: Legacy device as both source and target¶
A legacy device connects to services AND other machines connect to it.
| Component | Action |
|---|---|
| DC GPO | Include RC4 — restart KDC |
| Legacy device (computer account) | GPO must include RC4 for the device to authenticate with RC4 pre-auth |
| Legacy device's own service accounts | msDS-SET = 60 (0x3C) for user accounts hosting SPNs; GPO for the computer account SPN |
| Target services the legacy device connects to | msDS-SET = 60 (0x3C) if those services also need RC4 |
GPO model for mixed environments¶
Most environments end up with three GPOs:
| GPO | Target OU | Etypes | Purpose |
|---|---|---|---|
| DC GPO | Domain Controllers | AES128 + AES256 (+ RC4 if any legacy users or services exist) | Controls KDC hard filter and AS exchange |
| AES-only machines | Workstations/Servers (modern) | AES128 + AES256 | Restricts client etype advertisement; auto-updates computer account msDS-SET |
| AES+RC4 machines | Workstations/Servers (legacy) | RC4 + AES128 + AES256 | Allows RC4 pre-auth for legacy devices; auto-updates computer account msDS-SET |
For any SPN-bearing account that is not a computer account (user service accounts, gMSA, MSA), set msDS-SupportedEncryptionTypes directly in AD. A GPO cannot manage these accounts.
All SPN accounts are Kerberoastable — RC4 makes cracking ~800x faster
Any authenticated domain user can request a service ticket for any SPN and attempt to crack it offline. With AES, cracking a strong password requires centuries of compute. With RC4, that drops to hours. Any user service account that retains RC4 must have a 30+ character random password. Track every exception with the account name, the system requiring RC4, the vendor case or upgrade timeline, and a review date.
Frequently Asked Questions¶
Is RC4 being removed from Windows entirely?
No. DES was removed in Server 2025, but RC4 remains available and can be enabled explicitly. What is changing is the implicit default: RC4 will no longer be assumed for accounts without explicit configuration.
Will the April 2026 update break my environment immediately on install?
Yes, if you have SPN-bearing accounts with msDS-SupportedEncryptionTypes blank or 0 that depend on RC4. The enforcement is active as soon as the updated KDC starts. Run the audit steps in the AES Standardization Guide before deploying the April 2026 update, or roll back to Phase=1 (audit) immediately after install if failures occur.
I set DefaultDomainSupportedEncTypes = 60 (0x3C) on my DCs. Does that protect me?
Per KB5073381, an explicit DDSET is not overridden by enforcement — the enforcement only changes the internal default when DDSET is absent. Setting DefaultDomainSupportedEncTypes to a value that includes RC4 (e.g., 0x3C) does re-enable RC4 for accounts with blank/0 msDS-SupportedEncryptionTypes. However, DDSET is a domain-wide blunt instrument — it affects every unconfigured account. Prefer setting msDS-SupportedEncryptionTypes on individual accounts for targeted RC4 exceptions.
Can I roll back after July 2026?
No. The RC4DefaultDisablementPhase registry key is removed by the July 2026 update. Enforcement is permanent. The only remaining way to use RC4 is to set msDS-SupportedEncryptionTypes to include the RC4 bit on the specific service account and allow RC4 in the DC GPO.
Does DefaultDomainSupportedEncTypes need to include RC4 for legacy services?
No. DDSET is a KDC fallback for accounts with msDS-SET = 0. If you are using per-account msDS-SET = 60 (0x3C) for legacy services, DDSET is irrelevant for those accounts. DDSET with RC4 would re-enable RC4 for all unconfigured accounts, which is a broader change than necessary. Prefer per-account msDS-SupportedEncryptionTypes for targeted exceptions.