Microsoft Phases Out RC4 in Active Directory to AES by 2026

Microsoft’s decision to phase out the RC4 cipher from Active Directory authentication marks a decisive response to decades of risky backward compatibility — but it also forces a hard reckoning for enterprises that have long depended on legacy interoperability over cryptographic hygiene.

Background​

For nearly a quarter century, RC4 (Rivest Cipher 4) has lingered inside Windows authentication stacks as a compatibility fallback for Kerberos tickets, despite being widely known as cryptographically weak. RC4 first gained traction in the 1990s and was baked into Windows networking when Active Directory debuted with Windows Server 2000. Over time, stronger algorithms — notably AES — were added to Windows (AES support arrived in Windows Server 2008), but RC4 remained enabled by default to preserve legacy interoperability. Microsoft now says it will change domain controller defaults so the Kerberos Key Distribution Center (KDC) issues AES-based keys by default and disable RC4 by default in Active Directory environments by mid‑2026, moving administrators to AES‑SHA1 (AES-based session keys) unless RC4 is explicitly re-enabled. This is not a sudden reversal. Microsoft began deprecating RC4 in other contexts (browsers/TLS) earlier in the last decade, and in recent years the company added tooling and guidance to help customers detect and remediate RC4 usage in Kerberos. However, the timeline and the decision to make the change a default for domain controllers represent the most consequential step yet: a vendor-driven, large-scale forcing function that will break legacy authentications if environments are not prepared.

---

Why RC4 had to go​

The technical problem in plain terms​

RC4 is a stream cipher whose output keystream exhibits predictable biases. These biases, combined with weaknesses in key scheduling and simple key-derivation practices used historically with Windows NTLM/RC4, make it feasible for attackers to recover plaintext secrets far faster than with modern, iterated hash + AES constructions. Research over the last two decades — starting with the Fluhrer–Mantin–Shamir work and continuing through attacks demonstrated in the 2010s — made the vulnerabilities academic and practical. Practical "Bar Mitzvah" style attacks and numerous academic analyses have shown RC4’s keystream biases can be exploited to recover information from real-world streams. In Active Directory’s Kerberos implementation, RC4-based tickets can be targeted by offline cracking and other attacks because the service ticket encryption effectively reduces the defensive cost of guessing a password. AES‑based Kerberos session keys use far stronger key derivation and iteration counts, making offline cracking orders of magnitude harder. That fundamental cryptographic gap is why security pros have long urged the removal of RC4 from identity systems.

Practical attack chains that exploit RC4 weaknesses​

Two related techniques illustrate why RC4’s presence in Kerberos is not academic:

• Kerberoasting: attackers request service tickets (TGS) for service accounts and then perform offline cracking of the encrypted ticket to recover the account password. RC4/NTLM-style encryption yields tickets that can be brute-forced far faster than AES‑protected tickets, making Kerberoasting substantially more effective against RC4-protected service accounts.
• Golden / Silver Ticket and Pass‑the‑Ticket abuse: while these techniques do not strictly require RC4, the ability to extract ticket material and to forge or replay tickets has been facilitated by weak legacy cryptography and lax controls. Tools like Mimikatz dramatically lowered the bar for attackers to exploit ticketing weaknesses, and incident responders have repeatedly observed these techniques used in high-impact intrusions.

These attacks are not theoretical: incident reports and threat intelligence from multiple providers describe identity-based lateral movement and ticket-forging techniques as primary enablers of large-scale breaches. Organizations that relied on RC4-era Kerberos defaults faced a materially higher risk profile.

---

The announcement and timeline: what Microsoft is changing​

Microsoft’s public guidance and product blog posts describe a multi-step approach:

• New default behavior: domain controllers (KDC) on Windows Server 2008 and later will default to AES‑SHA1 encryption for Kerberos, and RC4 will be disabled by default for KDC ticket issuance by mid‑2026. Administrators can still explicitly re-enable RC4 for specific accounts or KDCs, but the intent is to flip the default away from the legacy cipher.
• Detection and remediation tooling: Microsoft published PowerShell scripts (List‑AccountKeys.ps1 and Get‑KerbEncryptionUsage.ps1) and guidance on how to discover accounts, machines, or service principals still using RC4. The company also documented Group Policy and Windows Admin Center workflows for enforcing encryption-type policies.
• Staged rollout and compatibility considerations: Microsoft recognizes that full removal risks breakage for legacy applications, so the change is a deliberate default flip with guidance and diagnostic tooling to drive migration. Administrators are being given months — not weeks — to audit and remediate environments before the change becomes operationally effective on new and updated domain controllers.

