Windows Kerberos Default Change: AES Enctypes Now By Default, RC4 Disabled by 2026

Microsoft is flipping a decades‑old Kerberos default in Windows Server — and IT teams must treat it as an operational deadline, not a theoretical security tweak.

Background / Overview​

Microsoft has announced a change to how the Kerberos Key Distribution Center (KDC) on Windows domain controllers will select encryption types for Kerberos session keys: AES‑SHA1 (AES128/AES256 CTS‑HMAC‑SHA1‑96) will become the default enctype, and RC4 (RC4‑HMAC / RC4‑NTLM‑derived) will be disabled by default unless explicitly allowed by a domain administrator. This change applies to domain controllers running Windows Server 2008 and later and is being rolled out as a default flip with a planning and enforcement timeline targeting mid‑2026.
This is not a simple "turn off a cipher" story. The move addresses real, practical risks — especially Kerberoasting — and it introduces new visibility and remediation tooling to help large, heterogeneous environments migrate without catastrophic breakage. Microsoft has published operational guidance and PowerShell helpers to inventory and remediate remaining RC4 dependencies.

---

Why this matters now​

The practical risk: Kerberoasting and offline cracking​

Kerberoasting is an attack wherein any valid domain user requests a service ticket (TGS) for a Service Principal Name (SPN), extracts the portion encrypted with the service account’s key, and performs offline password cracking against that ticket. When that ticket is protected with RC4/NTLM‑derived keys, the cost to crack passwords is dramatically lower than for AES‑protected tickets because of weak key derivation and the lack of salt and iteration in the historic NTLM-based key derivation used for RC4. That makes service accounts — particularly those with weak or rarely rotated passwords — a low-bar, high-payoff target for attackers. Removing RC4 as the default raises the computational cost for attackers and reduces population‑level exposure to these offline attacks.

Cryptographic reality: RC4 legacy vs modern AES enctypes​

RC4 is a stream cipher with decades‑old cryptanalytic weaknesses that the industry long ago deprecated for TLS; those same cryptanalytic realities undermine RC4’s suitability for identity tokens. AES‑based Kerberos enctypes use stronger key derivation and HMAC constructions that make offline ticket cracking orders of magnitude harder. The change aligns Kerberos defaults with modern cryptographic expectations.

---

What Microsoft is changing — technical specifics​

Default KDC behavior and scope​

• Domain controllers (KDCs) on Windows Server 2008 and later will, by default, issue AES‑SHA1 session keys.
• RC4 will be disabled by default for KDC ticket issuance; it will still be available only if a domain administrator explicitly configures an exception.
• The change is being positioned as a default flip rather than an immediate, universal removal to reduce abrupt breakage in legacy environments.

New Kerberos telemetry in the Security event log​

Microsoft has extended Kerberos‑related Security Event Log entries — notably Event ID 4768 (TGT requests) and 4769 (service ticket issuance) — to include richer fields that reveal:

• msDS‑SupportedEncryptionTypes — what encryption types the account or DC advertises
• Available Keys / Account Keys — which derived key material exists for the account (e.g., whether AES128/AES256 keys are present)
• Advertised Etypes — what clients advertise during AS‑REQ/TGS‑REQ negotiations
• Ticket Encryption Type / Session Encryption Type — the actual enctype used for particular tickets/sessions

This richer telemetry is specifically intended to make discovery actionable at scale.

Diagnostic tooling and automation​

Microsoft published PowerShell helpers and scripts (for example, List‑AccountKeys.ps1 and Get‑KerbEncryptionUsage.ps1) to enumerate accounts lacking AES keys, summarize recent Kerberos usage, and flag RC4 session usage across DCs. The vendor also documented Group Policy and Windows Admin Center workflows for enforcing allowed encryption types. These scripts are intended to form the backbone of large‑scale inventory and phased remediation projects.

---

Operational impacts and compatibility risks​

Who is likely to break?​

• Legacy appliances and third‑party network devices that only support RC4 for Kerberos/SPN authentication.
• Older Windows clients or embedded devices that were never updated to provision AES keys for machine/service accounts.
• Custom applications that depend on specific service account encryption behaviors or use antiquated APIs.

Breaking these systems can produce authentication failures that are hard to debug if administrators lack centralized Kerberos telemetry or a staged rollout plan.

Why this is operationally painful​

The default flip changes a behavior that many environments have tolerated for years purely because it was compatible. Replacing compatibility with safety will force teams to confront decades of undocumented exceptions, old appliances, and custom integrations. The operational cost is not negligible: remote offices with specialized printers, legacy ERP connectors, or older imaging systems are common sources of post‑change incidents. Microsoft explicitly warns administrators that they must inventory and remediate before the default flips to avoid service disruptions.

---

What IT teams must do now — an actionable plan​

Below is a practical, prioritized plan IT and security teams should adopt immediately.

