How to Manage RC4 Hardening – Definitive Guide

This article is a technical continuation of the RC4 deprecation / Kerberos hardening work I covered in my previous article last month. If you already went through the “why” (risk of RC4, what changes Microsoft is rolling out, and the high-level migration approach), the goal here is to get hands-on and precise: what exactly changes across the three rollout phases, which registry keys and AD attributes drive KDC behavior, what you should expect to see in security logs, and how to turn those signals into concrete remediation steps.

Prerequisites: ensure the January update that introduces the RC4/Kerberos hardening telemetry is installed on all Domain Controllers. Without that patch, the Security log will not emit the new KDC events (201–209) and the Domain Controllers will not evaluate the related registry keys (RC4DefaultDisablementPhase and DefaultDomainSupportedEncTypes).

Note: The information in this article applies only to supported operating systems released before 2025. I haven’t had the time to validate how these keys behave on 2025 versions.

Hardening Phases

Let's begin with a brief walkthrough of the hardening phases. For a detailed walkthrough of the rollout phases, see my previous article. Below is a technical summary of each phase of the RC4 hardening update.

• Phase 1 - Auditing - January 2026:
  • starting from the January update, you can create the RC4DefaultDisablementPhase registry key. Set it to 1 to enable logging of the new events (201-209) on domain controllers.
  • Nothing else changes, for now.
• Phase 2 – Soft enforcement – April 2026: the KDC will reject automatically requests that only support RC4. In this phase:
  • RC4DefaultDisablementPhase is set to 2 but can be reverted to 1. If the value was previously set to 1, the patch won’t override the value.
  • DefaultDomainSupportedEncTypes: if the value of this key was not set when Phase 2 starts, the value is set to 0x18 by default (AES-only). You can roll it back to 0x1C or 0x24 (you will understand the difference between those two values later in this article) if needed. However, if you had previously defined this key, Microsoft will not override it.
• Phase 3 – Hard enforcement – July 2026:
  • the RC4DefaultDisablementPhase is no longer read
  • In this phase, the only way to allow RC4 encryption is to manually set the msDS-SupportedEncryptionTypes attribute to 0x1C (to allow RC4 only for the account) or to set the DefaultDomainSupportedEncTypes to 0x1C or 0x24 to allow RC4 for the entire environment.

Note that, if you want to apply the msDS-SupportedEncryptionTypes to allow RC4 at AD object level, but at the same time have the DefaultDomainSupportedEncTypes set to 0x18 you’ll need to set the SupportedEcryptionType policy for the support of RC4 (more details in the scenarios section of this article).

Registry keys and attributes involved

In this section, you’ll find the list of all the registry keys, AD attributes, and GPOs involved in this hardening. The values shown are not exhaustive, I have listed only the specific values relevant to this hardening.

DefaultDomainSupportedEncTypes:

Path: HKLM\System\CurrentControlSet\Services\KDC

This key need to be created manually if needed

Possible values:

• 0x27: enable DES, RC4 and AES session key (default before hardening for pre-2025 OSs)
  • Flags enabled: DES-CBC-CRC, DES-CBC-MD5, RC4-HMAC, AES256-CTS-HMAC-SHA1-96-SK
• 0x24: Enable RC4 and AES session key:
  • Flags Enabled: RC4-HMAC, AES256-CTS-HMAC-SHA1-96-SK
• 0x1C: allow RC4 and AES:
  • Flags enabled: RC4-HMAC, AES128-CTS-HMAC-SHA1-96, AES256-CTS-HMAC-SHA1-96
• 0x3C: enable RC4, AES and AES session key
  • Flags enabled: RC4-HMAC, AES128-CTS-HMAC-SHA1-96, AES256-CTS-HMAC-SHA1-96, AES256-CTS-HMAC-SHA1-96-SK
• 0x18: enable AES only (default value pre hardening for 2025)
  • Flags enabled: AES128-CTS-HMAC-SHA1-96, AES256-CTS-HMAC-SHA1-96
• 0x38: enable AES and AES session key
  • Flags enabled: AES128-CTS-HMAC-SHA1-96, AES256-CTS-HMAC-SHA1-96, AES256-CTS-HMAC-SHA1-96-SK

Possible values and their meaning during all the phases: 

• Phase 1:
  • The value of this key won’t be changed during phase 1. if the key has not been manually set, you'll have the default value of you operating system during this phase
• Phase 2:
  • 0x18: default value for this phase. Block the use of RC4 encryption, only AES-128 and AES-256 are allowed. If this key was already explicitly set to any other value before the starting of phase 2, the patch won’t override its value.
  • 0x24, 0x1C and 0x3C: these values can be used for manual rollback to allow RC4, I’ll advise using the value 0x1C for increased security. *
