RC4 deprecation exposes hidden Kerberos app dependencies in AD

At a glance

What this is: This is an Active Directory and Kerberos audit guide showing how RC4 deprecation surfaces legacy application and service account dependencies that still rely on weak encryption.

Why it matters: It matters because IAM, PAM, and NHI teams need to find and remediate RC4-dependent service accounts before enforcement breaks authentication and exposes hard-to-recover legacy identity debt.

By the numbers:

• Microsoft has announced the deprecation of RC4 encryption beginning in April 2026, with auditing beginning January 2026 and full enforcement in July 2026.
• The query in the article looks back 60 days when searching for RC4-related Kerberos events in Microsoft Sentinel.

👉 Read Semperis' guide to auditing RC4-dependent Kerberos apps before enforcement

Context

RC4 deprecation in Kerberos is really an identity governance problem. The protocol change is straightforward, but the operational dependency graph is not, because many applications still depend on service accounts, scheduled tasks, and old password states that never generated AES keys.

For IAM and NHI programmes, the practical question is not whether RC4 is weaker, but which identities and workloads still require it to keep running. That makes discovery, audit logging, and account lifecycle evidence the control points that matter before enforcement turns hidden technical debt into authentication failure.

Key questions

Q: How should teams handle RC4-dependent service accounts before Kerberos enforcement changes?

A: Identify every service account, SPN, and scheduled task that still depends on RC4, then confirm where each one is used in production. Reset passwords where old key material is the blocker, change supported encryption types to AES, and test the service after every change. The goal is to remove hidden identity dependencies before enforcement turns them into outages.

Q: Why do old service accounts keep breaking Kerberos encryption migration projects?

A: Because RC4 support in Active Directory is often tied to password history, not just current configuration. If an account never had its password reset after AES became available, it may still lack usable AES keys even when the service appears healthy. That makes identity lifecycle state the deciding factor in whether migration succeeds.

Q: What breaks when Kerberos auditing is not enabled before RC4 deprecation?

A: Teams lose the evidence needed to see which identities still request RC4 tickets, so remediation becomes guesswork. If 4768 and 4769 are not collected, and KDC hardening events are missing too, the first signal may be service failure after enforcement. Audit readiness is therefore part of migration readiness.

Q: Who is accountable when RC4 deprecation breaks a business application?

A: Application ownership, directory ownership, and identity governance ownership all share accountability, but the operational fix usually sits with the team that controls the service account and the service restart path. In practice, the accountable team is the one that can trace the dependency, change the encryption setting, and prove the account now supports AES.

Technical breakdown

Kerberos RC4 usage and service ticket dependence

Kerberoasting exploits the fact that a service ticket can be requested for a valid SPN and then cracked offline if the ticket is protected with RC4. In Active Directory, the encryption type is visible through the Kerberos Authentication Service and Ticket Granting Service flows, especially event IDs 4768 and 4769. The article shows how ticket encryption, session encryption, and supported encryption types reveal whether an account or service is still bound to RC4. That matters because the issue is often not the application code itself, but the identity object backing the service.

Practical implication: identify every SPN and service account that still advertises RC4 before enforcement removes the fallback.

Why old passwords keep RC4 alive in Active Directory

RC4 in Active Directory is tied to the NT hash, which means older accounts can remain RC4-only if their passwords were never reset after AES became available. That is a lifecycle issue, not just a crypto issue. The account may look healthy in service terms while still lacking the key material needed for AES-based tickets. The article also notes that some remediations require resetting the password twice so AD regenerates the right keys. This is why legacy service accounts are usually the hardest part of RC4 removal.

Practical implication: verify password-reset history and key generation state for every legacy service account before changing encryption policy.

KDC hardening events and audit readiness

Microsoft’s newer KDC hardening events complement the leading 4768 and 4769 signals, but they only help if Service Ticket Auditing is enabled across the domain. The article’s guidance makes clear that logging is an architecture dependency, not a nice-to-have control. Without the right policy, teams may not see RC4 usage at all, which means they will discover breakage only after enforcement. The audit path also depends on how event forwarding is configured, so telemetry design becomes part of remediation planning.

Practical implication: enable Kerberos audit policy and validate that forwarded security logs actually capture 4768 and 4769 events.

Threat narrative

Attacker objective: The attacker aims to turn weak Kerberos encryption into reusable account credentials that unlock lateral movement and elevated access in the domain.

1. Entry begins when an attacker requests a service ticket for a valid SPN and the KDC issues RC4-protected Kerberos material that can be attacked offline.
2. Credential access follows when the attacker cracks the ticket offline to recover the service account password or equivalent credential material.
3. Escalation and impact occur when the compromised account is reused for lateral movement and privilege escalation inside Active Directory.

Breaches seen in the wild

• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.
• LiteLLM PyPI package breach — LiteLLM PyPI supply chain attack, credentials stolen from users.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