• Inventory — collect facts first.
• Forward Event IDs 4768 and 4769 from all domain controllers to a central SIEM or log store.
• Run Get‑KerbEncryptionUsage.ps1 to produce a baseline of recent ticket:session encryption types and filter for RC4 usage.
• Identify accounts lacking AES keys.
• Use List‑AccountKeys.ps1 to enumerate accounts that lack AES key material (these accounts will fall back to RC4 unless updated).
• Triage by business impact.
• Create a risk matrix: critical services, high‑impact applications, and devices that must be tested in pilot rings before broader remediation.
• Remediate service accounts and devices.
• For service accounts that lack AES keys, perform a controlled password reset to force directory replication of AES key material.
• Update or replace legacy appliances where vendor updates are unavailable; engage vendors early for firmware or software patches.
• Test in a staged manner.
• Build a pilot OU and point a subset of domain controllers to the changed policy in test before any broad enablement. Validate authentication flows for each client type.
• Establish an exception governance process.
• If RC4 must remain enabled for compatibility, require a documented, time‑boxed exception with compensating controls (network isolation, strict ACLs, monitoring).
• Monitor and iterate.
• Continue centralized log collection; measure RC4 session decline over weeks. Use SIEM alerts to detect regression.
• Final enforcement and audit.
• Before the vendor default flips to AES by mid‑2026, remove exceptions that are no longer necessary and audit the environment for stale accounts and unused SPNs.

This is a five‑to‑six month operational program for many organizations; starting now is essential.

---

Hardening best practices that reduce exposure even if RC4 still exists​

• Enforce complex, long passwords for service accounts and rotate them regularly. Service account credential hygiene dramatically reduces Kerberoasting success even when weaker enctypes exist.
• Use managed (group) or virtual managed service accounts where possible to avoid static passwords.
• Constrain and limit service principal names (SPNs) and service account privileges via least privilege.
• Enable robust monitoring for abnormal ticket requests and unusual Kerberos behavior; forward enriched Kerberos events to EDR/SIEM.
• Consider network segmentation for legacy devices that cannot be immediately upgraded.

---

Critical analysis: strengths and potential risks​

Strengths of Microsoft’s approach​

• Safer defaults: Moving to AES by default materially increases the cost of offline attacks and reduces population‑level risk. This is the classic security principle of secure by default, which benefits organizations that lag in proactive configuration.
• Operational tooling: Releasing PowerShell scripts and richer event telemetry makes discovery and targeted remediation feasible at enterprise scale rather than leaving admins to blind‑search for issues.
• Staged flip, not an immediate removal: Microsoft preserved an escape hatch (opt‑in RC4) to avoid wholesale outages, and the staged timetable gives teams runway to act.

Risks and tradeoffs​

• Compatibility breakage is real: Legacy appliances and niche software may fail silently, causing business impact that is sometimes non‑trivial to diagnose. Organizations with constrained update windows (medical devices, industrial control systems) face elevated operational complexity.
• Exception creep: Allowing explicit re‑enablement of RC4 can lead to poor governance and long‑term risk if exceptions are not strictly time‑boxed and monitored. Each exception is a reintroduced attack surface if left ungoverned.
• Vendor coordination is required: Some non‑Microsoft vendors will need to issue firmware or software updates for their appliances; absent vendor fixes, the only options are compensating controls or device replacement, both of which can be costly.

Political and public context (caveated)​

Reports in the community indicate public and regulatory attention to identity‑based abuse and the role of weak defaults in high‑impact incidents. While this context likely accelerated vendor timelines, any specific attribution of cause or congressional involvement should be treated as “reported” unless confirmed via vendor or legislative records. Flagging these as reported, not proven, is prudent.

---

Example runbook: 30‑day starter checklist (for busy IT managers)​

• Day 1–3: Enable centralized collection of Event IDs 4768/4769 and run Get‑KerbEncryptionUsage.ps1.
• Day 4–10: Run List‑AccountKeys.ps1 and compile a prioritized list of accounts missing AES keys.
• Day 11–20: Engage application and device owners; schedule password resets for non‑critical service accounts to provision AES keys.
• Day 21–25: Build a test pilot OU; apply stricter allowed enctype policy to a subset of DCs and run full authentication regression tests.
• Day 26–30: If pilot is successful, plan staged rollouts across locations, and implement exception governance for unavoidable RC4 dependencies.

This runbook is intentionally narrow — a pragmatic start you can execute in a month to build momentum toward a mid‑2026 enforcement posture.

---

Monitoring and validation after remediation​

• Validate by tracking the decline of RC4 session tickets in Event ID aggregates. A measured drop over weeks indicates success.
• Use SIEM alerting on any reappearance of RC4 session keys, and correlate those alerts with service owners for immediate remediation.
• Maintain a documented inventory of exceptions with expiration dates and compensating controls.

---

Final assessment and practical takeaway​

Microsoft’s default flip away from RC4 toward AES for Kerberos session keys is a long‑overdue hardening step that addresses a real, attacker‑friendly weakness. The move improves baseline security posture and reduces the ease of Kerberoasting and offline ticket‑cracking attacks. However, the change also introduces a non‑trivial operational program for enterprises: inventory, remediation, vendor coordination, staged testing, and tight exception governance are all required to avoid service disruptions.
For IT administrators and security teams, the operational imperative is clear: treat the vendor timeline as a planning deadline and begin inventory and remediation immediately. Use the vendor‑provided PowerShell tooling and enriched Kerberos telemetry to create a prioritized, testable program. Where RC4 remains necessary for legacy compatibility, document, isolate, and time‑box exceptions while accelerating vendor engagement or replacement planning.
Security‑by‑default matters — but so does measured, documented operational change management. The work required to migrate is real, and starting now will turn a disruptive enforcement event into a controlled modernization project that measurably reduces enterprise risk.

---

---

Source: Neowin https://www.neowin.net/news/microso...ent-it-admins-warned-about-new-configuration/