Futuristic data center with neon encryption icons, security shields, and a glowing chain.

Microsoft has begun a staged hardening of Kerberos on Windows domain controllers: starting with security updates released on January 13, 2026, domain controllers will gain new telemetry and audit controls that identify weak Kerberos encryption usage, and Microsoft plans a phased default flip so Kerberos KDCs on Windows Server 2008 and later will prefer AES‑SHA1 enctypes while RC4 will be disabled by default unless explicitly allowed — with a second deployment in April 2026 and full enforcement scheduled by July 2026.

Background​

Why this matters now​

Kerberos encryption type selection determines how hard it is for an attacker to perform offline cracking of service account credentials extracted from Kerberos tickets. The long‑standing presence of RC4‑HMAC (often called RC4 in Windows documentation) has been a compatibility concession for many legacy clients and third‑party appliances, but RC4’s cryptanalytic weaknesses and the older NTLM/RC4 key derivation approach used in Windows significantly lower the cost of offline attacks such as Kerberoasting. The operational result is that service accounts with weak or rarely rotated passwords become high‑value, low‑effort targets. Microsoft explicitly frames the change as raising the bar for attackers by moving to AES‑based enctypes as the default for KDC session keys.

What’s prompting the change​

Microsoft tied the hardening to a Kerberosre vulnerability tracked as CVE‑2026‑20833, published January 13, 2026, where use of a broken or risky cryptographic algorithm in Windows Kerberos could allow an authorized attacker to disclose information locally. Microsoft’s fixes delivered both telemetry and a staged configuration path to stop issuing RC4 tickets by default, while giving administrators time and tooling to inventory and remediate remaining RC4 dependencies. Public reporting and security vendors echoed Microsoft’s timeline and rationale.

Overview of the change: what Microsoft is changing, in plain terms​

  • Domain controllers running Windows Server 2008 and later will change KDC defaults so that the KDC issues AES‑SHA1 session keys (AES128/AES256 CTS‑HMAC‑SHA1‑96 family) for accounts that do not have an explicit msDS‑SupportedEncryptionTypes attribute, and RC4 will be disabled by default unless explicitly reenabled per‑account or per‑KDC.
  • The update sequence is phased:
    • January 13, 2026 — Initial deployment: updates begin shipping; added audit telemetry appears and a temporary registry control (RC4DefaultDisablementPhase) lets admins opt‑in earlier where safe.
    • April 2026 — Second deployment: the default value for DefaultDomainSupportedEncTypes (DDSET) will change to AES‑SHA1 only (0x18) for accounts without explicit msDS settings.
    • July 2026 — Enforcement: audit‑only controls and RC4DefaultDisablementPhase are removed and Enforcement mode will be enabled broadly. At that point, non‑compliant RC4 connections will be blocked unless an exception was explicitly configured.
  • Microsoft ships enhanced Kerberos telemetry fields in Windows Security and System event logs (notably extended information on Event IDs such as 4768 and 4769, plus KDCSVC events) so admins can answer whether RC4 is in use because clients advertise it, accounts lack AES keys, or the KDC is configured to permit RC4. The vendor also relers (List‑AccountKeys.ps1, Get‑KerbEncryptionUsage.ps1) and guidance for staged remediation.

Technical specifics: how Kerberos behavior changes​

DefaultDomainSupportedEncTypes (DDSET) and msDS‑SupportedEncryptionTypes​

The KDC’s choice of ticket encryption is influenced by two things:

  • the domain controller’s DefaultDomainSupportedEncTypes (DDSET), a registry value that establishes the KDC’s default behavior, and
  • the per‑account Active Directory attribute msDS‑SupportedEncryptionTypes, which explicitly advertises which enctypes are acceptable for a given account.

Microsoft’s change modifies the system default so that when an account does not explicitly declare supported enctypes, the KDC will use AES‑SHA1 enctypes only. If an account needs RC4, administrators must explicitly set the msDS flag to allow RC4 — making RC4 an opt‑in exception rather than the default.

New audit and telemetry events​

To make the transition manageable at enterprise scale, Microsoft enhanced logging:

  • Kerberos Security event entries (for example, Event IDs 4768 for TGT requests and 4769 for service tickets) will include msDS‑SupportedEncryptionTypes, Available Keys (what key material is present for the account), Advertised Etypes (what the client offered), and Ticket/Session Encryption Type (what was used). This makes it possible to pinpoint whether a compatibility problem is client‑side, account‑side, or a KDC default.
  • The System event log will also surface KDCSVC events (IDs 201–209 and similar) to flag issues and record audit‑only warnings during the initialcan be used to build SIEM detections and automated remediation playbooks.

Registry controls introduced for staged rollout​