Microsoft’s public messaging is explicit: RC4 has been optional for years and can be disabled today, but doing so without a careful inventory can break legacy services. The default flip is intended to move the ecosystem toward safer defaults while preserving an escape hatch for rare, well-audited compatibility scenarios.

---

Real-world stakes: why this matters to enterprises​

Expensive breaches and real incidents​

Identity-based attacks and lateral movement are central to many modern breaches, and the financial stakes are large. The average cost of a data breach continues to climb: industry studies show breach costs in the multi‑million‑dollar range for affected organizations, with healthcare and critical infrastructure frequently hit hardest. Weak identity controls and exploitable encryption primitives materially increase dwell time and impact. Lawmakers and incident responders have made the risks tangible: congressional attention — including public letters from U.S. Senator Ron Wyden — highlighted specific incidents (including a large healthcare ransomware incident disclosed in 2024) where Kerberos abuse and weak defaults played a role in the attacker’s ability to pivot and deploy ransomware widely. That public pressure helped focus vendor attention on making default changes that reduce population-level exposure.

Examples of Kerberos-enabled lateral movement and persistence​

While different breaches have different root causes, post‑compromise lateral movement often relies on abusing authentication artifacts:

• Golden / Silver Ticket forgeries and pass‑the‑ticket replay have been observed in espionage and high-impact compromises across years of reporting and threat-intel studies. These techniques enable attackers to impersonate users, bypass local authentication checks, and persist undetected.
• Kerberoasting remains a low-bar, high-payoff technique because it can be executed by any valid domain user and is stealthy by design. Environments that still accept RC4‑protected service tickets are markedly more exposed to rapid credential compromise.

It is important to note that not every major historic breach was solely the result of RC4 usage; attacks are multi‑vector and depend heavily on credential hygiene, segmentation, and monitoring. However, weak cryptographic defaults have repeatedly amplified impact and reduced the time and resources attackers need to succeed.

---

Migration mechanics: what IT teams must do now​

Migrating an enterprise Active Directory environment away from RC4 requires planning, verification, and testing. Microsoft’s guidance and the defensive community converge on a common checklist:

• Inventory and detection
• Run Microsoft’s Get‑KerbEncryptionUsage.ps1 and List‑AccountKeys.ps1 (or equivalent SIEM queries) to identify accounts, SPNs, and endpoints that are requesting or accepting RC4-based tickets.
• Prioritize high‑risk accounts
• Focus first on service accounts with Service Principal Names (SPNs), privileged accounts, and accounts with weak/unchanged passwords. These are the most valuable targets for Kerberoasting and ticket‑forgery abuse.
• Move to AES-capable keys
• Ensure service accounts and machines have AES keys and that key material (supplemental credentials) include AES128/256 variants. Use Group Managed Service Accounts (gMSAs) where possible to reduce manual password risk.
• Apply Group Policy or security baseline
• Use the “Network security: Configure encryption types allowed for Kerberos” GPO and Microsoft’s 2025 security baseline to restrict allowed encryption types and audit compliance. Windows Admin Center and OSConfig baselines can help enforce these settings.
• Test and stage changes
• Do not flip defaults in production without testing. Use lab domains and staged rollouts to validate hardened settings and to detect legacy services that fail when RC4 is disallowed.
• Compensating controls
• Enforce long, randomly generated passwords for service accounts, enable MFA for administrative workflows, apply Just‑In‑Time (JIT) and Privileged Identity Management (PIM) practices, and monitor Kerberos logs for anomalous TGS/AS‑REQ patterns (event IDs 4769 / 4771).
• Third‑party audits and monitoring
• Use external consultants or internal red teams to simulate Kerberoasting and ticket forging to validate detection and response. Integrate findings into SIEM and EDR rules.

These steps are operationally straightforward but can be time‑consuming at scale. Large enterprises with thousands of service accounts and legacy on‑premise appliances should budget weeks to months to confidently migrate without service disruption.

---

Strengths of Microsoft’s approach — and remaining risks​

Notable strengths​

• Default hardening: Shifting the default to AES‑based Kerberos encryption reduces the "population risk" for organizations that delay hardening. Defaults matter: many organizations never change vendor defaults, so a vendor‑level default change moves the entire installed base toward better security.
• Guidance and tooling: Microsoft is publishing scripts, admin center controls, and a documented remediation path. This helps translate a risky default into an actionable migration project for IT teams.
• Phased approach: By disabling RC4 as a default rather than an immediate forced removal, Microsoft reduces the chance of breaking critical legacy services while still forcing organizations to plan and execute remediation.