RC4 deprecation is exposing identity lifecycle debt, not just cryptographic weakness. The article shows that the accounts most likely to fail are legacy service identities whose password history never generated AES keys. That means the real gap is lifecycle visibility, not a missing encryption setting. Practitioners should treat RC4 as a marker for unmanaged identity age and configuration drift.

Kerberos audit coverage is a control prerequisite, not a troubleshooting aid. The post makes clear that 4768 and 4769 are only useful if Service Ticket Auditing is enabled and logs are actually forwarded. This is a classic governance failure mode in which teams assume telemetry exists because policy says it should. The practical conclusion is that identity controls without observable evidence are not enforceable controls.

Legacy service accounts remain the most stubborn NHI dependency in Active Directory. Scheduled tasks, member servers, and old application bindings can keep an account alive long after its password hygiene and encryption state have fallen out of compliance. That makes RC4 decommissioning a lifecycle-offboarding problem as much as a protocol problem. Security teams need to know where the account runs, who owns it, and whether it can be replaced.

RC4 migration will separate environments with real identity governance from environments with only configuration management. The article shows that remediation may require double password resets, supported encryption type changes, and service restarts across multiple domains. Those steps only work when ownership, dependencies, and audit evidence are already mapped. The broader lesson is that NHI governance has to connect identity state to operational service reality.

RC4-only compatibility is a named failure mode of trust in old key material. We can call this legacy encryption persistence: a state in which an identity continues to authenticate through obsolete algorithm support because its lifecycle never forced fresh key generation. That failure mode is already visible in Kerberos, and it will surface elsewhere whenever deprecation outruns asset discovery. The practitioner conclusion is to stop treating weak encryption as a purely protocol-level issue.

From our research:

• 72% of organisations have experienced or suspect they have experienced a breach of non-human identities, with 46% confirmed and 26% suspected, according to The 2024 ESG Report: Managing Non-Human Identities.
• Enterprises that have experienced a compromised NHI averaged 2.7 separate incidents in the past 12 months, which shows how quickly identity debt compounds once a service account or token set is exposed.
• That pattern aligns with the NHI Lifecycle Management Guide, because lifecycle state, not just cryptographic strength, determines whether old identities can be retired safely.

What this signals

RC4 deprecation should be treated as a discovery exercise for hidden service identity sprawl. Once teams start looking at 4768 and 4769 events, they usually find that the technical breakpoints are really ownership gaps, stale passwords, and services nobody can easily change. The programme signal is clear: if you cannot inventory the identity, you cannot retire the algorithm.

Legacy encryption persistence: environments that still rely on RC4 are usually carrying unresolved lifecycle debt in service accounts, scheduled tasks, and old application bindings. That means the next enforcement wave will expose who has real dependency mapping and who only has policy documents. Teams should prepare for remediation work to spread across IAM, Windows engineering, and application operations.

For practitioners, the useful next step is to align Kerberos audit data with the Ultimate Guide to NHIs , Key Challenges and Risks and the NIST Cybersecurity Framework 2.0. That combination helps translate RC4 findings into measurable governance, detection, and recovery tasks rather than one-off cleanup.

For practitioners

• Audit Kerberos events for RC4 usage Search event IDs 4768 and 4769 for ticket encryption or session encryption type 0x17, then map each result back to the service account and SPN that still depends on RC4.
• Rebuild legacy service account key material Reset affected service account passwords twice so Active Directory generates AES keys, then verify the account no longer advertises RC4 in supported encryption types.
• Validate log forwarding before enforcement Confirm that Security and System logs are being collected from every domain controller so KDC hardening events and Kerberos ticket events are visible before July 2026.

Key takeaways

• RC4 deprecation is exposing legacy service-account debt that many Active Directory programmes have not inventoried.
• The article’s evidence shows that Kerberos audit coverage, not just encryption policy, determines whether teams can find and fix affected identities before enforcement.
• The control that matters most is lifecycle-aware remediation of service accounts, supported by validated audit logs and AES-ready key material.

Key terms

• Kerberoasting: Kerberoasting is an attack that abuses Kerberos service ticket handling to recover service account credentials offline. The attacker requests a ticket for a valid SPN, then cracks the encrypted material later. In Active Directory, the risk rises when weak encryption or stale account state keeps ticket material easier to brute force.
• Service Principal Name: A Service Principal Name, or SPN, is the Kerberos identifier used to request a ticket for a specific service instance. It ties a service to the account that runs it, which is why SPN inventory is central to NHI governance. If the SPN is stale or misbound, the hidden identity risk grows quickly.
• Supported Encryption Types: Supported encryption types are the algorithms an account, service, or domain controller can use when issuing or accepting Kerberos tickets. In practice, this setting reveals whether a workload can still fall back to RC4 or is ready for AES-only operation. It is both a security control and an audit signal.
• 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

RC4 deprecation, Kerberos auditing, and legacy service account remediation are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are mapping identity dependencies ahead of enforcement, it is worth exploring.

This post draws on content published by Semperis: why RC4 is being decommissioned and how to audit for apps that use it. Read the original.