Microsoft has confirmed it will disable RC4 as the default assumed supported encryption type for Kerberos authentication on Active Directory domain controllers by the end of the second quarter of 2026. The change, disclosed in its documentation on detecting and remediating RC4 usage, closes the door on a legacy cipher that has been the source of Kerberos-based attacks for years. For organizations still relying on RC4—knowingly or not—the clock is now ticking.

The Phase-Out Plan at a Glance

Starting in late 2022, Microsoft shifted the Kerberos default encryption type from RC4 to AES-SHA1 for accounts where no explicit setting was defined, a change tied to CVE-2022-37966 and KB5021131. The goal was to curb Kerberoasting, an attack that exploits weak RC4-encrypted service tickets. While that update significantly reduced RC4 usage, it still allowed fallback for accounts and devices that didn't support AES. The upcoming Q2 2026 deadline removes that safety net: domain controllers will stop treating RC4 as a default option. Accounts that cannot use AES will see Kerberos failures unless administrators explicitly configure allowed encryption types.

Why This Matters for Your Organization

For home users and small businesses without on-premises Active Directory, this change is largely invisible. Managed services like Microsoft Entra ID (formerly Azure AD) already use modern protocols. The impact hits organizations that run their own domain controllers and have heterogeneous environments—older servers, legacy applications, appliances, or even non-Windows systems that authenticate via Kerberos.

A single RC4-dependent service can break file shares, remote PowerShell sessions, SQL Server connections, or any Kerberos-authenticated workload. Microsoft’s own troubleshooting guide calls out two classic failure modes: failed SMB access with a network error, and WinRM failures with error 0x80090342. These won’t appear gradually; they’ll surface the moment enforcement goes live. The lesson from previous Kerberos hardening updates is that blind spots are common. Identities created before Windows Server 2003, manually set encryption types, and appliances that never reset their machine passwords are the usual suspects.

How We Got Here: A Timeline of Kerberos Hardening

Kerberos has been a cryptographic workhorse in Windows since Windows 2000, but RC4’s inclusion as a default algorithm opened a long-running vulnerability. In 2014, the Kerberoasting technique was publicly documented, allowing attackers to request service tickets for SPNs and crack them offline if weak encryption was used. RC4-HMAC was particularly susceptible because of its speed. Microsoft’s response has been incremental:

  • November 2022: A security update changed the default Kerberos encryption type from RC4 to AES-SHA1 for accounts without an explicit setting, while still permitting fallback.
  • Windows Server 2025: Domain controllers were further hardened to stop issuing RC4 Ticket Granting Tickets entirely.
  • Mid-2026: The final step: RC4 will no longer be a default supported encryption type. Accounts that haven’t been updated to AES will be forced to use it only if explicitly allowed.

This timeline means organizations that haven’t started auditing are already behind. The 2022 change was intended as a grace period, but many environments still harbor RC4 dependencies.

Your Action Plan: Audit, Remediate, Monitor

Microsoft’s documentation, published alongside the deadline announcement, provides a detailed roadmap. Here’s how to approach it.

1. Inventory Every Kerberos Dependency

Don’t assume that only old Windows servers matter. Anything that authenticates with Kerberos is in scope: IIS web servers, SQL Server, Linux boxes joined to the domain, network appliances, scheduled tasks, and even cross-forest trusts. The first task is to identify all identities—user accounts, computer accounts, and service accounts—that may rely on RC4.

Microsoft now exposes RC4 usage directly in security event logs on Windows Server 2019 and later (and on Server 2016 with the January 2025 cumulative update). Events 4768 (TGT requests) and 4769 (service ticket requests) contain fields that reveal the encryption types advertised by the client and the session key used. Key indicators:

  • msDS-SupportedEncryptionTypes in the event shows the processed value for the account or target.
  • Advertized Etypes shows what the client claimed to support.
  • Session Encryption Type shows the actual encryption used for the ticket session key.

Manually combing through these logs is unfeasible. Microsoft provides two open-source PowerShell scripts from its Kerberos-Crypto GitHub repository:

  • List-AccountKeys.ps1: Enumerates accounts and their available encryption keys from the security event logs.
  • Get-KerbEncryptionUsage.ps1: Filters Kerberos events by encryption type; with the -Encryption RC4 parameter, it lists only RC4 usage.