Remaining risks and criticisms​

• Compatibility vs. security trade‑offs: Microsoft’s historical choices favored compatibility, which prolonged exposure. Critics (and some lawmakers) argue the company moved too slowly and that a faster removal would have reduced accumulated risk sooner. Congressional scrutiny and public pressure have framed this as more than a technical decision.
• Incomplete mitigation if admins misconfigure: The transition reduces default exposure but does not eliminate it. Administrators can still re-enable RC4 per account; without strict policy enforcement and auditing, some environments will remain vulnerable. Microsoft’s move reduces probability of exploitation but does not guarantee elimination.
• Dependency on password hygiene and segmentation: RC4 removal is powerful only when combined with strong passwords, rotation, least‑privilege, and segmentation. Kerberoasting can target AES tickets too — albeit at much higher computational cost — so poor password practices remain a critical failure point. Microsoft’s own guidance stresses these complementary controls.
• Legacy in‑market systems: Some unsupported or embedded devices cannot be upgraded and may require special handling. Microsoft’s phased approach leaves a path for these to remain functional but this path will also be a persistent risk if not tightly controlled.

---

Political and industry fallout​

Public scrutiny of identity‑security choices has reached regulators and lawmakers. Notably, a U.S. senator publicly urged the Federal Trade Commission to evaluate Microsoft for alleged cybersecurity negligence in relation to a high‑profile healthcare ransomware incident, citing RC4‑enabled Kerberoasting as a contributing factor. Microsoft responded by emphasizing that RC4 traffic is now a small minority (under 0.1% by the company’s published figures) and reiterated that a phased, compatibility‑aware retirement was necessary. The exchange underscored how vendor defaults are now viewed through the lens of national critical‑infrastructure risk. At the same time, security vendors, incident responders, and open‑source projects (for example, alternatives used in Samba and other interop stacks) have long since moved away from RC4 and now provide migration blueprints. The market pressure — from competitors, regulators, and enterprise security teams — finally aligned with Microsoft’s engineering roadmap to push a default change at scale.

---

What success will look like — and how to measure it​

A successful transition will be measurable in several ways:

• A continued downward trend in detected RC4 Kerberos events and a rise in AES‑protected TGS/AS requests in event logs and SIEM dashboards. Microsoft’s PowerShell tooling and event‑based telemetry will help teams quantify progress.
• Reduced incidence of identity‑centric lateral movement investigations tied to ticket‑based attacks (Kerberoasting, Golden/Silver Ticket, Pass‑the‑Ticket). This will require long‑term telemetry and post‑incident analysis across enterprise incident-response teams and vendors.
• Demonstrable remediation of legacy dependencies — for example, lists of devices and apps migrated off RC4 or isolated behind compensating network controls. This is an operational metric IT auditors can verify.

---

Practical checklist for CIOs and security teams (short, operational)​

• Run Microsoft’s Kerberos auditing scripts and SIEM queries to enumerate RC4 usage.
• Prioritize remediation of service accounts with SPNs and implement gMSAs where feasible.
• Apply Microsoft’s security baseline and Group Policy to restrict allowed Kerberos encryption types in test domains before production.
• Enforce strong randomness and length for service account passwords; rotate KRBTGT and critical service account credentials as part of incident response planning.
• Integrate Kerberos‑specific detections (unusual TGS/AS‑REQ patterns, RC4 usage flags) into SIEM/EDR playbooks and run tabletop exercises for ticket‑forging scenarios.

---

A caution about attribution and historical claims​

Many public narratives connect RC4 to specific high‑profile breaches; while weak encryption certainly amplified risk in multiple incidents, not every major breach can be singularly blamed on RC4. Breaches are multi‑vector, and effective defenders must look at cryptography, identity hygiene, segmentation, logging, and detection together. Where public reporting names Kerberos abuse (for example, in some investigations and congressional summaries), the role of weak cryptography has been corroborated by multiple independent reports and vendor analyses — but attribution of any breach to a single technical cause is often an oversimplification. When evaluating legacy‑cipher impacts on a particular incident, rely on incident reports, vendor advisories, and forensic timelines rather than single‑sentence summaries.

---

Closing analysis: the long tail of legacy code and the path forward​

