In case you haven’t heard, RC4 is not secure and has been deprecated. In this article, I will discuss what changed with the January 2026 Windows Update and why it is important to start auditing and remediate RC4 usage is your environment.

Starting with the January 13, 2026, Windows security updates, Microsoft began the first official phase of hardening Kerberos authentication by reducing reliance on RC4 encryption. The RC4 change will mainly impact service accounts and accounts that have the attribute msDS-SupportedEncryptionTypes left blank.

Why Microsoft Is Targeting RC4

RC4 is considered insecure due to cryptographic flaws that produce biased, non-random output, allowing attackers to recover encrypted data.

Despite this, RC4 remains enabled by default in many Active Directory environments for backward compatibility.

Microsoft tied the January changes to a Kerberos information disclosure vulnerability tracked as CVE-2026-20833, using this security update as the entry point to begin the RC4 deprecation process.

Update Timeline: From Audit to Full Enforcement

Microsoft is rolling out the Kerberos RC4 hardening in well-defined phases throughout 2026, giving organizations time to identify dependencies and remediate them before enforcement becomes mandatory. Understanding this timeline is critical to avoid outages.

Phase 1 – Initial Deployment (January 2026)

Starting on January 13, 2026, Windows security updates introduce the initial deployment phase.
This stage is focused on monitoring, not enforcement.

Key points of this phase:

• New Kerberos audit events are logged on Domain Controllers (we will analyze them later in this article)
• A temporary registry control setting (RC4DefaultDisablementPhase) has been introduced, allowing organizations to optionally enable stricter behavior ahead of time
• No default behavior changes are applied

Phase 2 – Enforcement Enabled by Default (April 2026)

Beginning with the April 2026 Windows security update, Microsoft moves to the second deployment phase, where behavior changes start to matter operationally.

During this phase:

• Enforcement mode is enabled by default on all supported Windows Domain Controllers, the default value for DefaultDomainSupportedEncTypes is set to allow AES-SHA1 only: 0x18
• This changes the Kerberos KDC default behavior for accounts without an explicit msDS-SupportedEncryptionTypes configuration to allow RC4. RC4 is no longer negotiated implicitly for accounts with a blank msDS-SupportedEncryptionTypes, they will only receive AES encrypted tickets

While it is still technically possible to revert to audit behavior temporarily (by changing the value of the registry key mentioned above), it will be important to arrive in this phase with the remediation already completed.

Phase 3 – Full Enforcement (July 2026)

The final phase begins with the July 2026 security updates and represents the end of the transition period.

At this point:

• Audit‑only mode is removed
• The temporary RC4DefaultDisablementPhase registry value is no longer read
• the default value for DefaultDomainSupportedEncTypes is set to AES-SHA1 only (0x18)
• With this configuration, Kerberos will issue RC4 tickets only if explicitly configured per account using the attribute “msDS-SupportedEncryptionTypes ”

Organizations that didn’t address RC4 usage earlier will experience persistent service outages for legacy systems and applications not compatible with AES encryption.

How to prepare for the changes

It’s tempting to ignore the January changes because “nothing is broken,” but that would be a mistake. The new audit events are here to help you prepare for the changes.

Let’s analyze how we can leverage audit data to be ready before April 2026

Audit events

After the January Windows security update, some new events will start to appear in the system event logs of supported domain controllers if:

• Your domain controller is receiving Kerberos service ticket requests that require RC4 cipher to be used but the service account has default encryption configuration
• Your domain controller has an explicit DefaultDomainSupportedEncTypes configuration to allow RC4 encryption

To understand if your environment will be impacted by the change, you’ll need to audit the events 201,202,205,206,207 from the system event log. The events 203,204,208 and 209 will be logged starting from phase 2. See this Microsoft article for more details about the events.

These events are designed to help you identify accounts or services still requesting RC4encrypted tickets and clients or applications that do not support AES. This gives administrators a safe discovery phase to identify dependencies before anything stops working.

Identify High Risk Dependencies

Not all RC4 usage has the same impact. The audit events allow administrators to prioritize remediation by identifying:

• Service accounts that rely on RC4 due to missing or outdated encryption keys, such as accounts that have not had password reset in years
• Legacy applications or appliances that cannot negotiate AES

Service accounts deserve special attention because they are commonly affected by RC4 dependencies and are high value targets in Kerberoasting scenarios.

Validate Kerberos Encryption Configuration

One of the most important insights provided by the new events is whether accounts are missing AES‑compatible Kerberos keys (msDS-SupportedEncryptionTypes).

In many cases, RC4 usage is not intentional but happens because the account password has never been reset since AES support was introduced or because the encryption types are implicitly inherited rather than explicitly defined.

The audit data allows you to confirm which accounts already support AES and which ones will fail once AESonly behavior becomes the default.

Establish a Remediation Baseline Before April

By the time the April 2026 enforcement phase begins, you should already have:

• Reviewed Kerberos audit events across all domain controllers
• Identified all RC4-dependent accounts and services
• Confirmed AES compatibility where possible
• Documented any unavoidable legacy dependencies

The January audit data is meant to drive these actions early, while remediation can still be planned and tested calmly.

Why the January Update Matters (Even If Nothing Breaks Yet)

Since the creation of AES-SHA1 tickets has been implemented in Windows Server 2008R2, I’m confident that many organizations won’t have issues with this transition and can use these phases to validate their configurations.

If you didn’t have the chance or the time to address the RC4 usage earlier, don’t give into the temptation to ignore the January changes, because that would be unwise. The audit events that have been introduced are your only early warning system to avoid Kerberos authentication failures, problems with legacy applications, and service accounts failing due to missing AES keys.

In practice, the January update is the last safe window to:

• Identify RC4‑only service accounts
• Detect non-AES-capable clients
• Fix misconfigured Kerberos encryption settings on your terms

Organizations that use this phase to audit, remediate, and modernize will transition smoothly.
Those who ignore it risk discovering RC4 dependencies only when enforcement is already active.