Microsoft’s July 14, 2026 cumulative updates will strip out the long‑standing Kerberos RC4 rollback control from all supported Windows Server domain controllers. At the same time, administrators must verify that the Microsoft Malware Protection Engine—the core of Microsoft Defender Antivirus—meets a minimum version requirement, or they risk service disruptions after the patches land.

This move ends an era of RC4‑HMAC encryption for Kerberos authentication in Active Directory. For the past two years, organizations have had the option to temporarily revert to the weaker cipher when applications or services couldn’t yet handle AES. That safety net disappears on July 14.

What’s Changing in the July 14 Updates

The upcoming Patch Tuesday updates—expected to be wrapped into the standard monthly cumulative rollups for Windows Server 2016, 2019, and 2022—will permanently remove the KdcUseRequestedEtypesForTickets registry key and the associated logic that allowed domain controllers to fall back to RC4 encryption for Kerberos tickets. After installing the updates, there is no supported method to re‑enable RC4 fallback.

The change does not disable RC4 entirely. Domain controllers will still accept requests that use RC4 encryption if a client or service explicitly asks for it. However, the “rollback” behavior—where a DC could be forced to answer a modern AES request with an RC4 ticket when interoperability demanded it—is dead. If a service account or a trust relationship is only capable of RC4, authentication may break the moment the update is applied.

An additional, less‑advertised change sits inside the same update bundle. According to what appears to be a draft security bulletin circulated to some administrators, organizations must independently confirm that the Microsoft Malware Protection Engine—the detection heart of Microsoft Defender Antivirus—is updated to a specific version number. The advisory suggests that if the engine is too old, protection services may fail silently or, worse, cause domain‑joined machines to hang during boot or report authentication errors after the Kerberos change. The exact version number wasn’t included in the excerpt we reviewed, but Microsoft is expected to publish a full Knowledge Base article (likely a KB starting with 503…) with the precise threshold well before July 14.

Double‑Barreled Requirement: Why the Antivirus Engine Matters

Tying a Kerberos configuration change to an antivirus engine update might seem odd, but there’s precedent. Microsoft has been incrementally hardening its security stack, and several components—including the Microsoft Protection service, Windows Defender Application Control, and even portions of the Security Accounts Manager—now authenticate using Kerberos under the hood. An outdated malware protection engine might still rely on RC4‑encrypted ticket exchanges. If that engine is what runs during early‑stage boot or before the domain controller has an opportunity to process an AES request, the mismatch can result in failures that are hard to diagnose.

Administrators should interpret this as a “check before you deploy” rather than a “maybe later.” The bulletin reportedly states that the update will proceed even if the engine is out of date—the installer won’t block—but unsupported configurations will be left with an unknown operational state. That is a polite way of saying “proceed at your own risk.”

What This Means for Your Organization

For system administrators and identity managers, July 14 is a hard deadline to finish any pending Kerberos hygiene work. Here’s how the removal of the RC4 rollback will ripple through a typical enterprise:

  • Direct Authentication Failures: Any account—user, computer, or service—whose msDS-SupportedEncryptionTypes attribute is set to a value that includes RC4 (0x4) but not AES (0x8, 0x10, 0x20) will be unable to obtain a service ticket from a DC that has the update installed. This includes managed service accounts, IIS application pool identities, SQL Server service accounts, and many third‑party appliances.
  • Cross‑Forest and External Trusts: If a trust was configured with a “Use DES encryption types for this trust” flag or relies on RC4, authentication across the trust will break. The rollback removal cannot be sidestepped by switch‑home‑side‑only—both sides must support AES.
  • Legacy Windows and Non‑Windows Systems: Systems running Windows Server 2003 (if any still exist), older Linux distributions with pre‑1.15 MIT Kerberos, or macOS versions prior to Mavericks (10.9) may default to RC4. Even if an AES‑capable Kerberos library is available, the client may be pinned to RC4 in its configuration file (e.g., krb5.conf).
  • Auditing and Monitoring: Domain controllers will generate event ID 4769 (Service Ticket Request) with failure code 0x19 (KDC_ERR_ETYPE_NOSUPP) when a client requests an unsupported encryption type. Event ID 4771 (Pre‑authentication) and 4768 (TGT request) may also surface RC4‑only attempts. Security teams should set up alerts for a spike in these events immediately after patching.

For end users, the impact is indirect: applications or network shares that rely on RC4‑authentication may stop working, producing “access denied” errors or repeated password prompts. Power users who run their own lab domains at home should follow the same audit steps if they are using a domain‑joined server.

How We Got Here