• Phase 3:
  • 0x18: default value for this phase. Block the use of RC4 encryption, only AES-128 and AES-256 are allowed. If this was already explicitly set to any other value, the patch won’t override its value.
  • 0x24, 0x1C and 0x3C: these values can be used for manual rollback to allow RC4, I’ll advise using the value 0x1C for increased security. *

Later in this article, you’ll find common scenarios to help you choose the right values based on your audit findings.

* In our labs, setting the DefaultDomainSupportedEncTypes to 0x1C caused login issues on Windows Server 2003 and Windows XP. If you still have these operating systems, test this value carefully in your environment. We tried to set the key to 0x24 and we did not observe the same issues.

RC4DefaultDisablementPhase

Path: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\Kerberos\Parameters

Note that this key must be manually created and set and will be evaluated only after the installation of the January 2026 update.   

Here you can find all the possible values during all phases:

• Phase 1:
  • 1: audit mode enabled, the events 201-209 are logged onto the domain controller when RC4 is being used (see the table below for details)
  • 2: Kerberos will start assuming that RC4 has been disabled and will start to negotiate AES encryption by default
• Phase 2:
  • The values are the same reported for phase 1. With the April patch the value will change to 2 only if the key was not explicitly set to 1 during phase 1. Anyway, it can be reverted to 1
• Phase 3:
  • The key is no longer evaluated

msDS-SupportedEncryptionTypes

This attribute is found on all domain objects in the attribute editor tab.

Value available for the attribute:

• Null, not set or 0x0: the encryption used depends on the value reported on the DefaultDomainSupportedEncTypes key
• 0x3C: enables RC4 AES and AES encryption key
  • Flags enabled: RC4-HMAC, AES128-CTS-HMAC-SHA1-96, AES256-CTS-HMAC-SHA1-96, AES256-CTS-HMAC-SHA1-96-SK
• 0x38: enables AES and AES encryption key only
  • Flags enabled: AES128-CTS-HMAC-SHA1-96, AES256-CTS-HMAC-SHA1-96, AES256-CTS-HMAC-SHA1-96-SK
• 0x18: enables AES only
  • Flags enabled: AES128-CTS-HMAC-SHA1-96, AES256-CTS-HMAC-SHA1-96

See the section reporting the common scenarios to understand how to correctly use this attribute in your environment.

SupportedEncryptionTypes

This registry key is populated by a GPO on the DCs: “Network security: Configure encryption types allowed for Kerberos”. The path of the GPO is "Computer Configuration > Policies > Windows Settings > Security Settings > Local Policies > Security Options".

You can find the related registry key at the path:  HKLM\Software\Microsoft\Windows\CurrentVersion\Policies\System\Kerberos\Parameters\

The values of the registry key depend on the GPO settings. The possible values are:

• 0x7FFFFFFC: this configuration is needed to support RC4 in your environment
  • Encryption type supported: RC4-HMAC, AES128-CTS-HMAC-SHA1-96, AES256-CTS-HMAC-SHA1-96, AES256-CTS-HMAC-SHA1-96-SK, FAST-supported, Compound-identity-supported, Claims-supported, Resource-SID-compression-disabled, Future encryption types
• 0x7FFFFFF8: this is value for the recommended configuration
  • Encryption types supported: AES128-CTS-HMAC-SHA1-96, AES256-CTS-HMAC-SHA1-96, AES256-CTS-HMAC-SHA1-96-SK, FAST-supported, Compound-identity-supported, Claims-supported, Resource-SID-compression-disabled, Future encryption types

See the section with the common scenarios to understand how to use this key.

 

Audit

This section lists the auditing events for this hardening and briefly explains what each one indicates. Starting in January 2026, some existing events were enhanced to surface additional encryption details, and new events were introduced that are available only after installing the January 2025 patch. Microsoft also made two really helpful scripts to collect and analyze events, you can find more details about those scripts at the end of this section.

Existing enhanced events 

Some existing events has been enhanced, and can be used for the auditing of RC4 usage, like:

• 4768: A TGT ticket has been requested
• 4769: A Kerberos service ticket has been requested

Beyond identifying the client and account requesting the ticket, both events include several fields that are useful for analysis:

• msDS-SupportedEncryptionTypes: show the value of this attribute for the account reported in the event
• Available keys: shows all the available keys that has been found in AD for that object
• Ticket Encryption Type: the actual ciphers used for the ticket encryption:
  • 0x17 = RC4
  • 0x12 or 0x13 = AES