Microsoft’s updates introduce a temporary registry control, RC4DefaultDisablementPhase, that admins can set to proactively enable the behavior before the global default flips. This value will be deprecated and removed when Audit mode is removed in July 2026, so it’s a transitional tool rather than a permanent escape hatch. Administrators with explicit DDSET customizations are intentionally not broken — Microsoft will log warning audit events instead of silently changing explicitly configured vasoft.com](])

Practical impact on networks and devices​

Immediate operational effects​

  • Systems and appliances that still only support RC4 will fail to negotiate AES‑only tickets once Enforcement mode is activated and no exception exists.
  • Domain controllers that have a non‑default DDSET value remain functionally unchanged, but the updates will log KDCSVC audit events if the configuration is considered insecure — giving admins a visible path to remediation.
  • For many modern Windows clients and servers there will be no change in day‑to‑day operation because they already prefer AES. The burden falls on legacy appliances, embedded devices, and third‑party products that cannot be updated.

Compatibility risks and common breakage scenarios​

  • Older network devices, NAS appliances, application servers, and home‑grown services that were never updated to support AES Kerberos enctypes may stop authenticating.
  • Services using accounts that were created a long time ago and never had their password reset may lack AES key material in AD (Available Keys will reveal this). In such cases a password reset for the service account will generate AES key entries and resolve compatibility without re‑enabling RC4.

What administrators must do now — step‑by‑step migration plan​

  1. Update domain controllers: deploy Windows updates released on or after January 13, 2026 to all domain controllers first (these updates add the audit telemetry and registry controls you’ll need).
  2. Enable and collect telemetry: configure enhanced Kerberos auditing and forward relevant events (Security and System) to your SIEM or Windows Event Collector. Look specifically for the new fields in Event IDs 4768/4769 and KDCSVC audit entries.
  3. Inventory accounts with SPNs: run Microsoft’s PowerShell helpers (List‑AccountKeys.ps1) to enumerate accounts that lack AES keys and to find accounts advertising only RC4. Use Get‑KerbEncryptionUsage.ps1 to summarize recent Kerberos use and detect current RC4 session usage.
  4. Remediate by root cause:
    • If an account lacks AES keys: perform a controlled password reset to generate AES key material and then confirm with List‑AccountKeys.ps1.
    • If a client advertises only RC4: patch or replace the client, or configure it (if possible) to enable AES enctypes.
    • For third‑party appliances that cannot be updated: engage vendors for fixes, and — if unavailable — plan for isolation/segmentation or proxying.
  5. Pilot enabling the new behavior: use a subset of non‑production DCs and the RC4DefaultDisablementPhase registry switch to test enabling AES‑only behavior in a controlled environment (remember this control will be removed in July 2026).
  6. Move from Audit to Enforcement on a per‑domain basis only after you have validated that no critical services break. Microsoft recommends enabling Enforcement mode as soon as warning and blocking events are no longer observed in your environment.
  7. Document and time‑box any RC4 exceptions: if you must re‑enable RC4 for a device, do so at the account level via msDS‑SupportedEncryptionTypes, record the risk, and set a remediation deadline. Exceptions must be temporary and governed.
  8. Update detection & incident response: add SIEM detections for RC4 occurrences, unusual TGS/AS‑REQ patterns, and spikes in KDCSVC warnings; incorporate these into tabletop exercises and runbooks.

Tools Microsoft provided (and how to use them)​

  • List‑AccountKeys.ps1 — enumerates AD accounts and shows which key material (RC4, AES128, AES256) is present; use it to find accounts that need password resets.
  • Get‑KerbEncryptionUsage.ps1 — scans Kerberos activity to find recent RC4 session usage across DCs; useful for trending and triage.
  • Windows Admin Center / Group Policy — GUI and policy mechanisms can set allowed Kerberos enctypes for targeted testing and rollout.
  • Event log fields & KDCSVC events — feed them to SIEM for automated detection and reporting.

Security analysis: strengths, limitations, and residual risks​

Notable strengths​

  • Safer defaults: Moving to AES‑SHA1 as the KDC default reduces the population‑level exposure to offline attacks like Kerberoasting by raising the computational cost for attackers. This is a systemic improvement that aligns Kerberos defaults with modern cryptographic practice.
  • Actionable telemetry: The enhanced event fields make previously opaque Kerberos negotiation decisions visible, enabling more precise remediation than generic audit logs allowed. This is a major operational win for large and heterogeneous environments.
  • Phased rollout and tooling: Microsoft’s staged approach with audit mode and PowerShell helpers gives organizations a pragmatic migration path rather than a sudden breaking change.