Retiring RC4 from Active Directory Kerberos defaults is overdue from a security‑first perspective, and it is a meaningful step toward reducing a long‑standing class of identity attacks. Making the safer option the default is an effective design move: default configurations drive large swathes of the enterprise installed base, and flipping a default moves the needle much faster than guidance alone. Microsoft’s rollout, combined with detection tooling and security baseline recommendations, gives organizations a workable path to modernize authentication without sudden disruption. That said, the technical fix alone will not erase the underlying management problems that make Kerberos abuses lethal: poor password hygiene, unsegmented networks, insufficient monitoring, and the persistence of unsupported appliances. For most organizations, the RC4 retirement will reduce systemic risk, but only a comprehensive identity‑centric defense posture — strong secrets, rotation, least privilege, MFA, telemetry, and rigorous patching — will close the loop and convert a vendor default into durable resilience. The next 12–18 months will be the test: if enterprises use the breathing room to proactively inventory, remediate, and modernize, the industry will have taken an important step toward safer default security. If not, RC4 will become one more historical footnote in post‑mortems. The right operational posture is clear: find your RC4 dependencies, prioritize high‑risk service accounts, and make AES the baseline for Active Directory authentication now — not later.

---

Source: WebProNews Microsoft to Retire Vulnerable RC4 Cipher in Active Directory by 2026

 

[ChatGPT]

Microsoft’s plan to end RC4 as a Kerberos default marks a clear, overdue break with a decades‑old compatibility choice that has long weakened Active Directory security; by mid‑2026 domain controllers running Windows Server 2008 and later will default to issuing AES‑SHA1 session keys for Kerberos and RC4 will be disabled by default, with admins required to explicitly opt in to allow RC4 where absolutely necessary.

Background / Overview​

For almost twenty years, Windows Kerberos implementations retained RC4‑HMAC (commonly referred to simply as RC4) as a widely supported encryption option to preserve compatibility with legacy clients and appliances. That backward‑compatibility choice became a security liability because RC4’s design and typical key‑derivation in Windows make offline attacks—most notably Kerberoasting—substantially cheaper than against modern AES‑based enctypes. Microsoft’s Windows Server blog and technical guidance explain the upcoming default flip and the operational telemetry and tools being shipped to help administrators find and fix remaining RC4 dependencies. Microsoft’s guidance is explicit: the KDC default behavior will change so domain controllers issue AES‑SHA1 (AES‑based Kerberos enctypes such as AES128‑CTS‑HMAC‑SHA1‑96 and AES256‑CTS‑HMAC‑SHA1‑96) by default; if an account or client still requires RC4, the domain administrator must explicitly configure that exception. The company also added richer Kerberos auditing fields (e.g., msDS‑SupportedEncryptionTypes, Available Keys, Advertised Etypes, Ticket Encryption Type, Session Encryption Type) to Security Event Log entries (notably Event IDs 4768 and 4769) and published PowerShell scripts to make discovery actionable.

---

Why this change matters: the practical risk from RC4​

The Kerberoasting problem and RC4’s role​

Kerberoasting is a stealthy, low‑privilege attack that abuses normal Kerberos flows: an attacker with any domain account can request a service ticket for an SPN (service principal name), extract the portion encrypted with the service account’s key, and perform offline password cracking against that ticket. When a ticket is encrypted with RC4‑derived keys (the NTLM/RC4 path historically used in Windows), the offline cracking cost is dramatically lower than for AES‑protected tickets because of weak key derivation and the absence of salted, iterated hashing. That makes service accounts—especially those with weak or non‑rotated passwords—highly attractive targets. Microsoft calls Kerberoasting a primary driver for this change.

Cryptographic reality: RC4 is broken, AES is stronger in Kerberos​

RC4 is a stream cipher with well‑documented keystream biases and practical attacks published over decades; the Internet community long ago banned RC4 for TLS and other applications. In Kerberos, RC4’s practical weakness is amplified by how Windows historically derived keys (MD4/NTLM‑derived keys with little iteration and no salt), making offline brute force far cheaper. AES enctypes used in Kerberos rely on stronger key derivation and HMAC constructions that increase the cost of cracking by orders of magnitude. The result: removing RC4 as a default significantly raises the computational cost of offline ticket cracking and reduces the population‑level exposure to Kerberoasting.

---

What Microsoft is changing (technical specifics)​

Default KDC behavior and scope​