• Session Encryption Type: the actual ciphers used for the session Encryption
  • 0x17 = RC4
  • 0x12 or 0x13 = AES
• Advertised Etypes: lists the encryption types the client supports. If you see only RC4 or DES in this field, it means that we are looking at a legacy client; modern clients should advertise both RC4 and AES.

Note: 4768 events are not correlated with any 201-209 event, while for the 4769 events you can find the related 201-209 event to help you during the troubleshooting.

New events available

During the audit phase we can see the system event log:

 

During the enforcement phase, you can find these events in the system event log:

 

Below is a list of possible remediation steps based on the events you observe:

• 201 and 203: these events usually indicate that we are looking to a legacy device. My advice is to correlate this finding to the related 4769 event. The goal is understand if the device is legacy or not:
  • The device is legacy: the device does not support AES and needs to be updated. If the update is not feasible now, you can set the msDS-SupportedEncryptionTypes to 0x1C to allow RC4
  • The device is not legacy: investigate the reason why the device does not have any AES keys available. Maybe the password of the AD account has not been reset in a long time, or there may be a policy applied to this object to enforce the use of RC4 only
• 202 and 204: these events usually indicate that the password for the account is too old, so the account cannot generate any AES key for encryption.
  • Reset the password and try the authentication again to confirm the resolution of the problem.
• 206 and 208: these events usually indicate a mismatch between the client and the account configuration. The account may be set to allow AES only but the client may be legacy one.
  • You need to update the client, if the update is not feasible now, you can set the msDS-SupportedEncryptionTypes to 0x1C to allow RC4
• 207 and 209: the account is set to AES but cannot generate an AES ticket.
  • Usually, you'll need to reset the password of the account to solve this issue.

See the common scenarios section for more details

Scripts

Microsoft provided two scripts to help us investigate the RC4 usage in our environment:

• List-AccountKeys.ps1 to query event logs to enumerate available encryption keys for accounts.
• Get-KerbEncryptionUsage.ps1 to identify Kerberos encryption types in use, with filtering options for specific algorithms like RC4.

The scripts are available in this repository: Microsoft's Kerberos-Crypto GitHub repository

Get-KerbEncryptionUsage.ps1

This script can identify the usage of RC4 encryption in the environment by analyzing the events recorded on the domain controllers. The info are collected primarily from the events 4768 and 4769. In the output you’ll find date and time of the event, the requestor and the type of ticket and session encryption used.

Example:

.\Get-KerbEncryptionUsage.ps1 -Encryption RC4 -Searchscope AllKdcs | Export-Csv -Path .\KerbUsage_DC01.csv -NoTypeInformation -Encoding UTF8

List-AccountKeys.ps1

This script is useful to identify which key are available for an object (service account, user, computer account).

Event forwarding

If you have a SIEM available on your environment: lucky you! There is a wonderful article that explains how to collect and forward the event to the SIEM to analyze them: So, you think you’re ready for enforcing AES for Kerberos? | Microsoft Community Hub

 

Common Scenarios

This section will cover the common scenarios that we may find in the customer’s environment and how to approach it

I have only few objects that are using RC4

Scenario:

• During the audit phase I found few legacy devices and applications not compatible with AES
• I cannot update those devices/applications before the July 2026 phase (enforcement phase)
• I need to leave RC4 enabled for only those objects

DOs:

• SupportedEncryptionTypes: you need to set this key to 0x7FFFFFFC to allow the support of RC4 using the GPO (see the "Registry keys and attributes involved" section of this article), otherwise even if the attribute msDS-SupportedEncryptionTypes is set to support RC4, the authentication will break, because the KDC won't know how to interpret RC4.
• msDS-SupportedEncryptionTypes: this attribute needs to be set to 0x1C to support RC4
• DefaultDomainSupportedEncTypes: can be set to 0x18, this sets AES as the default encryption type for the domain. So, all the account that have the msDS-SupportedEncryptionTypes not set, will use AES by dafault

In this scenario, new accounts and computers will use AES by default, while accounts with the attribute msDS-SupportedEncryptionTypes set to 0x1C will still use RC4. This works because the KDC is configured to allow RC4 even though AES remains the domain’s default.

Note that having devices and applications that rely on RC4, will lower the security posture of your environment, my advice would be to remediate those devices/applications asap.

Many services rely on RC4

Scenario:

• During the audit phase I found many devices not compatible with AES
• I cannot update those devices/applications before the July 2026 phase (enforcement phase)

