Microsoft’s long-standing accommodation for the RC4 cipher in Windows authentication is finally getting a firm end date: by mid‑2026 domain controllers (KDCs) running Windows Server 2008 and later will default to AES‑SHA1 session keys for Kerberos and RC4 will be disabled by default, leaving RC4 only as an explicit, opt‑in compatibility exception.
For decades Active Directory’s Kerberos implementation allowed multiple Kerberos encryption types (enctypes). RC4‑HMAC (commonly shortened to RC4 in Windows documentation) persisted as a widely interoperable fallback from the earliest Windows Server releases, despite serious cryptographic weaknesses being public knowledge since the 1990s. RFC 7465 formalized the Internet community’s repudiation of RC4 in TLS in 2015, and the industry has steadily moved away from RC4 in protocol stacks — but identity systems and long‑lived appliances have lagged. Microsoft’s recent public guidance codifies a long‑running engineering effort: the Kerberos KDC on Windows Server 2008+ will be configured to issue AES‑SHA1‑based session keys by default, and RC4 will no longer be the default path for ticket encryption. The change is explicitly timed as a default flip by mid‑2026, giving organizations a runway to find and fix RC4 dependencies.
That said, the move does not magically erase RC4 from the internet. Legacy devices, vendor slowdowns, and archived key material in Active Directory mean that RC4‑based authentication and the associated risks will persist in many environments for months or years unless organizations invest in discovery, remediation, and vendor coordination. The mid‑2026 default flip is a forcing function: it makes remediation an operational necessity and transforms optional best practice into urgent project work for IT teams. Administrators should start now: run the scripts, inventory your estate, prioritize SPNs and privileged accounts, and coordinate with vendors for fixes or isolated workarounds. Treat any re‑enabled RC4 setting as a documented, temporary exception with a strict sunset. The tools Microsoft published make the task feasible — the remaining challenge is the organizational discipline to carry it out before the default flips to AES‑only.
Microsoft’s move closes a long‑open compatibility versus security tradeoff in Windows authentication. The technical fix — defaulting to AES‑SHA1 in Kerberos and equipping administrators with precise telemetry and scripts — is sound. The operational challenge for organizations is real but solvable if addressed methodically and soon.
Source: TechSpot Microsoft will soon deprecate the insecure RC4 encryption algorithm
Background
For decades Active Directory’s Kerberos implementation allowed multiple Kerberos encryption types (enctypes). RC4‑HMAC (commonly shortened to RC4 in Windows documentation) persisted as a widely interoperable fallback from the earliest Windows Server releases, despite serious cryptographic weaknesses being public knowledge since the 1990s. RFC 7465 formalized the Internet community’s repudiation of RC4 in TLS in 2015, and the industry has steadily moved away from RC4 in protocol stacks — but identity systems and long‑lived appliances have lagged. Microsoft’s recent public guidance codifies a long‑running engineering effort: the Kerberos KDC on Windows Server 2008+ will be configured to issue AES‑SHA1‑based session keys by default, and RC4 will no longer be the default path for ticket encryption. The change is explicitly timed as a default flip by mid‑2026, giving organizations a runway to find and fix RC4 dependencies. Why RC4 had to go: technical context
RC4’s cryptographic problems
RC4 is a stream cipher whose keystream exhibits statistical biases that became exploitable in practice. Over time researchers demonstrated attacks that reduce the cost and complexity of recovering plaintext or deriving secrets from RC4 streams. Those weaknesses, combined with simple key‑derivation methods historically used for NTLM/RC4 in Windows, make RC4‑protected Kerberos tickets much easier to crack offline than modern AES‑protected tickets. RFC 7465 captures the broader consensus that RC4 is not acceptable for TLS; the same cryptanalytic realities undercut its use in other security‑critical contexts.Kerberoasting and the practical attack surface
The operational risk Microsoft highlights is Kerberoasting: any domain account can request a service ticket (TGS) for a service principal name (SPN), extract the encrypted portion, and then perform offline brute‑force attacks against the ticket. When the ticket uses RC4/NTLM‑derived keys, the cost to crack passwords is dramatically lower than when AES‑based enctypes are used. That makes service accounts with weak passwords especially attractive targets and transforms a common, legitimate Kerberos flow into an offline credential‑exfiltration vector.What Microsoft is changing (technical specifics)
The default flip
Microsoft will update domain controller defaults so the KDC issues AES‑SHA1 session keys by default; RC4 will be disabled by default and only allowed when a domain administrator explicitly configures accounts or the KDC to permit it. This applies to domain controllers running Windows Server 2008 and later. Administrators may still re‑enable RC4 for compatibility, but that will be an opt‑in exception rather than the norm.New visibility in Kerberos auditing
To make remediation practical at scale, Microsoft added precise telemetry to Kerberos events (Windows Security Event IDs such as 4768 and 4769). New fields include:- msds‑SupportedEncryptionTypes — what enctypes the client or service advertises.
- Available Keys — the actual key material present for an account in AD (e.g., whether AES keys exist).
- Session Encryption Type and Ticket Encryption Type — which enctype was used for a particular ticket/session.
New tooling: PowerShell scripts and guidance
Microsoft published PowerShell helpers (notably List‑AccountKeys.ps1 and Get‑KerbEncryptionUsage.ps1) to automate log parsing and inventory, plus Windows Admin Center and Group Policy guidance for configuring allowed enctypes. These scripts extract the new event fields and produce targeted lists of accounts, clients, and devices that must be remediated. Microsoft also documented remediation workflows (e.g., password reset to provision AES keys for accounts that only have RC4).Cross‑checks and independent verification
This move is documented in Microsoft’s Windows Server blog post authored by a Microsoft principal program manager and reinforced by Microsoft Learn documentation describing the detection/remediation steps and the same mid‑2026 timeline. Independent reporting from security press outlets confirms the announcement and the timeline, and also captures the political context and industry reaction. RFC 7465 and IETF materials confirm why RC4 was prohibited for TLS years ago, establishing consistent technical rationale for deprecating RC4 across protocols. Note on verification: the schedule expressed in Microsoft’s documentation and learn pages is the authoritative public timeline. Administrators should verify release notes and Microsoft updates or advisories close to the enforcement date in case rollout details change.Policy, politics, and the public context
The announcement arrives after public scrutiny of real‑world incidents where identity abuse played a central role in large intrusions. Congressional attention — including public criticism from Senator Ron Wyden — highlighted RC4’s role in at least one high‑impact healthcare intrusion, and lawmakers asked whether Microsoft’s defaults contributed to the attack surface. Reporting from major outlets summarized the political pressure and Microsoft’s public responses. Microsoft pushed back on some characterizations while accelerating its timeline for making AES the default. This combination of high‑severity incidents and regulatory scrutiny likely accelerated Microsoft’s default flip and the emphasis on operational telemetry and tooling.Practical impact: who will break, and how to prepare
The compatibility problem
Many enterprise environments include legacy appliances, embedded devices, scanners, multi‑function printers, OT systems, or third‑party applications that either:- advertise only RC4 in Kerberos negotiations, or
- rely on accounts that were never rekeyed to generate AES keys.
Inventory first, change second
Microsoft’s guidance and the community playbook converge on a single principle: discover before you change. Practical steps:- Run Microsoft’s Get‑KerbEncryptionUsage.ps1 and List‑AccountKeys.ps1 to enumerate recent Kerberos sessions and available keys. Aggregate results in a central SIEM.
- Prioritize remediation by risk: service accounts with SPNs and privileged service accounts come first.
- For accounts missing AES keys, perform controlled password resets (or rekey operations) in test OUs; password resets cause AD to generate AES128/256 key material. Validate authentication flows for each service.
- For devices that cannot be upgraded, consider network segmentation, authentication proxies, or vendor‑provided gateways while pushing for firmware/driver fixes.
Short checklist for administrators
- Run the supplied PowerShell scripts and export results to your SIEM.
- Identify all service accounts with SPNs; enforce strong, random passwords or migrate to gMSAs/gMSAs where possible.
- Reset passwords for accounts that lack AES keys so AD creates AES key material. Test before mass deployment.
- Run pilot GPOs that restrict allowed Kerberos enctypes in non‑production OUs (use the “Network security: Configure encryption types allowed for Kerberos” policy).
- Coordinate with vendors for firmware/driver updates or plan isolation strategies for devices that cannot be fixed.
Technical how‑to (concise, operational)
Detect RC4 usage quickly
- Use Get‑KerbEncryptionUsage.ps1 with filters (e.g., -Encryption RC4) to find recent sessions that used RC4.
- Use List‑AccountKeys.ps1 to read the Available Keys field from events and list accounts that only have RC4 key material.
- Audit Security Event log entries 4768 and 4769 for the new fields and forward relevant events to SIEM.
Remediate common cases
- Accounts with only RC4 keys: reset the account password (in a controlled test first); that will provision AES128/256 keys.
- Clients advertising only RC4: update the client OS or application; if impossible, isolate the device or proxy authentication.
- Third‑party application servers that return RC4: request vendor updates or reconfigure the application to use AES enctypes where possible.
Strengths of Microsoft’s approach
- Default hardening: Changing vendor defaults is high‑leverage; many organizations never change defaults, so moving the safe choice to the default reduces population risk immediately.
- Actionable telemetry: New Kerberos event fields make discovery and remediation operationally tractable instead of relying on guessing or ad‑hoc scanning.
- Tools-first rollout: Shipping PowerShell scripts and administrative guidance at the same time as the policy change reduces the chance that the default flip becomes a surprise outage.
Risks, tradeoffs, and open questions
- Vendor coordination burden: Large enterprises rely on many third‑party devices and embedded systems. Achieving firmware and driver updates across a heterogeneous vendor landscape is a heavy operational burden and will likely be the main blocker for many organizations.
- Residual artifacts: Active Directory will continue to contain legacy RC4/NTLM‑derived keys until accounts are rekeyed; the presence of RC4 keys alone doesn’t mean RC4 is being actively used, but it represents residual attack surface if misconfigurations or re‑enabling of RC4 occur.
- Exception management risk: Allowing administrators to re‑enable RC4 introduces governance risk — exceptions must be logged, time‑boxed, and strictly monitored or they will become permanent technical debt.
- Timeline fragility: Microsoft’s public timeline is mid‑2026 for the default flip; while that is the published target, organizations should verify the specific rollout and release notes for their Windows Server servicing channel and patch levels as the date approaches. Treat the published date as the planning deadline, not the fail‑safe.
Recommended migration plan — a pragmatic timeline
- Inventory (0–2 months)
- Run Microsoft’s scripts and collect Kerberos event data into SIEM; identify RC4 session events and accounts missing AES keys.
- Prioritize and pilot (2–6 months)
- Target high‑risk service accounts (SPNs) and domain‑joined servers. Reset test account passwords to provision AES keys; pilot GPOs in non‑prod OUs enforcing AES‑only.
- Vendor coordination and isolation (6–12 months)
- Request vendor updates, plan segmentation for non‑fixable devices, and implement proxies or gateways where feasible.
- Organization‑wide rollout and enforcement (12+ months, before mid‑2026)
- Gradually tighten Group Policy to disallow RC4, monitor authentication failures closely, and apply remediation playbooks for any business‑critical breakage.
- Exception management and closure (ongoing)
- Log every RC4 exception with an owner, a sunset date, and a remediation plan; treat re‑enabled RC4 as high‑risk technical debt.
Final assessment
Microsoft’s decision to flip Kerberos defaults away from RC4 and to back that change with precise auditing fields and remediation tooling is a necessary and pragmatic step for improving identity security at scale. Default changes are powerful: they raise the bar across countless deployments that will never otherwise be hardened. The company’s dual focus on visibility (new event fields) and action (PowerShell scripts, GPO guidance, Windows Admin Center support) gives administrators the practical tools they need to migrate.That said, the move does not magically erase RC4 from the internet. Legacy devices, vendor slowdowns, and archived key material in Active Directory mean that RC4‑based authentication and the associated risks will persist in many environments for months or years unless organizations invest in discovery, remediation, and vendor coordination. The mid‑2026 default flip is a forcing function: it makes remediation an operational necessity and transforms optional best practice into urgent project work for IT teams. Administrators should start now: run the scripts, inventory your estate, prioritize SPNs and privileged accounts, and coordinate with vendors for fixes or isolated workarounds. Treat any re‑enabled RC4 setting as a documented, temporary exception with a strict sunset. The tools Microsoft published make the task feasible — the remaining challenge is the organizational discipline to carry it out before the default flips to AES‑only.
Microsoft’s move closes a long‑open compatibility versus security tradeoff in Windows authentication. The technical fix — defaulting to AES‑SHA1 in Kerberos and equipping administrators with precise telemetry and scripts — is sound. The operational challenge for organizations is real but solvable if addressed methodically and soon.
Source: TechSpot Microsoft will soon deprecate the insecure RC4 encryption algorithm
