Table of Contents
What should Active Directory admins do now to prepare for the April 2026 Kerberos RC4 enforcement change?
RC4 is an older encryption type that many environments still carry for backward compatibility. Microsoft’s plan is to turn off RC4 by default for Kerberos ticket issuance on domain controllers (KDC behavior), so Kerberos service tickets use AES-based encryption by default instead.
This is not a single “flip the switch” event. Microsoft is doing it in phases so organizations can identify RC4 dependencies first, then fix them before enforcement becomes the default.
Why the January 2026 updates matter
The January 2026 cumulative security updates introduce two practical capabilities:
- New monitoring signals that help you detect where RC4 is still in use (or where systems are configured in a way that would fall back to RC4).
- An optional, temporary configuration control (via registry) that lets admins manage or respond to the hardening process without immediate disruption.
This phase is designed for visibility. The intent is to surface remaining RC4 dependencies early—before Microsoft shifts behavior in April 2026.
Timeline you should plan around
Microsoft’s published schedule creates three planning milestones:
- January 2026: Initial deployment phase begins. Monitoring and optional controls appear. Recommended action: patch domain controllers and start detection.
- April 2026: Enforcement mode becomes enabled by default on Windows domain controllers. Default behavior shifts toward AES-SHA1 ticket encryption.
- July 2026: Audit mode is removed, leaving Enforcement mode as the only option.
Operationally, this means any remaining RC4-only dependency that survives into enforcement can become an outage risk.
What admins should do now (practical preparation plan)
Start with actions that create evidence, then fix what the evidence reveals:
- Patch all AD domain controllers to the January 2026 cumulative update (or later) so monitoring and controls exist everywhere.
- Enable and review the new Kerberos monitoring events to identify accounts, services, and applications still requesting or requiring RC4.
- Inventory service accounts and legacy apps that use Kerberos, then confirm they support AES. Focus on “old but critical” services: line-of-business apps, appliances, print services, older middleware, and anything using hard-coded crypto settings.
- Remediate by updating apps, rotating keys where required, and adjusting account settings so AES is permitted and preferred (instead of allowing RC4 as a fallback).
- Treat April 2026 as the internal deadline for “RC4-free by default,” because that’s when enforcement behavior becomes the baseline.
Risk framing (what breaks and why)
The most common failure pattern is simple: a service or service account still expects RC4-based Kerberos service tickets. When a domain controller moves to enforcing AES-only ticket issuance by default, the request can fail, and authentication to that service can stop.
Microsoft’s “Audit First” approach is meant to prevent surprise outages, but only if monitoring is reviewed and remediation starts early—January through March 2026 is the safest window.
Where to validate details
Use Microsoft’s Release Health / support documentation for the canonical timeline, the monitoring event references, and the registry control guidance, including the management article covering “How to manage Kerberos KDC usage of RC4 for service account ticket issuance changes related to CVE-2026-20833.”