• The Kerberos Key Distribution Center (KDC) on domain controllers running Windows Server 2008 and later will be updated so that AES‑SHA1 is the default enctype for session keys.
• RC4 will be disabled by default. It remains available only if a domain admin explicitly configures a KDC or an account to permit RC4 for compatibility.
• The timeline Microsoft publicized sets mid‑2026 (end of Q2 2026 is the public planning target) as the planning deadline for this default flip. Administrators must treat this as an operational deadline to inventory and remediate RC4 dependencies.

Enhanced telemetry and auditing​

Microsoft extended Kerberos‑related Security Event Log entries (4768 for TGT requests and 4769 for service ticket issues) to include processed values that reveal:

• msDS‑SupportedEncryptionTypes — what encryption types the account or DC advertises.
• Available Keys / Account Keys — which derived key material is present for the account in AD (e.g., whether AES128/AES256 keys exist).
• Advertised Etypes — what clients advertise during requests.
• Ticket Encryption Type / Session Encryption Type — the etype actually used for a particular ticket/session.

Those fields make it operationally feasible to answer whether RC4 persistence is a client problem, a service/account provisioning issue, or a KDC policy/configuration issue. Microsoft also published two PowerShell scripts—List‑AccountKeys.ps1 and Get‑KerbEncryptionUsage.ps1—to parse logs and produce inventories for remediation.

---

How to detect RC4 usage in your environment (practical steps)​

Microsoft’s published guidance and scripts give administrators a concrete discovery pipeline; implement this as the first stage of a migration plan.

• Centralize Kerberos logs
• Forward Event IDs 4768 and 4769 from all domain controllers to a SIEM (Event Forwarding, Microsoft Sentinel, or third‑party SIEM).
• Ensure log retention covers the window needed to discover sporadic legacy clients.
• Use the new fields in those events to filter on Ticket/Session encryption types.
• Run Microsoft’s PowerShell helpers (on a test DC first)
• List‑AccountKeys.ps1 enumerates Available Keys and shows accounts that lack AES key material.
• Get‑KerbEncryptionUsage.ps1 summarizes ticket and session key etypes and supports filtering for RC4.
• Triage findings into actionable groups
• Accounts with SPNs that only show RC4 in Available Keys (likely need password resets to generate AES keys).
• Clients that advertise only RC4 (outdated OS, embedded devices, or third‑party stacks).
• Service applications that respond with RC4 (vendor configuration or legacy software).
• Prioritize remediation by risk
• High priority: service accounts with SPNs and any domain‑joined servers providing critical services.
• Medium: third‑party appliances used in production that cannot be quickly updated.
• Low: isolated lab equipment and devices slated for decommissioning.

---

Concrete remediation actions​

• Reset passwords for accounts missing AES keys (target the account holding the SPN). In some cases, two password resets are required to populate AES key material. Test carefully in a non‑production OU first.
• Migrate service accounts to Group Managed Service Accounts (gMSA) where feasible; gMSAs remove manual password management and mitigate weak password exposure.
• Update or replace clients that advertise only RC4. For embedded or unsupported devices, insist on vendor fixes, or isolate them behind network segmentation or an authentication proxy.
• For stubborn legacy appliances, consider an authentication gateway that terminates legacy Kerberos and relays with modern enctypes (with strict controls and monitoring).
• Enforce staged Group Policy changes: pilot an AES‑only allowed enctype in a test OU, then expand once validated. Keep rollback playbooks ready.

---

Recommended migration timeline (practical, sequential plan)​

• Inventory and detection (0–2 months)
• Deploy event collection, run the two Microsoft PowerShell scripts, and create a prioritized list of RC4 dependencies.
• Pilot and remediation (2–6 months)
• Reset passwords for top‑priority SPN accounts in test environments, validate application authentication, and implement gMSAs for suitable services.
• Vendor coordination and segmentation (6–12 months)
• Coordinate firmware/patch schedules with vendors. For devices lacking fixes, implement network segmentation and monitoring as compensating controls.
• Enforcement and tightening (12+ months, before mid‑2026)
• Gradually enforce AES‑only policies in production OUs, monitor for authentication failures, and address exceptions via documented, time‑boxed approvals.
• Exception management (ongoing)
• Every RC4 exception must be logged, owned, and have a sunset date. Treat re‑enabled RC4 settings as high‑risk technical debt.

---

Strengths of Microsoft’s approach — and why they matter​

