The January 2026 Windows security update begins a staged, vendor-driven hardening of Kerberos by changing default Kerberos encryption behavior on domain controllers and introducing audit and enforcement mechanisms that phase out RC4-derived service tickets; at the same time, Microsoft and OEM partners are rolling out replacement Secure Boot certificates because the 2011-era UEFI/KEK certificates begin expiring in June 2026 — together these two maintenance windows require immediate planning from Windows administrators to avoid authentication outages and boot-security disruptions.
Microsoft released Windows updates starting January 13, 2026, that introduce protections tied to a Kerberos information-disclosure issue tracked as CVE-2026-20833. The update does two things at once: it delivers telemetry and audit events so administrators can discover where weak Kerberos encryption is still in use, and it implements a staged default change that will make domain controllers prefer AES-SHA1 Kerberos enctypes and stop issuing RC4-encrypted service tickets unless explicitly allowed.
These updates are being rolled out in phases:
This article pulls these two operational items together, explains the technical changes and timelines, details the detection and remediation tools Microsoft supplies, assesses the risks and trade-offs, and provides a practical migration plan for enterprise IT and security teams.
Kerberoasting allows any valid domain user to request a service ticket for an SPN, extract the encrypted blob, and perform offline brute force to recover the service account password. When the ticket uses RC4/NTLM-derived keys, the computational cost to recover weak passwords is far lower than with AES. By changing KDC defaults to prefer AES-SHA1 enctypes, Microsoft raises the cost for attackers and reduces the population-level exposure to offline attacks.
For defenders, the hardening dramatically reduces the ease and reward of Kerberoasting-style offline attacks. For operations teams, this is an urgent inventory-and-remediation project that must be executed with discipline: discover, prioritize, test, remediate, and govern exceptions. The work is not purely technical — it is an organizational program that spans desktop, server, firmware, vendor management, and incident response.
The Secure Boot certificate rollover adds a parallel, firmware-level deadline. Missing that update is not just an availability problem; it degrades the platform’s ability to accept and install boot-time security updates, which is a clear risk for organizations that depend on platform-level protections against low-level threats.
Both changes share a common theme: security-by-default requires active operational work to avoid compatibility problems. The correct posture is to treat the vendor timelines (January–April–July 2026 for Kerberos phases and June–October 2026 for Secure Boot certificate expirations) as non-negotiable planning deadlines. Use the telemetry and vendor-supplied tools to turn what would be a disruptive enforcement into a measured modernization project that reduces real-world risk.
Caveat: Microsoft’s published dates and deployment mechanics are the authoritative source for exact rollout timing and registration/registry controls; organizations should confirm release notes, KB numbers, and OEM advisories before making irreversible policy changes.
The January 2026 update is both an operational challenge and a rare opportunity: organizations that take immediate, measured action will end 2026 with measurably stronger identity and boot security, while those that delay will face rolling enforcement and the risk of disruptive outages. Start with the telemetry, prioritize high-risk service accounts, coordinate with vendors, and treat any remaining RC4 allowances as strictly temporary exceptions.
Source: Microsoft - Message Center How to manage Kerberos KDC usage of RC4 for service account ticket issuance changes related to CVE-2026-20833 - Microsoft Support
Background / Overview
Microsoft released Windows updates starting January 13, 2026, that introduce protections tied to a Kerberos information-disclosure issue tracked as CVE-2026-20833. The update does two things at once: it delivers telemetry and audit events so administrators can discover where weak Kerberos encryption is still in use, and it implements a staged default change that will make domain controllers prefer AES-SHA1 Kerberos enctypes and stop issuing RC4-encrypted service tickets unless explicitly allowed.These updates are being rolled out in phases:
- January 13, 2026 — Initial deployment: updates begin shipping and provide audit telemetry and a registry control (RC4DefaultDisablementPhase) so organizations can opt into the change early where safe.
- April 2026 — Second deployment: the KDC default for accounts without explicit msDS-SupportedEncryptionTypes will be changed to AES-SHA1 only (DefaultDomainSupportedEncTypes becomes 0x18).
- July 2026 — Enforcement: audit-only modes and certain registry controls are removed; Enforcement mode will be enabled broadly and Audit mode will be deprecated.
This article pulls these two operational items together, explains the technical changes and timelines, details the detection and remediation tools Microsoft supplies, assesses the risks and trade-offs, and provides a practical migration plan for enterprise IT and security teams.
Why Microsoft is hardening Kerberos and retiring RC4 as a default
The problem in plain language
Kerberos ticket encryption determines how hard it is for an attacker to perform offline password cracking of service account credentials extracted from service tickets. Historically Windows supported several Kerberos encryption types (enctypes); RC4-HMAC (commonly called RC4) persisted as a widely compatible fallback. RC4-based Kerberos tickets — combined with legacy NTLM-derived key material — make offline attacks such as Kerberoasting materially cheaper than when AES-based enctypes protect tickets.Kerberoasting allows any valid domain user to request a service ticket for an SPN, extract the encrypted blob, and perform offline brute force to recover the service account password. When the ticket uses RC4/NTLM-derived keys, the computational cost to recover weak passwords is far lower than with AES. By changing KDC defaults to prefer AES-SHA1 enctypes, Microsoft raises the cost for attackers and reduces the population-level exposure to offline attacks.
The security rationale and public context
The move aligns Kerberos defaults with modern cryptographic expectations. RC4 has been deprecated for many protocols for over a decade; the decision to flip KDC defaults is driven by recurring incident patterns and long-standing hardening recommendations from the security community. Microsoft frames the change as safer defaults rather than a universal blanket removal: RC4 remains available as an opt-in for compatibility, but only where a domain administrator explicitly configures accounts or KDCs to accept it.What changed in the January 2026 update (technical specifics)
Key behavioral changes
- The update ships enhanced Kerberos telemetry in the Security and System event logs to surface encryption negotiation details for each Kerberos request and ticket.
- A new default for KDC behavior will be introduced in stages so domain controllers issue AES-SHA1 (AES128/AES256 CTS-HMAC-SHA1-96 family) session keys for accounts that do not have an explicit msDS-SupportedEncryptionTypes value defined.
- The registry value DefaultDomainSupportedEncTypes (DDSET) will have its default changed; in April 2026 this default will be set to AES-SHA1 only (0x18).
- If a DC already has a customized DefaultDomainSupportedEncTypes registry value, existing behavior remains unchanged — but the new updates may log an audit event (KDCSVC Event ID 205) if the configured value is considered insecure.
- Administrators can proactively set RC4DefaultDisablementPhase on domain controllers to phase in the change earlier (value 2 to enable proactively).
- Microsoft recommends moving from Audit mode to Enforcement mode (which blocks non-compliant devices) as soon as validation is complete; Enforcement will be enabled broadly starting April 2026 and Audit mode will be removed in July 2026.
New telemetry and visibility (what to collect)
The updates enrich existing Kerberos events (notably Event IDs 4768 and 4769) with fields that make it possible to identify why RC4 remains in play:- msDS-SupportedEncryptionTypes — what the client or service advertises.
- Available Keys / Account Keys — what key material (AES128/AES256/RC4) exists for an account in AD.
- Advertised Etypes — enctypes the client offered during the AS-REQ/TGS-REQ.
- Ticket Encryption Type / Session Encryption Type — the enctype actually used for a specific ticket/session.
- List-AccountKeys.ps1 — enumerates accounts and shows which key material they have available.
- Get-KerbEncryptionUsage.ps1 — summarizes recent Kerberos activity and filters for RC4 session usage.
Secure Boot certificate expiration: what administrators must know
The certificates and the problem
Multiple Microsoft Secure Boot certificates issued in 2011 (KEK CA 2011, UEFI CA 2011, and Windows Production PCA 2011 variants) start to expire in June–October 2026. When those certificates expire:- Devices may stop receiving Secure Boot-related security updates for boot components.
- Devices may stop trusting third-party boot loaders or option ROMs signed under the old CAs.
- Firmware/UEFI-level trusts in platform stores (KEK/DB) must be updated to include new 2023 CA certificates.
The operational risks
- Systems that miss the certificate updates may lose the ability to install Secure Boot security updates after their local certs expire.
- Failure to update certificate stores could also prevent boot-time trust of new third-party signed components or cause compliance failures.
- For some commercial OEM platforms, a firmware/BIOS update may also be required to fully adopt the new KEK/DB entries.
Practical detection and remediation plan (Kerberos & Secure Boot)
Immediate actions (Day 0–14)
- Install January 13, 2026+ Windows updates on all domain controllers to obtain audit telemetry and the registry controls. This is the essential first step to get the extra visibility needed.
- Enable centralized collection of Kerberos-related events (Event IDs 4768 and 4769) from all domain controllers to your SIEM (Event Forwarding, Microsoft Sentinel, or a third-party SIEM).
- Run the supplied PowerShell scripts (Get-KerbEncryptionUsage.ps1 and List-AccountKeys.ps1) in a test OU or on a test DC first, then at scale to produce an inventory of:
- Service accounts with SPNs that only have RC4 key material.
- Clients advertising only RC4.
- Hosts or applications returning RC4-protected tickets.
- Monitor for KDCSVC Event ID 205 in the System event log; this indicates existing DefaultDomainSupportedEncTypes configurations the update considers insecure.
Short-term (Weeks 2–8)
- Prioritize accounts with SPNs and reset their passwords in a controlled way to provision AES key material; validate with List-AccountKeys.ps1 that AES128/256 keys now exist.
- Patch or update client OSs and third-party appliances that advertise only RC4; where vendor updates are unavailable, plan compensating controls (network isolation, authentication proxies).
- Establish an exception governance process: any explicit re-enablement of RC4 must be documented, time-boxed, and approved with clear compensating controls.
Medium-term (Months 2–6)
- Build a pilot OU and apply stricter Kerberos encryption policies to a subset of DCs and users; perform exhaustive authentication regression testing across business-critical applications.
- Use SIEM alerts to detect any new RC4 session occurrences and triage quickly.
- Engage vendors of legacy devices and embedded systems for firmware patches; where no vendor fix is available, plan for isolation and replacement schedules.
Deadline-driven actions (April–July 2026)
- By April 2026 — prepare for Enforcement mode being enabled broadly; verify that your environment can operate correctly with AES-only negotiation for accounts that do not explicitly request RC4.
- By July 2026 — Audit mode will be removed and Enforcement mode will be the baseline; ensure exceptions are removed or justified with concrete remediation timelines.
Secure Boot-specific actions
- Identify platforms that require BIOS/UEFI updates or Windows updates to receive the new 2023 certificates.
- Prioritize systems that are Secure-Core or production-critical; coordinate OEM firmware tests in staging channels before broad rollout.
- Verify Secure Boot certificate status in firmware or via OS checks (e.g., platform telemetry or secure-boot-related PowerShell cmdlets).
- Confirm that any anti-cheat, virtualization, or low-level security tooling that relies on Secure Boot will continue to function after the certificate rollover; coordinate with vendors where necessary.
Risk assessment and trade-offs
Strengths of Microsoft’s approach
- Safer defaults at scale: Making AES the default significantly increases the computational cost of offline Kerberos attacks and reduces population-level exposure.
- Actionable telemetry: New event fields and provided PowerShell scripts make discovery realistic and operationally tractable.
- Staged rollout: A phased deployment with an extended runway reduces the risk of surprise outages and gives administrators time to remediate.
Operational risks and downsides
- Compatibility breakage: Legacy appliances, embedded devices, and older OSes may fail to authenticate if they cannot support AES enctypes. These failures can be silent and difficult to diagnose.
- Vendor coordination burden: Many vendors of third-party appliances must provide firmware or software updates — a supply-chain and coordination challenge that will be the primary blocker for many organizations.
- Exception creep and governance: Allowing administrators to re-enable RC4 for compatibility is necessary but introduces long-term governance risks if exceptions are not strictly time-boxed and monitored.
- Residual credential artifacts: Active Directory will continue to hold legacy RC4/NTLM-derived credentials until accounts are rekeyed; the presence of those entries can represent residual attack surface if exceptions or fallbacks remain.
What can go wrong (examples)
- A network printer or imaging appliance that only supports RC4 suddenly fails to authenticate after a staged policy or DC flip, causing business disruption.
- A lack of centralized Kerberos logging means an organization cannot detect that a service continues to issue RC4 tickets until enforcement triggers failures.
- Failure to update device firmware for the Secure Boot CA rollover results in lost updates for boot components and reduced ability to remediate boot-time vulnerabilities.
Governance, monitoring, and validation — a practical runbook
- Centralize telemetry first: collect Event IDs 4768/4769 from all DCs and keep one long-term baseline run of the supplied scripts.
- Create a prioritized remediation queue based on:
- Presence of SPNs (service accounts) with RC4-only keys.
- Criticality of the service and business impact.
- Vendor patchability or ease of replacement.
- For each high-priority service account:
- Plan a maintenance window.
- Reset the account password (controlled), verify AES keys exist, test the service.
- Record the change, the test results, and rollback steps.
- For unsupported appliances:
- Open vendor cases immediately.
- If vendor updates are unavailable, isolate the device or proxy auth to a gateway that can negotiate AES on behalf of the device.
- Maintain an exceptions registry with owner, approval, sunset date, compensating controls, and verification evidence.
- Before moving to Enforcement mode:
- Execute a full production-day pilot with the tighter policy.
- Confirm failover and rollback procedures.
- Verify monitoring triggers for RC4 reappearance.
- After Enforcement goes live:
- Audit the exception registry and close expired exceptions.
- Continue monitoring and maintain the inventory as part of standard change control.
Recommendations and checklist for IT teams (summary)
- Install Windows updates released on or after January 13, 2026, to get Kerberos audit telemetry and the initial tooling.
- Forward Event IDs 4768 and 4769 from all DCs to your SIEM and run List-AccountKeys.ps1 and Get-KerbEncryptionUsage.ps1.
- Reset passwords for service accounts missing AES keys (test and stage these password resets), and verify AES key material is present.
- Patch and update clients, third-party appliances, and firmware to support AES Kerberos enctypes where possible.
- Implement strict exception governance for any RC4 re-enablement and time-box every exception.
- Plan for Enforcement in April 2026 and the removal of Audit mode in July 2026; treat the published dates as firm planning deadlines but remain ready for last-minute vendor clarifications.
- For Secure Boot: inventory platforms, prioritize firmware and Windows updates that install new 2023 CA certificates, and coordinate with OEMs for devices that require BIOS updates.
Final analysis: why this matters and how to think about risk
Changing a long-running default in a pervasive protocol like Kerberos is always a difficult balance between improved safety and potential operational disruption. Microsoft’s approach is pragmatic: first, increase visibility and offer remediation tooling; second, provide a measured phased switch to safer defaults; third, enforce the hardened state after giving administrators runway.For defenders, the hardening dramatically reduces the ease and reward of Kerberoasting-style offline attacks. For operations teams, this is an urgent inventory-and-remediation project that must be executed with discipline: discover, prioritize, test, remediate, and govern exceptions. The work is not purely technical — it is an organizational program that spans desktop, server, firmware, vendor management, and incident response.
The Secure Boot certificate rollover adds a parallel, firmware-level deadline. Missing that update is not just an availability problem; it degrades the platform’s ability to accept and install boot-time security updates, which is a clear risk for organizations that depend on platform-level protections against low-level threats.
Both changes share a common theme: security-by-default requires active operational work to avoid compatibility problems. The correct posture is to treat the vendor timelines (January–April–July 2026 for Kerberos phases and June–October 2026 for Secure Boot certificate expirations) as non-negotiable planning deadlines. Use the telemetry and vendor-supplied tools to turn what would be a disruptive enforcement into a measured modernization project that reduces real-world risk.
Caveat: Microsoft’s published dates and deployment mechanics are the authoritative source for exact rollout timing and registration/registry controls; organizations should confirm release notes, KB numbers, and OEM advisories before making irreversible policy changes.
The January 2026 update is both an operational challenge and a rare opportunity: organizations that take immediate, measured action will end 2026 with measurably stronger identity and boot security, while those that delay will face rolling enforcement and the risk of disruptive outages. Start with the telemetry, prioritize high-risk service accounts, coordinate with vendors, and treat any remaining RC4 allowances as strictly temporary exceptions.
Source: Microsoft - Message Center How to manage Kerberos KDC usage of RC4 for service account ticket issuance changes related to CVE-2026-20833 - Microsoft Support
