TL;DR: Microsoft’s RC4 deprecation for Kerberos begins with auditing in January 2026, manual rollback in April, and full enforcement in July, making legacy service accounts and unsupported applications the immediate risk, according to Semperis. The real issue is not encryption alone, but the long tail of RC4-only identity dependencies hidden in Active Directory.
At a glance
What this is: NHI Mgmt Group's analysis, drawing on Semperis's blog post: Microsoft's RC4 deprecation for Kerberos will break hidden Active Directory application dependencies when RC4 is removed.
Why it matters: IAM and identity teams need to find RC4-dependent service accounts, scheduled tasks, and legacy applications before enforcement turns a cryptographic change into an access outage.
Context
RC4 deprecation in Kerberos is an identity governance problem as much as a cryptography problem. Once Microsoft removes RC4 support, any service account, keytab, or application that still depends on RC4-only Kerberos flows will fail authentication even if the rest of the environment is healthy.
The operational risk is not abstract. Active Directory estates often contain legacy application bindings that were never reset for AES-era encryption types, so the dependency only becomes visible when tickets stop issuing or services stop starting. That makes discovery, inventory, and remediation a prerelease governance task, not a cleanup exercise after enforcement.
For identity teams, the challenge is to identify where Kerberos encryption types are still pinned to older behavior, then determine which apps can move to AES and which systems are too old to survive the change.
Key questions
Q: What breaks when RC4 is removed from Kerberos authentication?
A: Service and machine accounts that still depend on RC4 will fail to authenticate, which can take down applications and automated processes that rely on Active Directory tickets. The operational risk is not limited to login failure. It can interrupt business services, expose hidden legacy dependencies, and force emergency remediation under time pressure.
Q: Why does RC4 deprecation matter for Kerberoasting risk?
A: RC4 matters because it weakens Kerberos ticket encryption enough that attackers can take service tickets offline and brute-force the recovered material. That makes service accounts a practical target for credential recovery and follow-on lateral movement. Removing RC4 reduces the attack opportunity, but only if the environment no longer depends on it for normal authentication.
Q: How can teams tell whether RC4 is still active in Active Directory?
A: Look for event IDs 4768 and 4769 in the Security log and inspect the ticket encryption and session encryption fields for 0x17. If you also see KDC hardening warnings, those events can point to clients, accounts, or registry settings that still rely on RC4. That telemetry gives you a practical discovery path for remediation prioritization.
Q: How should identity teams prepare for Kerberos RC4 enforcement?
A: They should inventory every RC4-dependent account, determine which applications or member servers use those identities, and test AES-compatible authentication before the enforcement date. The remediation path depends on whether the problem is an old password, an unsupported client, or an application that needs redesign. The goal is controlled migration, not emergency replacement.
Technical breakdown
How RC4 still appears in Kerberos ticket flows
Kerberos tickets reveal the negotiated encryption type at issuance time. In the audit trail, event 4768 covers authentication service requests and event 4769 covers service ticket requests, while the encryption fields show whether the ticket and session key were issued with RC4 or AES. When the ticket encryption type is 0x17, the flow is using RC4-HMAC, which is the signal defenders need to track. This matters because the presence of RC4 in the ticket path usually reflects a dependency in the service account, client, or domain controller configuration rather than a one-off user choice.
Practical implication: Use Kerberos event telemetry to separate normal AES traffic from legacy RC4 dependencies before enforcement starts.
Why legacy service accounts keep RC4 alive
RC4 in Active Directory is tied to the NT hash, so accounts that never had a password reset after AES support became available may still only have RC4-compatible keys. That is why some service principals continue to negotiate RC4 even in otherwise modern environments. The article also notes that remediation may require resetting the password twice so AD can generate the necessary AES keys. This is a lifecycle issue, not simply a configuration tweak, because the identity object itself may be carrying forward an old cryptographic state.
Practical implication: Treat stale service account passwords as cryptographic debt and prioritize them for controlled reset and application testing.
How auditing exposes break scenarios before enforcement
Microsoft’s audit path relies on Security log events 4768 and 4769, and the article points to KDC hardening warnings in events 201 to 209 as the early warning layer. Those warnings help identify RC4-only clients, accounts lacking AES keys, registry overrides, and client incompatibilities before the July 2026 enforcement deadline. In practice, this turns Kerberos audit logs into a dependency map for migration work, because the same telemetry that proves RC4 use also shows where the environment still needs remediation.
Practical implication: Enable Kerberos auditing across every domain and use the warnings to build an ordered remediation queue.
Threat narrative
Attacker objective: Recover service account credentials from Kerberos tickets and reuse them for lateral movement and privilege escalation.
- Entry begins when an attacker requests a Kerberos service ticket for a valid SPN and receives a ticket encrypted with RC4.
- Credential access follows when the attacker takes the ticket offline and cracks it to recover the account password.
- Escalation and lateral movement occur when the compromised account is reused to move through the environment and elevate privileges.
- Impact is the broader Kerberoasting exposure that Microsoft’s RC4 deprecation is intended to reduce by removing the weaker encryption path.
Breaches seen in the wild
- Storm-0501 hybrid cloud attacks 2024: Ransomware affiliate Storm-0501 stole Entra Connect Sync credentials to move from on-prem AD to Entra ID, then forged tokens via a rogue federated domain.
- Cisco Active Directory credentials leak 2025: Kraken leaked Cisco Active Directory hashes, including service and krbtgt accounts; Cisco says they came from its 2022 breach, not a new one.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
RC4 deprecation is really a hidden dependency disclosure event: The first governance problem is not the cipher change itself but the inventory gap it exposes. Many AD programmes assume Kerberos encryption is already standardized, yet the article shows that legacy service accounts and applications can still be pinned to RC4 without obvious user-visible symptoms. The practitioner conclusion is simple: if you do not know which identities still require RC4, you do not actually know your Kerberos estate.
Legacy service account state is carrying the cryptographic debt: Accounts that have not had passwords reset since AES became available may still lack AES-compatible keys, which means the account object itself preserves outdated security capability. That is a lifecycle failure, not a pure hardening issue, because the identity persists with obsolete encryption characteristics. The implication is that password age and key generation state must be treated as governance signals, not just hygiene metrics.
Kerberos auditing becomes a remediation control, not just a detection control: Event IDs 4768 and 4769, plus KDC hardening warnings, are operationally useful because they identify where RC4 still exists before full enforcement breaks access. This makes audit readiness part of the change-management process for identity infrastructure. The practitioner conclusion is that successful RC4 removal depends on evidence-driven remediation, not policy declarations.
RC4 removal will separate modern authentication from identity debt: Organisations with clean AES-ready service accounts will absorb the change quietly, while those with opaque application dependencies will see authentication failures first and root-cause analysis later. That difference is what makes RC4 deprecation a governance test for AD maturity. The practitioner conclusion is to treat the deprecation timeline as a forced exposure of technical debt hidden inside identity dependencies.
Kerberoasting pressure is what makes this deprecation materially important: Microsoft is not removing RC4 in a vacuum. The cipher has remained attractive to attackers because weaker ticket encryption lowers the cost of offline cracking, which in turn turns service account exposure into lateral movement potential. The practitioner conclusion is that cryptographic modernization and identity privilege reduction have to move together, not as separate programmes.
What this signals
RC4 deprecation is exposing identity debt inside Active Directory: the environment may look stable until enforcement removes the weaker encryption path and legacy workloads fail under the first real authentication check. For practitioners, the signal is to treat Kerberos telemetry as a dependency inventory and not as a post-incident log source.
Audit readiness is now part of the change plan: if event 4768, event 4769, or KDC hardening warnings are not already visible in your SIEM, you do not yet have the evidence needed to separate RC4 clients from RC4 service accounts. The practical programme shift is to validate telemetry before you begin broad remediation.
Hidden RC4 dependencies are a service account lifecycle problem: old passwords, missing AES keys, and undiscovered application bindings show that the governance issue sits at the intersection of identity ownership and application support. Teams should expect the remediation queue to be driven by account age, owner visibility, and workload compatibility rather than by pure technical priority.
For practitioners
- Audit Kerberos ticket use now Search Security logs for event IDs 4768 and 4769, then flag any ticket or session encryption value of 0x17 to identify RC4-dependent identities and services.
- Reset stale service account passwords twice For accounts that still lack AES keys, reset the password twice so Active Directory generates the required AES-compatible keys and the account can stop relying on RC4.
- Validate service ticket auditing in every domain Enable Audit Kerberos Authentication Service and Audit Kerberos Service Ticket Operations for success and failure across each domain controller OU before you rely on the logs for discovery.
- Map application owners to each RC4 dependency Identify which service, scheduled task, or member server is bound to each RC4-capable account so remediation can be tested against the exact workload that depends on it.
Key takeaways
- RC4 deprecation turns a cryptography change into an Active Directory dependency audit, because hidden service account and application bindings will fail when enforcement arrives.
- Kerberoasting remains the security rationale for the change, since RC4-encrypted tickets can be taken offline and cracked to recover credentials.
- Teams that validate Kerberos auditing, reset stale service accounts, and map application ownership now will avoid discovering RC4 debt through outages later.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST SP 800-53 Rev 5 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-07 — Long-Lived Secrets | Legacy RC4-only accounts persist because old passwords and keys were never refreshed. |
| NHI-01 — Improper Offboarding | Unsupported applications and stale identities become breakpoints when RC4 support is removed. | |
| Recommendation — Review long-lived account credentials and reset any service identity still carrying RC4-only keys. Retire or rehome identities that cannot transition off RC4 before enforcement removes the fallback. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | The article centers on credential lifecycle actions needed to move accounts from RC4 to AES. |
| Recommendation — Apply authenticator management controls to force AES-ready resets for affected service accounts. | ||
| MITRE ATT&CK | TA0006; TA0008 — Credential Access; Lateral Movement | Kerberoasting uses RC4 tickets to recover credentials and then move laterally. |
| Recommendation — Map RC4 exposure to credential access and lateral movement techniques to prioritize high-value service accounts. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | Kerberos encryption dependencies affect whether identity authorizations can succeed under enforcement. |
| Recommendation — Validate entitlement dependencies before removing RC4 so authentication changes do not break access paths. | ||
Key terms
- Kerberoasting: Kerberoasting is an Active Directory attack that targets service accounts by requesting Kerberos tickets and attempting to crack the underlying password offline. It is dangerous because weak service account passwords and excessive permissions can turn one ticket into elevated access across critical systems.
- Kerberos Ticket-Granting Ticket: A Kerberos credential that proves the user has already authenticated and can request service tickets without re-entering credentials. In delegation scenarios, it becomes valuable because a service may store it in memory, making it a target for attackers who compromise the host.
- Service Account: A special-purpose account used by applications, automated tools, or services rather than a human user to interact with systems, APIs, and infrastructure. Service accounts are a primary category of NHI and one of the most frequently exploited attack vectors.
- KDC Hardening: KDC hardening is the set of Kerberos Domain Controller warnings and enforcement signals that help administrators detect weak or incompatible ticket encryption before full policy rollout. It is useful because it turns silent legacy dependence into visible identity telemetry. Teams should treat it as migration evidence, not just a patch note.
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.
Published by the NHIMG editorial team on June 6, 2026.
Updated on October 8, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org