If there are too many devices to be remediated using the msDS-SupportedEncryptionTypes attribute, you’ll need to keep RC4 enabled by default at the domain level:

• DefaultDomainSupportedEncTypes: needs to be set to 0x1C to allow both AES and RC4
• SupportedEncryptionTypes: needs to be set to 0x7FFFFFFC (see the "Registry keys and attributes involved" section for more information about this setting)
• msDS-SupportedEncryptionTypes: this attribute does not need to be changed in this scenario.

In this scenario you can evaluate the possibility to use the attribute msDS-SupportedEncryptionType to secure some critical modern devices and applications by setting the attribute to 0x18 or 0x38 to allow only AES encryption for those objects. 

No services rely on RC4

Congratulations!! This is the best scenario, you don’t have any legacy devices or applications that can rely only on RC4.

DOs:

• DefaultDomainSupportedEncTypes: you can leave it to the July 2026 default (0x18)
• SupportedEncryptionTypes: can be set to 0x7FFFFFF8 (see the "Registry keys and attributes involved" section for more information about this setting)
• msDS-SupportedEncryptionTypes: there is no need to change this attribute in this scenario

 

Conclusion

The RC4 hardening rollout is one of those changes that looks simple on paper “move everything to AES”, but succeeds or fails based on how well you turn Kerberos telemetry into an inventory of real dependencies. Across the three phases (audit, soft enforcement, hard enforcement), the KDC gradually shifts from observing RC4 usage to actively rejecting it, and by Phase 3 the domain-wide “allow RC4” escape hatch is gone.

Use Phase 1 and the first part of Phase 2 to build a remediation backlog from the new KDC events (201–209) and the enhanced 4768/4769 fields. 

Also keep in mind the blind spots: the absence of KDCSVC audit events does not guarantee that all systems will function correctly after enforcement. These events focus on service ticket requests involving default/implicit encryption behavior; explicitly configured accounts, TGT requests, and non-Windows or embedded Kerberos stacks can still fail in ways that are not surfaced by 201–209 alone.

 

FAQs

Are there impacts in the forest trusts?

Test external trusts for impact. Trusts between domains in the same forest have used AES since the November 2022 patch. Before enforcing AES-only across a forest, validate that the trusted forest supports AES.

I don’t see any 201-209 events in my environment, does it means that my environment won’t be impacted?

No, the absence of KDCSVC audit events does not guarantee that all systems will function correctly after enforcement. These events focus on service ticket requests involving default/implicit encryption behavior; explicitly configured accounts, TGT requests, and non-Windows or embedded Kerberos stacks can still fail in ways that are not surfaced by 201–209 alone.

Is the msDS-SupportedEncryptionTypes key evaluated by Windows XP and Windows 2003 OSs?

No, those operating systems are not capable to read the msDS-SupportedEncryptionTypes key. In this case, to allow the use of RC4 you’ll need to use the DefaultDomainSupportedEncTypes set to 0x24

Useful Resources

• Encryption Type Calculator: Encryption Type Calculator - Kerberos in Active Directory
• What is going on with RC4 in Kerberos? | Microsoft Community Hub
• Supported Encryption Types Bit Flags [MS-KILE]: Supported Encryption Types Bit Flags | Microsoft Learn
• How to manage Kerberos KDC usage of RC4 for service account ticket issuance changes related to CVE-2026-20833 How to manage Kerberos KDC usage of RC4 for service account ticket issuance changes related to CVE-2026-20833 - Microsoft Support
• Event 4769: 4769(S, F) A Kerberos service ticket was requested. - Windows 10 | Microsoft Learn
• How to manage the Kerberos protocol changes related to CVE-2022-37966 KB5021131: How to manage the Kerberos protocol changes related to CVE-2022-37966 - Microsoft Support
• Detect and remediate RC4 usage Detect and Remediate RC4 Usage in Kerberos | Microsoft Learn

 

Disclaimer

The content of this article is based on available public documentation and test performed on a personal lab environment. The information is provided AS IS without a warranty of any kind. Microsoft further disclaims all implied warranties including, without limitation, any implied warranties of merchantability or of fitness for a particular purpose. The entire risk arising out of the use of the reported information contained in this documentation remains with you. In no event shall Microsoft, its authors, or anyone else involved in the creation, production, or delivery of the document be liable for any damages whatsoever (including, without limitation, damages for loss of business profits, business interruption, loss of business information, or other pecuniary loss) arising out of the use of or inability to use the data in this documentation, even if Microsoft has been advised of the possibility of such damages.
In short: Every environment is different, please test the changes before the implementation in your production environment