Microsoft is disabling RC4, an older and less secure cipher historically used in some Kerberos authentication scenarios in Active Directory. While RC4 was widely supported for compatibility with legacy systems, modern security standards have moved to stronger encryption methods such as AES.
If left unaddressed, this change can cause silent failures in production applications, missed jobs, and broken integrations often without affecting user logins, which makes detection harder.
Why Microsoft Is Disabling RC4
RC4 has been considered cryptographically weak for years and is no longer recommended for modern authentication systems. Microsoft has gradually moved Active Directory environments toward stronger AES-based Kerberos encryption, and this change removes one of the last legacy compatibility options that can weaken authentication security.
Microsoft’s 2026 RC4 Enforcement Timeline
This change is Microsoft-driven and mandatory so planning ahead is the safest path.
- January 2026: Microsoft released an update that helps reveal (via logs) which applications/services are still using RC4.
- April 2026: Enforcement begins. Domain controllers will begin rejecting RC4 authentication attempts unless temporarily rolled back through Microsoft’s compatibility settings.
- July 2026: Full enforcement. RC4 is disabled with no rollback.
Who Is Most Likely To Be impacted?
Most modern Windows environments already use AES encryption and will see little impact. However, environments with older integrations or non-Windows systems are more likely to encounter issues. The biggest risk is in applications, scheduled tasks, integrations, and service accounts that authenticate in the background. Consider:
- Any business-critical app or integration that still uses RC4 for Kerberos authentication can fail once enforcement starts.
- Linux/Unix systems or appliances using keytab files (common in Kerberos integrations).
- Non-Windows devices joined to or authenticating against Active Directory (e.g., NAS devices, vendor appliances).
- Windows hosts where AES has been disabled (not recommended) and RC4 is still in use.
- Legacy Windows systems (e.g., Windows Server 2003/Windows XP-era compatibility).
For example, a nightly file transfer job using a Linux service account with an outdated keytab may suddenly fail after enforcement even though no user-facing logins are affected.
In many cases, remediation is straightforward: the affected application, service, or integration already supports modern ciphers and simply needs a configuration change or an update provided by the application’s vendor.
What You Should Do Now
- Identify RC4 usage: Review authentication logs on domain controllers to find any accounts, hosts, or services still negotiating RC4. In many environments this can be surfaced through Kerberos event logs that show the encryption type used during authentication.
- Prioritize what’s business-critical: Focus first on production applications, core integrations, and high-availability systems.
- Remediate: Update application configuration to use AES. Work with the application vendor to obtain any required patches or supported configuration changes, and update keytabs or service account settings as needed.
- Test before enforcement: Validate changes in lower environments and run targeted authentication testing so you’re not discovering issues during an outage.
While you’re reviewing legacy authentication, it can also be a good time to assess other older protocols sometimes found in environments (for example, NTLMv1 or SMBv1) and plan an incremental modernization path.
How JourneyTeam Can Help
Get Help Identifying RC4 Dependencies
We run a short assessment to identify RC4 dependencies before they become outages, prioritize fixes, and help validate remediation ahead of Microsoft’s enforcement deadlines