Limitations and risks​

  • Compatibility burden on organizations: The real operational burden falls on enterprises with long tails of legacy devices, embedded systems, and third‑party appliances that may be unsupported or difficult to patch. Planning, vendor coordination, and possible network segmentation will be required.
  • Risk of misconfiguration or incomplete coverage: If a domain controller (or a subset of DCs) is not updated, or if admins disable audit/events prematurely, you could end up with blind spots and produce authentication outages when enforcement flips are applied. The enforcement timeline creates an operational deadline that many orgs will struggle to meet without automation.
  • Residual brute‑force risk: AES alone is not a silver bullet — weak passwords on service accounts remain crackable given enough resources. Microsoft and security guidance emphasize that AES must be paired with strong password hygiene, rotation, and least‑privilege principles.

Risk‑mitigation recommendations (practical and prioritized)​

  • Prioritize inventory of accounts with SPNs, and treat long‑unused service accounts as high risk.
  • Build automation to detect and remediate missing AES key material (controlled password reset + verification).
  • Engage third‑party vendors early; require AES Kerberos support in vendor SLAs and procurement documents.
  • Use defensive segmentation and application proxies for legacy appliances that cannot be updated in time.
  • Add SIEM rules for KDCSVC and extended Kerberos event fields and configure alerting thresholds tied to business impact.
  • Maintain a documented exceptions register for any RC4 re‑enables and enforce short remediation windows.

Timeline and decision points (quick reference)​

  1. January 13, 2026 — Install updates: adds audit telemetry and RC4DefaultDisablementPhase for controlled early activation.
  2. April 2026 — Microsoft changes the default DDSET to AES‑SHA1 (0x18) for accounts without explicit msDS values; Enforcement mode enabled broadly starting that month. Test thoroughly before this date.
  3. July 2026 — Audit mode and RC4DefaultDisablementPhase registry control removed; Enforcement mode becomes the only option in updated builds. Any lingering RC4 reliance must be addressed by then.

What to watch for and common gotchas​

  • Don’t assume absence of RC4 in your environment; older appliances and virtualization host integrations often hide Kerberos dependencies. Use the provided scripts and audit fields to prove RC4 usage (or lack of it).
  • If your environment uses non‑Windows KDCs or third‑party domain controllers, verify interoperability behavior separately; Microsoft’s change affects Windows KDC issuance decisions.
  • Beware of partial patching: patching only some DCs or only some clients can create asymmetric behavior, leading to hard‑to‑diagnose authentication failures. Plan for synchronized update windows.

Critical perspective: balancing improved defaults with operational reality​

Microsoft’s decision to flip the KDC default to AES‑SHA1 and demote RC4 to an explicit opt‑in is a defensible, long‑overdue security move that modernizes Windows authentication defaults and reduces systemic risk from Kerberoasting‑style attacks. The approach is pragmatic: telemetry, scripts, and a phased roll make the change operationally feasible for large organizations. These are meaningful strengths and reflect lessons learned from years of incident response and public scrutiny. However, the change is only as effective as the execution in customer environments. Enterprises with extensive legacy stacks face real timelines and coordination costs. The phased schedule creates operational deadlines that must be treated like regulatory compliance dates: missed milestones will translate into either short‑term risk (if RC4 is re‑enabled globally) or potential outages (if enforcement happens before remediation). Admin teams must therefore prioritize discovery, automation, and vendor engagement over ad‑hoc firefighting. Finally, while Microsoft’s technical fix addresses the cryptographic vector, human and process problems remain — weak service account passwords, unmanaged service accounts, and poor exception governance will blunt the hardening unless organizations pair technical remediation with identity governance and inventory discipline.

Action checklist for the next 30–90 days​

  • Install January 13, 2026 updates on all domain controllers.
  • Enable and collect the new Kerberos telemetry into your SIEM.
  • Run List‑AccountKeys.ps1 and Get‑KerbEncryptionUsage.ps1; create a prioritized remediation backlog.
  • Reset passwords for service accounts lacking AES keys in a controlled manner and document changes.
  • Engage vendors of appliances that cannot be updated — require AES Kerberos support or plan segmentation.
  • Pilot RC4DefaultDisablementPhase in a test domain and move to Enforcement only after no audit warnings appear.
  • Time‑box and govern any RC4 exceptions — record risk, compensating controls, and remediation deadlines.

Microsoft’s staged Kerberos hardening is a major operational event for Windows administrators and security teams: it strengthens defaults where cryptographic practice and incident history demanded change, but it also hands responsibility to each organization to inventory, remediate, and govern legacy dependencies before enforcement arrives. Use the telemetry and scripts Microsoft shipped, treat the April/July 2026 milestones as firm operational deadlines, and prioritize short remediation cycles for service accounts and unsupported appliances — otherwise the long tail of legacy compatibility will become an availability problem as well as a security one.

 

Click to expand...
You must log in or register to reply here.