Microsoft Is Ending RC4 and Phasing Out NTLM

March 24, 2026
Read Time: 5 mins

Microsoft is making two significant changes to Windows authentication in 2026.

RC4 encryption in Kerberos is being phased out through 2026 cumulative updates, and will move toward being blocked by default in a staged rollout.
NTLM is being phased out through a multi-stage deprecation, with default disablement planned for the next major Windows Server release.

Here is what each change means for your environment and how to prepare.

The End of RC4 in Kerberos

RC4 (Rivest Cipher 4) has been part of Kerberos authentication in Windows environments for decades. It stayed around primarily for compatibility. Older devices, legacy service accounts and third-party applications that never moved to stronger encryption. That compatibility window is now closing.

Why RC4 Has to Go

RC4 is vulnerable to attacks like Kerberoasting, where threat actors request service tickets encrypted with RC4 and crack them offline to steal credentials. The encryption is weak enough that this attack is fast and well-documented. Keeping RC4 in your environment is an open invitation for credential theft.

AES-SHA1 (specifically AES128 and AES256) has been available across all supported Windows versions since Windows Server 2008. There are very few remaining reasons to run RC4 in a modern environment. The security tradeoff stopped making sense a long time ago.

2026 RC4 Enforcement Timeline

Microsoft is rolling out changes to RC4-related Kerberos defaults in phases via cumulative updates. The exact timing can vary by update cadence and supported platform, but the overall sequence is audit/telemetry first, then enforcement later in 2026.

January 2026 (Audit/Telemetry Phase): Updates introduce additional auditing/telemetry to help identify RC4 dependencies and risky configurations. Enforcement is not the default behavior at this stage.
Mid-2026 (Enforcement Begins): A later phase of updates begins blocking RC4 usage that relies on weak defaults (for example, accounts without explicit encryption-type configuration). Environments that have not addressed dependencies may experience authentication failures.
Late-2026 (Full Enforcement / Reduced Rollback): Subsequent updates are expected to tighten enforcement further and reduce rollback options, increasing the likelihood of breakage where RC4 dependencies remain

How to Find RC4 in Your Environment

Microsoft has made auditing more accessible than ever. On domain controllers running Windows Server 2019, 2022 or 2025, two new PowerShell scripts are available in the Microsoft Kerberos-Crypto GitHub repository:

List-AccountKeys.ps1: queries the Security Event Log to show which accounts have RC4 keys but lack AES-SHA1 keys
Get-KerbEncryptionUsage.ps1: shows which encryption types Kerberos is actually using in your environment, with filtering by algorithm

Running these scripts against your domain controllers will surface service accounts, machine accounts and configurations that need attention before April.

For a broader view, Microsoft Sentinel and Windows Event Forwarding can ingest and query Events 4768 and 4769 at scale across larger environments.

Your RC4 Next Steps

Most remediation comes down to a few common scenarios:

Service accounts without AES keys
Reset the account password. Modern Windows domain controllers automatically generate AES128 and AES256 keys during a password reset.
Accounts with unconfigured msds-SupportedEncryptionTypes
Set this attribute explicitly in Active Directory so the account does not fall back to the domain default assumption.
Legacy devices that do not support AES
The last Windows version without AES support was Windows Server 2003. If you still have Server 2003 in your environment, migration is the only real answer.
Third-party applications hardcoded to RC4
These require vendor engagement. Microsoft wants to hear about these cases at [email protected].

NTLM Is Coming Off by Default

While RC4 is the immediate priority for Microsoft, NTLM is not far behind.

New Technology LAN Manager (NTLM) has been a fallback authentication protocol in Windows environments for more than 30 years. It functions as a challenge-response system, typically kicking in when Kerberos is unavailable—no line of sight to a domain controller, a local account, or an application that requests it directly. NTLM has been officially deprecated by Microsoft, but deprecation means it is still present and still functioning…but not much longer.

Why NTLM Is a Risk

NTLM uses weak cryptography and is vulnerable to replay attacks, pass-the-hash attacks and man-in-the-middle attacks. It also provides limited visibility, and, until recently, organizations had little insight into where NTLM was actually being used in their environment. Threat actors have exploited NTLM for credential theft and lateral movement for years. Keeping it running silently in the background is a liability most organizations do not fully account for.

The NTLM Phased Roadmap

Just like their plan for RC4, Microsoft has laid out a three-phase approach:

