The clock is ticking for one of the longest-lasting (and most insecure) ciphers in our networks. Microsoft is getting serious and pushing for the shutdown of RC4 encryption in the Kerberos protocol. Those who fail to act now risk far-reaching authentication problems in Active Directory in April – or July at the latest.

At TEAL, we have been helping customers harden their infrastructure for years. Disabling RC4 is one of the “classics” in this process. But those who have not yet taken action need to hurry! This time, the timeline is not being dictated by internal IT, but directly by Redmond.

The three paths through April and July

When the changes to Kerberos encryption logic take effect in April, companies will have exactly three options:

1. 1. Hope that they are somehow ready.
   2. Panic, press the “panic button,” and delay the changes (at their own risk).
   3. Know that they are ready because they have done their homework.

Guess which option we prefer 😉.

What exactly is changing?

Previously, service tickets often fell back to RC4 if AES was not explicitly enabled on SPN-enabled accounts. After the April update, AES is the default. RC4 is only used if it is manually stored in the msds-SupportedEncryptionTypes attribute. In addition, only AES session keys are supported by default.

So you can continue to use RC4 after the April update, but only until July! Then Microsoft will enforce the change. You must take action by then at the latest. If you don’t, you will be affected by the following problems:

The problem: In historically grown environments, there are pitfalls that cause Kerberos logins to fail:

• • Outdated hardware/systems: Anything prior to Windows 7 or Server 2008.
  • Legacy passwords: Accounts whose passwords have not been changed since 2008 or that have been migrated via ADMT (NTLM hashes only). Incorrectly configured service accounts can no longer be used.
  • Third-party solutions: Appliances or legacy software that does not support AES.

The TEAL expert assessment: The devil is in the details

Our experience shows: Don’t rely solely on group policies (GPOs). These are ignored in various scenarios, especially if attributes are missing from the accounts.

“Microsoft has provided tools to test the shutdown with the RegKey DefaultDomainSupportedEncTypes and the RC4DefaultDisablementPhase introduced in January. But be careful: the time until the end of June is valuable. With the July update, the RC4 door will be slammed shut for good—then a rollback will no longer be possible,” says one of our TEAL experts.

Your roadmap to RC4 freedom (instructions)

To avoid being overwhelmed by error messages, we recommend the following procedure:

1. 1. Enable auditing & start monitoring

With the January update, Microsoft introduced nine new event IDs. These are your early warning system.

• • Focus on events 201 & 206: These indicate devices that lack AES support.
  • Focus on events 202 & 207: Here you will find accounts that urgently need a password reset.
  • Check: Ensure that auditing is not blocked by manually defined DefaultDomainSupportedEncTypes on the domain controllers.

1. 2. Simulating an “emergency situation”

Use the temporary registry key RC4DefaultDisablementPhase. This allows you to trigger the RC4 shutdown in test environments (or in a controlled manner in production) before the official deadline in order to uncover any incompatibilities.

1. 3. Clean up contaminated sites

• • Identify keytab files without AES keys and regenerate them.
  • Force password changes for ancient accounts.
  • Update or isolate systems that do not support AES.

Conclusion: Take action before the automatic system kicks in

Attackers love RC4 vulnerabilities. From a security perspective, deactivation is a long overdue step. Those who do not prioritize these projects now will be left behind in the second half of 2026 when Microsoft finally cuts off the return paths.

Detailed technical information about the changes and CVE-2026-20833 can be found directly in the Microsoft Support article.