• Default hardening is high‑leverage. Many organizations never change vendor defaults; moving the safe choice to the default reduces population‑level exposure quickly.
• Actionable telemetry. Adding explicit fields to 4768/4769 and publishing scripts addresses the operational barrier that historically slowed remediation: visibility.
• Phased rollout with tooling. Microsoft is not suddenly breaking authentication; the company provided detection tools and guidance alongside the policy flip to reduce accidental outages.

---

Limitations, residual risks, and caveats​

• Vendor and embedded device compatibility will be the principal friction point. Many network appliances, OT devices, or non‑Windows stacks may only support legacy enctypes and will require vendor action or isolation. This is an operational burden that can be time‑consuming and costly.
• Residual key artifacts: Active Directory will likely retain RC4/NTLM‑derived key material until accounts are rekeyed; the presence of RC4 keys in "Available Keys" does not necessarily mean RC4 is actively being used, but it is a residual attack surface until cleared.
• Exception risk: Allowing administrators to re‑enable RC4 for compatibility is necessary but dangerous. Without strict governance, these exceptions can become permanent and undermine the security gains of the default change.
• Timeline fragility: Microsoft’s public timeline is mid‑2026 for the default flip. Administrators should treat that as an operational deadline and validate specific rollout timing and release notes for their servicing channel, because enforcement timing can vary by patch level and servicing channel.

---

Political context and public scrutiny​

The decision did not occur in a vacuum. High‑impact intrusions that leveraged identity attacks and ensuing public and congressional attention put pressure on vendors to move faster. U.S. Senator Ron Wyden publicly urged regulatory scrutiny of Microsoft’s long tail of RC4 support following a widely reported healthcare ransomware incident; Microsoft responded by accelerating its default change and producing operational guidance—while also disputing some characterizations and stressing RC4 is now a very small share of Kerberos traffic in modern deployments. These events framed the default flip as not only a technical necessity but also a regulatory and public‑policy issue. Readers should treat claims about exact numbers (for example, percentages of traffic) with caution unless corroborated by vendor telemetry or published metrics. Note: some press coverage attributes quantitative claims (e.g., “RC4 constitutes less than 0.1% of Microsoft’s network traffic”). Those statements are summaries of Microsoft’s communications to reporters and should be verified directly against Microsoft’s published telemetry or statements before being used in compliance or legal contexts.

---

Operational checklist for IT and security teams (actionable)​

• Run List‑AccountKeys.ps1 across DC event logs and export the list of accounts lacking AES keys.
• Use Get‑KerbEncryptionUsage.ps1 to identify any recent RC4 session keys in tickets, and correlate with accounts and client IPs.
• Prioritize and reset passwords for SPN‑bearing accounts in test OUs to ensure AES keys are provisioned.
• Convert eligible service accounts to gMSAs where possible.
• Establish vendor engagement plans for devices that cannot be upgraded; plan segmentation or authentication proxying as compensating controls.
• Pilot an AES‑only Group Policy in non‑production OUs; measure authentication failures and refine rollback steps.
• Implement SIEM alerts for any RC4 Session Encryption Type events after the pilot and document each RC4 exception with owner and sunset date.
• Schedule quarterly reviews of remaining exceptions and progress toward a zero‑RC4 posture.

---

Final assessment — what success looks like​

Success will be measurable and practical:

• A clear and sustained decline of RC4 session keys in Security Event logs and SIEM dashboards.
• All high‑value service accounts (SPNs) rekeyed or migrated to gMSAs and no longer vulnerable to fast offline cracking via RC4 tickets.
• Documented remediation of legacy dependencies, or documented compensating controls (segmentation, proxies) with sunset timelines.
• A governance posture that treats RC4 exceptions as short‑term technical debt with strict monitoring, rather than permanent allowances.

---

Final thoughts and cautions​

Microsoft’s decision to flip Kerberos defaults away from RC4 and to provide auditing fields and remediation scripts is an important step for improving identity security at scale. The move aligns Kerberos defaults with contemporary cryptographic expectations and materially raises the cost of offline attacks like Kerberoasting. However, the operational reality is complex: legacy devices, vendor timelines, and the risk of poorly documented exceptions remain the biggest obstacles.
Administrators should treat mid‑2026 as a hard planning deadline: inventory now, pilot early, coordinate with vendors, and create rollback and exception governance playbooks. The technical change reduces systemic risk substantially, but it must be combined with strong password hygiene, least‑privilege, segmentation, and monitoring to eliminate the practical attack paths that have enabled large intrusions in the past.

---

Source: heise online Microsoft Sweeps RC4 Remnants from Kerberos