Phase 1 (Now): Enhanced NTLM auditing is available in Windows Server 2025 and Windows 11 version 24H2 and later. This gives IT teams their first clear picture of where NTLM is still in use, which devices are requesting it, which applications are triggering it, and which dependencies remain.
Phase 2 (Second half of 2026): Microsoft will release features designed to eliminate the most common reasons NTLM gets used as a fallback:
- IAKerb allows Kerberos authentication to succeed even when a device cannot directly reach a domain controller
- Local KDC enables Kerberos for local account authentication, eliminating one of the most common NTLM triggers
- Core Windows components will be updated to negotiate Kerberos first
These features will be available for Windows Server 2025 and Windows 11 24H2 and later.
Phase 3 (Next major Windows Server release): Network NTLM will be disabled by default. Re-enabling it will require explicit policy configuration. NTLM will still exist in the OS, but it will not operate unless an administrator deliberately turns it back on. Common edge cases—e.g., unknown SPNs, IP address-based authentication, local accounts on domain-joined machines—are intended to be addressed through the new capabilities built in Phase 2.

What You Should Do Now

NTLM’s deadline is less defined than RC4’s, but organizations that wait for Phase 3 to start their inventory will probably be caught off guard. The right time to act is during Phase 1 while auditing is available and before dependencies become emergencies.

Microsoft’s recommended steps:

Deploy enhanced NTLM auditing on Windows Server 2025 and Windows 11 24H2 devices
Map every application, service and workflow still triggering NTLM
Prioritize migrating critical workloads to Kerberos
Begin testing NTLM-off configurations in non-production environments
Engage application vendors where NTLM is hardcoded

Microsoft is no longer suggesting that organizations modernize authentication. It is enforcing it through default changes tied to standard Windows.

The organizations best positioned for these changes are the ones auditing now, not responding to outages later.

HBS works with organizations to assess authentication dependencies, close gaps in Active Directory health and modernize identity security before deadlines create downtime. If you are not sure where your environment stands, that is the right place to start.

Questions About RC4 or NTLM? Need Help with an Active Directory Health Check? Contact HBS Today.

RC4 and NTLM FAQs

Will RC4 be completely removed from Windows?

Not immediately. As of early 2026, Microsoft has no plans to remove RC4 from Windows entirely. What is changing is the default behavior: RC4 will no longer be assumed as a supported encryption type for service accounts that lack explicit configuration. Environments that have properly configured AES-SHA1 and set explicit encryption type attributes on service accounts will be unaffected. Environments that have not done this work will see authentication failures starting with the April 2026 cumulative updates.

My environment has a legacy system that only supports RC4. What are my options?

You have a few paths. First, if you define the DefaultDomainSupportedEncTypes registry key on all relevant domain controllers to explicitly include RC4, you can maintain compatibility while you address the dependency. Second, you can configure the msds-SupportedEncryptionTypes attribute directly on the service account to include RC4. These are stop-gap measures. The underlying system still needs to move to AES. If you have a third-party device or application that cannot support AES at all, Microsoft wants to hear from you at [email protected].

I see RC4 events in my Security Event Log. Does that mean I will break?

Not automatically. Events 4768 and 4769 log Kerberos ticket requests, and RC4 entries in those logs do not automatically indicate a breaking dependency. Focus on the ticket and session encryption types being used and whether accounts lack AES keys. Some updated domain controllers may also emit additional System log events that help flag at-risk configurations, but 4768/4769 remain central for Kerberos usage analysis.

What is the difference between NTLM being deprecated and being disabled?

Deprecated means Microsoft has signaled intent to remove the feature and stopped investing in it, but it still works. Disabled by default means Windows will ship in a state where NTLM network authentication is blocked and does not run automatically. Organizations that still need it must explicitly enable it through policy. NTLM is currently deprecated. The transition to disabled by default is coming with the next major Windows Server release. Organizations should treat today as an opportunity to audit and reduce NTLM usage before it becomes a forced migration.

Will disabling NTLM break our applications?

Potentially, yes…depending on how those applications authenticate. Applications that hardcode NTLM or fall back to it when Kerberos is not available will fail if NTLM is disabled. That is exactly why Microsoft is providing Phase 1 auditing tools now. IAKerb and Local KDC (coming in the second half of 2026) are specifically designed to address the most common scenarios that have historically forced NTLM fallback. Identifying NTLM-dependent applications before Phase 3 lands is the most important thing your team can do today.

Does NTLM being disabled mean it will be removed from Windows?

No, not at Phase 3. When NTLM is disabled by default in the next major Windows Server release, it will still exist in the operating system and can be re-enabled via policy. The long-term direction is full removal, but Microsoft is committed to a phased approach that gives organizations time to complete the transition.

Should we wait for Microsoft to handle this automatically through Windows Update?

No. The updates will enforce the changes whether your environment is ready or not. The January 2026 update already shifted behavior and added new audit events. April 2026 begins blocking authentication. Relying on Windows Update without performing an audit first is how organizations end up with unexpected authentication failures in production.