Run these on domain controllers or via remote PowerShell. Collect data over a representative business period—including quarterly batch jobs and infrequently used services.

2. Classify and Remediate

For each RC4-using identity, determine why AES isn’t in play:

  • Missing AES keys: If a user or computer account was created before AES support came to Windows (around Server 2003), it lacks AES hashes in Active Directory. Solution: reset the account password. This generates new AES keys without any manual attribute tweaking.
  • Explicit msDS-SupportedEncryptionTypes: Some accounts have the attribute set to a value that excludes AES. Use Active Directory Users and Computers (with Advanced Features) or Get-ADObject to check. A decimal value of 4 (RC4 only) won’t cut it. For Windows machines, a reboot after correcting the attribute updates the computer’s effective encryption support.
  • Domain-level defaults: When msDS-SupportedEncryptionTypes is not defined, the domain controller falls back to DefaultDomainSupportedEncTypes, which historically includes RC4. Updating this registry value to 0x18 (AES only) is an option, but it’s a broad change. Better practice is to set the attribute per account where possible.

Third-party devices and older Linux systems that can’t handle AES require a different path. Microsoft urges customers to contact [email protected] for guidance on specific devices. Where immediate upgrade isn’t possible, create a narrowly scoped exception using Group Policy—more on that below.

3. Control RC4 with Group Policy (If You Must)

If you can’t eliminate all RC4 use by the deadline, you can explicitly allow it for the stragglers. The Group Policy setting Network security: Configure encryption types allowed for Kerberos (under Computer Configuration → Windows Settings → Security Settings → Local Policies → Security Options) lets you define allowed ciphers. You can scope it to specific OUs or groups.

For example:
- To allow only AES, check AES128_HMAC_SHA1 and AES256_HMAC_SHA1.
- To permit both AES and RC4, also check RC4_HMAC_MD5.

Alternatively, you can set the registry key DefaultDomainSupportedEncTypes on domain controllers to 0x18 to force AES-only globally. But this is a blunt instrument—test it in a lab first.

4. Don’t Forget Azure Files and Entra Domain Services

Your RC4 inventory isn’t complete if you only look at on-premises domain controllers. Two distinct control planes need separate treatment:

  • Azure Files with on-prem AD DS authentication: SMB file shares using this authentication method have their own pathway to AES-256. Microsoft’s documentation outlines a specific upgrade procedure. If you use Microsoft Entra Kerberos, Entra Domain Services, or storage account keys, you can skip this step.
  • Microsoft Entra Domain Services: Since Microsoft manages the domain controllers in this service, you cannot apply custom Group Policies or registry hacks. Instead, review the service’s official guidance and test your applications against the managed domain. File a support case if you find a dependency without a documented remediation.

5. Validate Every Fix End-to-End

A successful password reset or attribute change doesn’t prove AES is working. You must test the actual authentication path: client, KDC, identity, application, and target service. For file shares, map a drive from a representative client. For SQL, run a Kerberos-authenticated query. Compare event logs before and after to confirm that RC4 is gone and AES is in use. If something breaks, roll back the specific change, not the entire policy.

6. Create a Living Inventory

Track every RC4 dependency in a structured list. For each, record:

  • The service, application, or device name.
  • The affected identity and evidence of RC4 use (event ID, date, ticket type).
  • The remediation path—reference Microsoft’s or the vendor’s procedure.
  • The test plan and proof of success (attach logs).
  • If a temporary exception is needed, document the exact scope, approval, and expiration date. An exception without an owner and a deadline is just a pending outage.

What’s Next After RC4?

When the Q2 2026 deadline passes, Kerberos in Active Directory will finally be operating on modern ciphers. The immediate benefit is a drastic reduction in the risk of Kerberoasting. But cryptography doesn’t stand still. AES-128 and AES-256 are robust today, but future updates may push for SHA-256 variants or quantum-resistant algorithms. For now, the focus is on discipline: treat every RC4 dependency as a security debt item, and close it before the bill comes due. Organizations that act now will not only dodge the 2026 rush but also build the muscle memory for the next round of cryptographic hygiene.