The Kerberos RC4 deprecation has been a slow‑burn story since 2022, punctuated by several milestones:

  • November 2022: Microsoft introduced the rollback control and a corresponding registry key (KdcUseRequestedEtypesForTickets) in the November security updates. The change allowed domain controllers to prioritize AES encryption for Kerberos tickets, but the rollback let administrators flip a switch to revert to the old behavior if things went wrong.
  • April 2023: A series of updates changed the default value of the rollback registry key from “disabled” (i.e., allow RC4 fallback) to “enabled” (block it). New domains were immediately unaffected, but existing domains were grandfathered until admins manually intervened.
  • May 2024: Microsoft signaled that the rollback was a temporary crutch. In a Tech Community post, the identity security team warned that “the rollback control will be removed in a future update” and urged customers to complete their AES migration.
  • January 2026: The first whispers of a final cut‑off date began circulating in the Microsoft Security Response Center (MSRC) preview of upcoming changes. July 14 was tied to the “C” week of the Patch Tuesday cycle.
  • Today: The removal is now a confirmed item in the July 14 cumulative update bundles, not a phased‑out extension.

Why remove it at all? RC4‑HMAC has been cryptographically weak for over a decade. It’s susceptible to brute‑force attacks, particularly when combined with a predictable service principal name (SPN) in what attackers call Kerberoasting. Microsoft’s own threat intelligence reported a 300% increase in Kerberoasting attempts between 2023 and 2025. Eliminating the ability to fall back to RC4 slams shut a vector that has been exploited relentlessly.

What to Do Now

Time is short—here are the concrete steps every AD administrator should take before July 14.

1. Audit Encryption Types Across the Enterprise

Identify every principal that might be using RC4. Run this PowerShell snippet from a Domain Controller or a machine with the ActiveDirectory module:

Get-ADUser -Filter * -Properties msDS-SupportedEncryptionTypes |
    Where-Object { $_.msDS-SupportedEncryptionTypes -band 0x4 } |
    Select Name, SamAccountName, msDS-SupportedEncryptionTypes

Get-ADComputer -Filter * -Properties msDS-SupportedEncryptionTypes |
    Where-Object { $_.msDS-SupportedEncryptionTypes -band 0x4 } |
    Select Name, msDS-SupportedEncryptionTypes

Don’t stop at accounts: use the same logic for Get-ADTrust to examine the TGTEncryptionType attribute of each trust.

2. Update or Retire RC4‑Only Accounts and Trusts

  • Service Accounts & GMSAs: If the account must stay, update the encryption type to include AES (add 0x8). For Group Managed Service Accounts, you can also recreate them; they default to AES.
  • Computer Accounts: Domain‑joined Windows machines negotiate the strongest encryption type by default, but verify that Group Policy isn’t restricting them. Check Computer Configuration\Policies\Windows Settings\Security Settings\Local Policies\Security Options\Network security: Configure encryption types allowed for Kerberos.
  • Trusts: Re‑establish the trust with AES support. For external trusts, make sure the trusting side’s domain controllers are also patched and configured for AES.
  • Third‑Party Devices: Contact vendors for firmware updates or configuration changes that enable AES Kerberos authentication. If no AES support exists, consider replacing the device or moving to password‑based fallback where acceptable.

3. Verify the Microsoft Malware Protection Engine Version

  • Open Windows Security → Virus & threat protection → Virus & threat protection settings → About.
  • The “Engine version” line should be 1.1.xxxxx.x or later. Microsoft will publish the exact minimum required version in the KB article for the July 14 update. Pro tip: You can also query it with Get-MpComputerStatus | Select-Object AMEngineVersion.
  • If the engine is out of date, run a manual update: open Command Prompt as Administrator and execute "%ProgramFiles%\Windows Defender\MpCmdRun.exe" -SignatureUpdate. Then confirm the version.

4. Test in a Lab

Stand up a non‑production domain controller that mirrors your production forest, apply the July 14 update early, and attempt authentication from a variety of clients. Use klist on Windows or kvno on Linux to observe ticket encryption types. Break glass accounts or old test users are ideal guinea pigs.

5. Prepare Monitoring and Rollback Readiness

Even though there is no official rollback, Microsoft often leaves an undocumented, time‑limited reg key in extreme cases. Prepare your monitoring by:
- Creating an Azure Monitor workbook or Log Analytics query that tracks event ID 4769 failure codes over time.
- Setting a threshold alert for more than 10 0x19 failures per hour on any DC.
- Having a documented, offline backup of the pre‑update domain controller state (VM snapshot or bare‑metal backup) so you can restore in the worst case. There is no supported way to uninstall the cumulative update without restoring.

Outlook

The July 14 update marks the final chapter in a multi‑year effort to deprecate a legacy encryption type that has outlived its usefulness. For most organizations that have already modernized, this will be a non‑event. For stragglers, the next few weeks are a forced march toward better security.

After this, the next obvious question is whether NTLM will receive a similarly hard deadline. Microsoft has been baking “extended protection for NTLM” into server builds, but a total removal seems unlikely before the end of the decade. Still, the Kerberos RC4 rollback’s fate shows that Microsoft is willing to close doors permanently—and those who wait until the last minute may find them already locked.