Microsoft has set a firm deadline to end a decades‑long compatibility compromise: by mid‑2026 domain controllers running Windows Server 2008 and later will default to issuing
AES‑SHA1 Kerberos session keys and
RC4 will be disabled by default, forcing organizations to find and remediate remaining RC4 dependencies or explicitly opt into the weaker cipher for backward compatibility.
Background
For nearly a quarter century Windows Active Directory environments allowed multiple Kerberos encryption types (enctypes). RC4‑HMAC (commonly referred to as
RC4) persisted as a ubiquitous fallback because it provided broad interoperability with legacy clients and third‑party appliances. That compatibility choice became a persistent security liability: RC4’s cryptographic weaknesses and the way Windows derived NTLM/RC4 keys made certain offline attacks — notably
Kerberoasting — much cheaper and more practical. Microsoft’s recent public guidance, product blog posts, and updated Learn content formalize a multi‑phase retirement plan: the Kerberos Key Distribution Center (KDC) on domain controllers running Windows Server 2008 and later will flip its defaults so AES‑SHA1 enctypes are used by default and RC4 will be disabled unless a domain administrator explicitly allows it. The change is explicitly scheduled as a default flip
by the end of Q2 2026 (mid‑2026).
Why this matters: the attack surface and operational urgency
Kerberoasting is the clearest operational case against RC4 in Kerberos: any low‑privilege domain user can request a service ticket (TGS) for a Service Principal Name (SPN), extract the ticket, and perform an offline password crack. Tickets encrypted under RC4 and NTLM‑derived keys are far cheaper to brute‑force than AES‑protected tickets, which use stronger key derivation and HMAC constructs. Removing RC4 as the default raises the computational cost of many offline attacks and reduces the population‑level exposure to simple, high‑impact attacks directed at service accounts. The decision also responds to public scrutiny and regulatory pressure following real‑world incidents where Kerberos abuse enabled widespread lateral movement. Lawmakers and incident responders have cited cases where legacy defaults amplified attacker impact — adding urgency to a vendor‑driven forcing function. Microsoft stresses the change is about safer defaults, not an immediate, universal removal; administrators still have opt‑in exceptions but those must be governed tightly to avoid long‑term risk.
What Microsoft is changing — the technical specifics
Default KDC behavior and scope
- Domain controllers (KDCs) on Windows Server 2008 and later: default session keys will be AES‑SHA1 (AES128/AES256 CTS‑HMAC‑SHA1‑96 family) and RC4 will be disabled by default. RC4 remains available only when explicitly configured by an administrator.
- Windows Server 2025 and later: Microsoft notes domain controllers in updated SKUs already reduced RC4 issuance (for example, RC4 Ticket Granting Tickets were phased out in recent Windows Server updates), but the mid‑2026 change is the global default flip for the broader installed base. Administrators should not assume automatic removal for all environments until the timeline completes.
New audit telemetry and visibility
Microsoft has extended Kerberos‑related Security Event Log entries (notably
Event ID 4768 for TGT requests and
Event ID 4769 for service tickets) with new fields to make encryption negotiation visible:
- msDS‑SupportedEncryptionTypes — what enctypes the account advertises.
- Available Keys / Account Keys — which derived key material exists for the account (e.g., RC4 only vs. AES keys present).
- Advertised Etypes — client‑advertised enctypes in AS‑REQ/TGS‑REQ messages.
- Ticket Encryption Type / Session Encryption Type — the enctype used for specific tickets/sessions.
This richer telemetry lets admins answer whether remaining RC4 usage is a
client problem (devices advertising only RC4), a
service/account provisioning problem (accounts lacking AES keys), or a
KDC/policy issue.
Diagnostic and remediation tooling
Microsoft published PowerShell helpers and example scripts aimed at large‑scale discovery and remediation:
- List‑AccountKeys.ps1 — enumerates Available Keys for accounts and flags accounts lacking AES key material.
- Get‑KerbEncryptionUsage.ps1 — summarizes recent Kerberos usage and can filter for RC4 session keys.
Combined with centralized log collection (Event Forwarding, SIEM, or Microsoft Sentinel), these tools form the operational backbone for inventory, triage, and phased remediation.
Practical migration mechanics — an operational checklist for CIOs and AD teams
The change is simple in principle but operationally complex in practice. Below is an actionable, prioritized plan to prepare for the mid‑2026 default flip.
1. Inventory (mandatory, first step)
- Forward Event IDs 4768 and 4769 from all domain controllers to a SIEM or central log store.
- Run Get‑KerbEncryptionUsage.ps1 to produce a baseline report of Ticket/Session encryption types (filter for RC4).
- Use List‑AccountKeys.ps1 to list accounts that have RC4 key material but no AES keys.
2. Triage and prioritization
- High priority: service accounts with SPNs that are critical to production infrastructure (application servers, database services, middleware).
- Medium priority: third‑party appliances in production that cannot be updated immediately.
- Low priority: test lab equipment and devices scheduled for decommissioning.
Prioritize by business impact and exposure: an RC4‑protected service account used by a public‑facing web tier demands higher urgency than an isolated test device.
3. Remediation actions
- For accounts missing AES keys: perform controlled password resets to generate AES key material. Validate with a follow‑up run of List‑AccountKeys.ps1 to confirm AES keys are present.
- For clients advertising only RC4: patch or replace the client, update the client configuration to support AES enctypes, or isolate the device behind compensating network controls until it can be modernized.
- For third‑party appliances that cannot be updated: engage vendors for firmware/patch timelines; where vendor updates are impossible, plan for isolation, proxying, or application segmentation.
4. Test and stage the policy
- Implement Group Policy restrictions for Kerberos encryption types in a lab or staging domain first (Network security: Configure encryption types allowed for Kerberos).
- Use Windows Admin Center and controlled domain controllers to validate application behavior under AES‑only negotiation.
5. Governance for exceptions
- Any decision to re‑enable RC4 must be temporary, documented, and time‑boxed with a clear remediation target date.
- Maintain a tracked exceptions register that includes risk assessments and compensating controls (network segmentation, dedicated authentication proxies).
6. Detection and monitoring updates
- Add SIEM rules and Sentinel query alerts for any new occurrences of RC4 session keys.
- Integrate Kerberos‑specific detections (unusual TGS/AS‑REQ patterns, spikes in RC4 use) into incident‑response playbooks and tabletop exercises.
Technical verification and cross‑checks
Key technical claims and dates in this article have been verified against Microsoft’s official guidance and independent security journalism. Microsoft’s Learn documentation explicitly states the mid‑2026 target to disable RC4 as a default for Active Directory domain controllers and details the new audit fields and remediation scripting. Independent reporting from security outlets (detailed technical analysis and reporting) confirms the timeline and contextualizes operational impacts and public scrutiny. Administrators should treat Microsoft’s documentation as the authoritative source for configuration details while using independent reporting for operational context. Caveat: schedules and enforcement mechanisms may evolve. Organizations should validate final behavior in Microsoft’s release notes and product updates close to the enforcement date and test changes in lab domains before production rollout. If any claim about a Windows SKU or update is particularly consequential to an organization’s environment, confirm that specific SKU’s release notes and cumulative updates before taking action.
Critical analysis: strengths, potential gaps, and risks
Strengths of Microsoft’s approach
- Safer defaults at scale. Flipping a default is the single most effective way vendors can reduce systemic risk across heterogeneous customer bases; making AES the default will substantially reduce population‑level exposure.
- Practical remediation tooling. The combination of richer Event Log fields and PowerShell scripts makes discovery actionable; this is far better than abstract guidance alone.
- Phased rollout and compatibility escape hatches. Allowing opt‑in RC4 settings and providing a runway helps avoid operational outages in environments with genuine legacy dependencies.
Risks and operational pitfalls
- Exceptions calcify into permanent risk. Historically, temporary compatibility fixes become entrenched unless governed. Organizations that re‑enable RC4 without firm deadlines and controls may leave long‑term vulnerabilities in place. Exception governance is the single biggest operational risk.
- Third‑party vendor lag. Numerous embedded systems and appliances still lack AES Kerberos support; vendor upgrade timelines often lag enterprise remediation windows, creating friction and fragmentation. This will force many organizations to choose between availability and security.
- Incomplete remediation for weak passwords. AES enctypes raise the cost of ticket cracking but do not substitute for strong service account passwords. If weak, unsalted, or non‑rotated passwords remain, attackers can still brute‑force accounts even when AES is used; remediation must combine cryptographic upgrades with credential hygiene.
- Operational complexity for large estates. Identifying a handful of legacy devices is straightforward; discovering and remediating tens of thousands of endpoints across multiple domains, partners, and cloud connectors requires significant investment in inventory, logging, and automation. The mid‑2026 deadline is a hard operational milestone for CIOs.
Political and regulatory context
Public scrutiny — including congressional attention — has amplified the reputational cost of weak defaults. This creates a policy environment where vendors and regulated entities are under pressure to remove legacy dangerous behaviors. While Microsoft’s phased approach aims to balance compatibility and security, regulators and auditors may expect proactive remediation and strict exception governance going forward.
Recommended remediation playbook for the next 12 months
- Run discovery scripts and centralize Kerberos event telemetry within 30 days.
- Produce a prioritized remediation roadmap focused on SPN‑bearing service accounts and production appliances.
- Execute controlled password resets for service accounts lacking AES keys and validate AES key material appears in the “Available Keys” audit field.
- Engage vendors immediately for any devices that cannot support AES; plan for isolation or replacement.
- Implement a strict, auditable exceptions process: every RC4 re‑enable must have an expiration date and business justification.
- Update SIEM and detection capabilities for Kerberos‑specific telemetry; add playbooks for Kerberoasting and ticket‑forging incident response.
Crypto agility and longer‑term strategy
This RC4 deprecation is a critical test of
crypto agility — the ability of an organization to swap out cryptographic primitives or change policies with minimal operational disruption. Successful organizations will treat this event as more than a one‑off: it is a prompt to build systems that:
- Allow cryptographic suites to be configured centrally and rolled out safely.
- Instrument authentication flows end‑to‑end (client, service, KDC) so negotiation failures are visible before defaults change.
- Maintain a vendor management program that requires secure cipher support for new procurement.
These investments yield recurring benefits beyond RC4: they reduce future migration costs and accelerate response to emerging cryptographic discoveries.
What success looks like
- A measurable reduction in RC4 session keys across Kerberos events and a corresponding rise in AES‑protected tickets in SIEM dashboards.
- No unplanned authentication outages for critical services during and after the default flip.
- A small, time‑boxed set of documented, controlled exceptions that are resolved before their exception expiry.
- Evidence of improved credential hygiene for service accounts (stronger passwords, gMSAs, rotation), and integrated Kerberos detections in the SOC playbook.
Conclusion
Microsoft’s mid‑2026 default change to disable RC4 in Kerberos is a practical, overdue step to harden Active Directory infrastructure and reduce the attack surface for ticket‑based offline attacks such as Kerberoasting. The vendor is providing the necessary visibility and tooling — richer Kerberos audit fields and PowerShell helpers — to make remediation feasible, but the technical fix must be accompanied by disciplined operational governance, vendor engagement, and credential hygiene.
CIOs and security leaders should treat the mid‑2026 date as an operational deadline: run discovery now, prioritize high‑risk service accounts, engage vendors for non‑compliant appliances, and lock down any temporary re‑enablements with strict expiration and compensating controls. This is an opportunity to convert a long‑standing compatibility debt into a durable security improvement — if organizations use the runway wisely.
Source: The National CIO Review
Microsoft Targets Legacy Encryption: RC4 to Be Disabled in Kerberos - The National CIO Review