Microsoft’s decision to stop issuing RC4-based Kerberos tickets by default on domain controllers is both overdue and consequential: after more than two decades of using RC4‑HMAC as a compatibility fall‑back in Active Directory, Microsoft will flip Kerberos defaults so domain controllers running Windows Server 2008 and later issue AES‑SHA1 enctypes by default and
disable RC4 unless explicitly reenabled, with the change scheduled as the default flip by mid‑2026.
Background / Overview
RC4 (Rivest Cipher 4), a fast stream cipher designed in 1987, was once prized for simplicity and performance. It became ubiquitous across protocols and products during the 1990s and 2000s — embedded in WEP/WPA-era Wi‑Fi stacks, TLS/SSL, and in Windows’ own Kerberos implementation — because it offered broad interoperability at a time when strong, standardized alternatives were not yet universally deployed. Over the last 15 years, however, public cryptanalysis revealed persistent statistical biases and key‑schedule weaknesses in RC4 that make it unsuitable for modern security needs. RFC 7465 formalized the Internet community’s repudiation of RC4 for TLS back in 2015. Microsoft’s Active Directory shipped with Kerberos-based authentication that historically allowed multiple encryption types (enctypes). To preserve compatibility with legacy clients and third‑party appliances, Windows continued to accept and sometimes issue RC4‑HMAC (commonly shortened to “RC4”) Kerberos tickets even after AES enctypes were introduced in Windows Server 2008. That compatibility choice — aimed at avoiding service breakage — created a long tail of systems and accounts that could still negotiate RC4, increasing the population‑level risk for identity‑focused attacks.
Why RC4 had to go: the technical case
The cipher is broken in practice
RC4 is a stream cipher with known, exploitable keystream biases that researchers have steadily documented since the early 2000s (notably the Fluhrer–Mantin–Shamir work). Those weaknesses were eventually turned into real‑world exploits against TLS and other protocols; industry bodies moved to ban RC4 in sensitive uses (TLS) because the cryptanalytic risk is not merely theoretical but demonstrable. RFC 7465 requires TLS stacks to avoid negotiating RC4 cipher suites entirely.
Windows-specific amplification of risk
In the Windows Kerberos ecosystem, RC4’s practical weaknesses are amplified by how key material has historically been derived. Windows used NTLM/NT hash material as the long‑term key for RC4 in Kerberos, a compatibility decision dating back to the Windows 2000 era to ease migration from older NTLM‑only systems. That derivation lacks modern salting and iteration (PBKDF2‑style stretching) used in stronger schemes, making offline password recovery from captured RC4‑encrypted Kerberos tickets materially easier than with AES‑based Kerberos tickets. Multiple Active Directory and incident response posts have documented that the RC4 + NTLM key path reduces the computational cost of offline cracking compared with AES enctypes.
Kerberoasting: a practical, low‑privilege attack
Kerberoasting is the clearest operational example of RC4’s harm inside Windows domains. The attack sequence is straightforward and stealthy: any authenticated domain user can request a service ticket for a Service Principal Name (SPN). The Key Distribution Center (KDC) issues a service ticket encrypted with the target service account’s key. An adversary can capture that ticket and crack it offline to recover the service account password — provided the ticket uses a weak enctype. When tickets are encrypted under RC4/NTLM‑derived keys, offline cracking is far cheaper than with AES, making Kerberoasting a low‑effort, high‑reward technique for privilege escalation inside targets. Security vendors, incident responders, and official guidance have repeatedly flagged Kerberoasting as an actively exploited technique.
What Microsoft announced and when
Microsoft’s Windows Server team published guidance and automation to help administrators discover RC4 dependencies and prepare for the default flip. The company’s guidance makes three core points:
- Domain controllers (KDCs) on Windows Server 2008 and later will change their default behavior so AES‑SHA1 (AES128/AES256 CTS‑HMAC‑SHA1‑96) is used for session keys by default and RC4 will be disabled by default; RC4 remains available only through explicit admin opt‑in where absolutely necessary.
- Microsoft added richer Kerberos telemetry (new, processed fields in Security Event Log entries such as 4768 and 4769) and published PowerShell tools (for example, List‑AccountKeys.ps1 and Get‑KerbEncryptionUsage.ps1) to inventory accounts and tickets that still use RC4. These telemetry enhancements make it possible to answer whether remaining RC4 usage is a client problem (devices advertising only RC4), an account problem (accounts lacking AES keys), or a KDC/policy problem.
- Microsoft’s public schedule sets mid‑2026 (end of Q2 2026) as the planning target to flip the defaults so that RC4 is not issued by default on domain controllers; the company frames this as a deliberate, staged change to avoid abrupt breakage. Administrators are expected to use the runway to discover and remediate legacy dependencies.
These technical and operational details came after rising political and customer pressure following high‑impact incidents that invoked Kerberos abuse and legacy cryptography.
The incidents and the political pressure
The most widely publicized example cited by lawmakers and press was the May 2024 ransomware intrusion into a major U.S. healthcare operator that ultimately affected millions of patient records. Public reporting, congressional correspondence, and subsequent investigations described Kerberos abuse during the intrusion and identified RC4‑era Kerberos behavior as a facilitator for the adversary’s lateral movement and privilege escalation. Those events prompted sustained scrutiny from U.S. Senator Ron Wyden, who urged the Federal Trade Commission to investigate Microsoft for what he characterized as “gross cybersecurity negligence.” The political heat and industry reaction accelerated conversations inside Microsoft about turning the safety knob from guidance to a default change.
What administrators need to do now (practical remediation steps)
Microsoft published concrete discovery and remediation guidance; below is a prioritized operational checklist distilled from the vendor’s tools and community best practice:
- Inventory Kerberos usage and surface RC4 tickets
- Centralize Kerberos events (Event IDs 4768 / 4769) from all DCs into a SIEM or log store.
- Use the new fields Microsoft added (Ticket Encryption Type, Session Encryption Type, msDS‑SupportedEncryptionTypes, Available Keys) to filter for RC4 usage.
- Run Microsoft’s helper scripts
- Run Get‑KerbEncryptionUsage.ps1 to get a first‑pass summary of ticket enctypes and recent RC4 sessions.
- Run List‑AccountKeys.ps1 to identify accounts that lack AES keys (accounts with SPNs that only have RC4 key material will show up here).
- Triage and prioritize
- High priority: service accounts with SPNs, especially those attached to critical infrastructure or with wide privileges.
- Medium: third‑party appliances and embedded devices used in production.
- Low: isolated lab gear or devices nearing decommission.
- Remediate accounts
- For accounts lacking AES keys, perform controlled password resets to generate AES128/256 keys in AD. In some cases, two resets are needed for all key material to be created and recognized across services.
- Ensure msDS‑SupportedEncryptionTypes is set to include AES128 and/or AES256 for service accounts where appropriate.
- Engage vendors and update devices
- Identify and talk to third‑party hardware/software vendors whose devices cannot speak AES SHA1 Kerberos. Ask for firmware/driver updates or migration plans. Microsoft is collecting compatibility information from vendors (stillneedrc4@microsoft.com), but the onus is on customers to escalate vendor fixes.
- Harden account hygiene
- Enforce long, random passwords or managed service accounts (gMSAs) for service principals.
- Rotate service account passwords and avoid “password never expires” defaults for high‑value accounts.
- Add multi‑factor protections and least privilege where possible.
- Test before you flip
- Use a staged test domain or a subset of DCs to try the default flip and validate application behavior before broad rollout.
These are practical, actionable steps; they are the exact measures Microsoft suggests and the same playbook recommended by security vendors and incident responders.
Benefits and the security upside
- Reduced population‑level attack surface. Making AES the default dramatically raises the offline cost to crack service tickets, reducing the window of opportunity for Kerberoasting at scale. Microsoft’s default flip forces a safer baseline across millions of devices without requiring every admin to act proactively.
- Better observability. New telemetry fields in Kerberos events make RC4 usage auditable for the first time at scale, enabling security teams to track progress and measure remediation.
- Cleaner long‑term architecture. For organizations that have been carrying technical debt to preserve backward compatibility, the default flip is a vendor‑level push to modernize identity and authentication hygiene.
Risks, caveats and operational hazards
- Compatibility breakage remains a real possibility. The flip is staged to minimize surprises, but some legacy appliances, embedded systems, and vendor stacks still rely on RC4. If those systems cannot be updated or reconfigured, organizations face operational outages unless proper exceptions or compensating controls are implemented. Microsoft’s approach retains an escape hatch (explicit opt‑in), but that same escape hatch is a risk vector if misused.
- Admin burden and human error. Large enterprises with hundreds of thousands of accounts and many third‑party devices must carefully triage and update service accounts; mistakes during password resets, misapplied GPOs, or incomplete vendor coordination could cause outages.
- Opt‑in exceptions prolong risk. Because Microsoft will still allow RC4 when explicitly configured, organizations that do reenable RC4 for compatibility are accepting a deliberate increase in risk. Those exceptions must be tightly governed and audited.
- Not a silver bullet. Retiring RC4 raises the bar, but it does not eliminate Kerberoasting entirely — weak or static service passwords, poor segmentation, and lack of monitoring will still permit attackers to succeed. The flip must be part of a broader identity‑centric program.
Critical analysis: strengths, missed opportunities, and political implications
Microsoft’s technical decision is sound: default security matters. Studies and vendor advisories have long argued that changing defaults is the single most effective way to shift the security posture across a massive installed base, because
defaults drive behavior. Turning AES into the default KDC behavior will, if executed properly, reduce the number of domains issuing RC4 tickets by orders of magnitude.
However, the political and communications context highlights two shortcomings.
First, the change is reactive rather than proactive. The company’s long‑standing accommodation to legacy systems left a tractable but real attack vector in place for years. When real breaches occurred and lawmakers flagged the risk, Microsoft accelerated public steps toward safer defaults — but many security practitioners will point out that the deprecation should have happened earlier and more decisively.
Second, Microsoft’s decision to retain an explicit opt‑in for RC4, while operationally pragmatic, preserves the possibility for organizations (or vendors) to knowingly keep a high‑risk configuration alive. That’s both necessary for compatibility in a complex ecosystem and a policy gap that attackers can still exploit if organizations do not govern exceptions rigorously. Recent congressional inquiries and public letters — notably from Senator Wyden — made this political pain visible and helped focus vendor action. A final point on claims and numbers: public articles and social posts have used evocative comparisons (for example, that AES is “1,000 times harder” to crack than RC4). Those raw multiplicative claims are
not a useful technical metric without context: “harder” depends on attack model, password quality, key‑derivation steps, and compute resources. AES has well‑understood cryptographic strength and modern Kerberos AES enctypes use stronger key derivation and HMAC constructs than the historical RC4/NTLM path; that
does translate into orders‑of‑magnitude increases in brute‑force cost in practice, but engineers should avoid quoting arbitrary multiplicative factors unless they are explicitly benchmarked for a defined scenario. Treat blanket numeric claims with caution.
What success looks like — an operational yardstick
For this policy change to be judged a success, organizations and security teams should aim to demonstrate, before the mid‑2026 default flip:
- Centralized evidence that RC4 tickets are below a measurable threshold across their domain fleet (e.g., <0.1% of Kerberos tickets).
- All high‑risk service accounts with SPNs are updated to include AES key material (validated by List‑AccountKeys.ps1 output).
- Vendor‑facing inventories with remediation plans, roll‑out dates, and fallbacks for devices that cannot be updated.
- Policies enforcing rotation of service account credentials, least privilege for service accounts, and integration of Kerberos telemetry into SIEM/EDR playbooks.
If those checkpoints are met, the ecosystem will have converted a decades‑old compatibility decision into a measurable reduction in identity attack surface.
Final verdict
Microsoft’s decision to stop issuing RC4 Kerberos tickets by default on domain controllers addresses a long‑standing, concrete security weakness in Windows authentication. It is a long‑overdue, technically justified change that will materially increase the cost for attackers leveraging Kerberoasting and related ticket‑based attacks. The change is neither risk‑free nor immediate: administrators must move quickly to inventory, remediate, and test, and vendors must update devices that lack AES Kerberos support.
The move is an important lesson in modern secure defaults: compatibility compromises can persist for decades and quietly accumulate risk. Turning the default toward
safer cryptography is the right design choice; success depends on execution, vendor engagement, and the discipline of administrators to use the provided tools and telemetry to migrate aggressively — not to treat the mid‑2026 date as a vague suggestion.
Use the Microsoft guidance and the community remediation playbooks as your immediate roadmap: inventory Kerberos traffic, discover accounts with only RC4 key material, update service passwords to generate AES keys, coordinate with third‑party vendors, and integrate Kerberos telemetry into your detection pipelines. The mid‑2026 default flip gives time — but it is not a reason to delay the hard work of modernizing identity security.
Source: GIGAZINE
Why did Microsoft abolish the encryption method 'RC4' that it had supported by default for 26 years?