RC4 deprecation in Kerberos exposes hidden Active Directory risk

At a glance

What this is: Microsoft’s Kerberos RC4 deprecation will force legacy Active Directory dependencies into the open by breaking authentication for accounts that still rely on weak encryption.

Why it matters: IAM and NHI teams need a complete view of service and machine accounts now, because the failure mode is operational outage first and security exposure second.

By the numbers:

• Only 5.7% of organisations have full visibility into their service accounts.
• 71% of NHIs are not rotated within recommended time frames, increasing the risk of compromise over time.
• 79% of organisations have experienced secrets leaks, with 77% of these incidents resulting in tangible damage.

👉 Read Silverfort's analysis of RC4 deprecation and Kerberos authentication risk

Context

RC4 deprecation in Kerberos is a legacy authentication problem with direct NHI governance consequences. In Active Directory, service accounts and machine accounts often depend on encryption choices that were never explicitly documented, which means the first sign of exposure can be a failed login path when enforcement changes.

The April 2026 Windows update changes the operating assumption from permissive fallback to explicit compatibility management. For IAM teams, that means identity inventory is no longer just about who has access, but which accounts still depend on older cryptographic behaviour and where those dependencies will break under enforcement.

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 do service accounts create the biggest RC4 risk in Active Directory?

A: Service accounts often keep old passwords for long periods, and older passwords may never have generated AES keys. If their encryption settings were never updated, they can continue to rely on RC4 silently. That makes them both a security liability and a likely failure point when enforcement removes weak encryption fallback.

Q: How do security teams know if Kerberos RC4 is still in use?

A: Teams should combine posture assessment with authentication log review. Look for weak encryption indicators, then confirm the source host, target service, and account involved in each ticket request. That approach distinguishes accounts that merely might be at risk from accounts actively using RC4 in production.

Q: What should teams do in the first 72 hours after RC4-related authentication failures start?

A: Contain the outage by identifying affected services, checking whether the RC4 rollback option is still available, and prioritising the most business-critical accounts. Then validate which accounts need password resets, OS upgrades, or exception handling. The goal is to restore service without freezing the remediation programme.

Technical breakdown

Why RC4 in Kerberos becomes an NHI exposure

Kerberos issues tickets to prove identity to a target service, and the encryption type protecting those tickets determines how resistant they are to offline cracking. RC4 is weak by modern standards, which makes service tickets attractive to Kerberoasting attacks when a valid domain account can request and capture them. In an Active Directory environment, that risk is tied to non-human identities such as service accounts and machine accounts, not just interactive users. If the account still negotiates RC4, an attacker can often move from basic domain access to service account compromise without triggering strong detection. The issue is not only cryptographic weakness, but the hidden persistence of legacy dependencies across identity estates.

Practical implication: Inventory which NHI accounts still use RC4 before enforcement turns weak encryption into production outage.

How undefined encryption settings create hidden Kerberos dependency

The msDS-SupportedEncryptionTypes attribute controls which Kerberos encryption types are allowed for an account. When that attribute is not explicitly set, older environments often fall back to defaults that may still include RC4. That creates a blind spot because the account may appear normal until a ticket request exposes the dependency. Service accounts are especially risky because passwords may predate AES support, so a password reset is required before stronger keys exist. Machine accounts are different: older operating systems may not support AES at all, which means RC4 persists as a compatibility requirement until the endpoint is upgraded or retired.

Practical implication: Treat undefined encryption settings as an identity hygiene defect and map them to account owners now.

What the phased RC4 rollback changes in practice

The deprecation sequence matters because audit and enforcement are not the same thing. The audit phase reveals where weak encryption is present, but the enforcement phase removes RC4 as a silent fallback for accounts with undefined settings. Microsoft’s temporary rollback option buys time, but it does not change the underlying compatibility problem. Once rollback is removed, any remaining dependency becomes a hard failure condition. That shifts the control question from detection to remediation sequencing, because teams need to decide which service accounts, machine accounts, and applications must be fixed first to avoid outages.

Practical implication: Use the audit window to prioritize breakpoints by business criticality, not by which systems are easiest to fix.

Threat narrative

Attacker objective: The attacker aims to recover service account credentials and expand from low-privilege domain access into broader control of Active Directory-backed services.

1. Entry occurs when a valid domain account requests a service ticket for a Kerberos-enabled resource that still negotiates RC4.
2. Credential harvesting happens offline when the attacker captures the RC4-encrypted ticket and brute-force cracks the service account password.
3. Escalation follows when the compromised service account is reused across applications or granted broader access than intended.
4. Impact is lateral movement across the Active Directory environment and potential service disruption if legacy RC4 dependencies are removed without remediation.

Breaches seen in the wild

• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.
• ASP.NET machine keys RCE attack — 3,000+ exposed ASP.NET machine keys enabled remote code execution.

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 really an NHI inventory problem disguised as a cryptography change. The control failure is not whether RC4 is weak, because that part is settled. The failure is that many organisations cannot reliably enumerate which service accounts and machine accounts still depend on it. That makes remediation sequencing impossible until enforcement starts causing breaks. Practitioners should treat encryption inventory as part of identity governance, not as an afterthought in platform hardening.

Hidden fallback behaviour creates identity blast radius. When Kerberos accepts weak encryption implicitly, the risk is not evenly distributed. A small number of forgotten service accounts or obsolete machines can create broad outage potential across business-critical applications. That is why the real governance question is not simply whether RC4 exists, but which workloads will fail when it is removed. Teams need to map dependencies to business services before the change is enforced.

RC4 retirement validates the shift from standing compatibility to explicit exception management. Legacy tolerance has been functioning like standing privilege for encryption, because systems were allowed to continue with insecure defaults. The removal of that tolerance forces organisations to make compatibility exceptions visible and time-bound. That is a healthier operating model, but only if identity owners can see and own the exceptions. Otherwise the change will surface as unplanned downtime instead of controlled remediation.

Service accounts and machine accounts need different remediation paths. Service accounts usually require password resets, ownership review, and sometimes application testing before AES can be used safely. Machine accounts often require operating system upgrades or decommissioning plans, because some endpoints cannot negotiate stronger encryption. A single policy will not solve both problems. Mature NHI governance separates account classes and assigns remediation according to actual technical dependency, not by account label.

Strengthening Kerberos here does not reduce the need for continuous authentication monitoring. Once RC4 disappears as a fallback, the remaining question is whether environments can detect weak-encryption attempts, account drift, and unmanaged legacy systems early enough to avoid disruption. That makes visibility a governance control, not just a detection feature. Practitioners should use the deprecation window to prove they can see the dependency chain before the default changes.

From our research:

• Only 5.7% of organisations have full visibility into their service accounts, according to the Ultimate Guide to NHIs.
• 91.6% of secrets remain valid five days after the targeted organisation is notified, showing how slowly identity and secret remediation can lag operational exposure.
• The 52 NHI breaches Report shows how hidden non-human identity exposure often becomes visible only after attackers have already used it.

What this signals

Identity blast radius: RC4 retirement will expose how much of Active Directory still runs on undocumented compatibility assumptions. For programmes that already struggle with service-account visibility, the change will separate teams that have true inventory from teams that only have directory lists. That is why service ownership, encryption state, and business criticality need to be managed together.

For many organisations, the practical next step is to align Kerberos remediation with NIST SP 800-63 Digital Identity Guidelines and Zero Trust Architecture thinking, even though the problem sits inside legacy AD. Once encryption defaults can no longer be trusted to fail open, exception management becomes a named control surface. Teams that treat this as an identity workstream, not a one-time patch cycle, will reduce both outage risk and lingering weak-encryption exposure.

For practitioners

• Map every RC4-dependent account Build an inventory of service accounts, machine accounts, and applications that still negotiate RC4, then assign an owner and remediation deadline for each one.
• Reset legacy service account passwords Reset passwords for service accounts whose last password set predates AES support so new AES keys are generated and RC4 dependency is removed.
• Upgrade or retire unsupported machines Identify machine accounts tied to older operating systems that cannot use AES, then move them to upgrade or decommission tracks before enforcement begins.
• Use audit logs to confirm live RC4 usage Track weakly encrypted ticket requests in authentication logs and tie each event to the source host, target service, and domain controller for remediation prioritisation.

Key takeaways

• RC4 deprecation in Kerberos turns hidden Active Directory dependencies into a visible operational risk for service and machine accounts.
• The main challenge is not knowing that RC4 is weak, but locating where legacy encryption still exists before enforcement causes failures.
• Teams should use the audit window to map owners, reset stale service accounts, and retire incompatible systems before rollback disappears.

Key terms

• Kerberoasting: Kerberoasting is an attack pattern where a valid domain account requests a service ticket and captures it for offline password cracking. The risk rises when tickets are protected with weaker encryption, because attackers can work on the hash without further interaction with the environment.
• Service Account: A service account is a non-human identity used by software, services, or automation to authenticate to resources in an Active Directory environment. These accounts often persist for years, which makes password age, key strength, and ownership hygiene central to governance.
• Machine Account: A machine account is the identity Active Directory creates for a domain-joined device. It usually rotates automatically, but encryption support depends on the operating system and configuration, so older endpoints can remain locked to weaker authentication methods until they are upgraded or retired.
• Kerberos Ticket Encryption: Kerberos ticket encryption is the cryptographic protection applied to tickets that prove identity to a service. It matters because the strength of the encryption determines how difficult it is for an attacker to capture and crack a ticket offline, especially in legacy environments.

Deepen your knowledge

Kerberos RC4 deprecation and NHI dependency mapping are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are preparing for legacy Active Directory remediation, it is worth exploring.

This post draws on content published by Silverfort: RC4 deprecation in Kerberos and how to find hidden dependencies. Read the original.