Kerberos delegation risk extends to machine accounts in Active Directory

At a glance

What this is: This is an analysis of how Kerberos delegation risk in Active Directory extends to machine accounts, with CVE-2025-60704 showing that delegated computer identities can be abused for elevation to domain-level control.

Why it matters: IAM, PAM, and NHI teams need to treat sensitive machine accounts as delegation targets, not just human users, because hidden defaults in AD can leave Tier 0 identity infrastructure exposed.

Context

Kerberos delegation is a control-plane mechanism that preserves identity across tiers when one service must act on behalf of another. The governance gap in this article is that Active Directory administrators often model delegation as a user-only risk, even though computer objects can also be delegated and may carry Tier 0 authority.

For machine identities, the practical problem is not just visibility but lifecycle control. If a sensitive computer account can be used in delegated flows without being marked non-delegable, the organisation has created an identity trust path that bypasses the same scrutiny normally applied to privileged users.

Key questions

Q: What breaks when a sensitive machine account is left delegable in Active Directory?

A: A delegable machine account can be impersonated in Kerberos flows, which lets an attacker turn routine service trust into privileged directory access. The risk is greatest when the computer object anchors Tier 0 infrastructure such as domain controllers or identity services. In practice, the break is not just technical exposure but a collapsed trust boundary around the control plane.

Q: Why does Kerberos delegation on machine accounts create higher-risk escalation paths?

A: Because machine identities often hold authority equivalent to privileged users, delegation on those objects can convert a weak entry point into domain-level control. The risk rises when the identity can reset passwords, replicate directory data, or mediate identity services. That makes delegated computer objects a direct escalation path, not a configuration footnote.

Q: How do security teams find machine accounts that should not be delegated?

A: Start with Tier 0 and identity infrastructure, then identify any computer account that can influence authentication, replication, or certificate issuance. Those objects should be reviewed for delegation paths and marked non-delegable where the business dependency is not required. The aim is to remove trust from the machines that govern trust itself.

Q: What should teams do when a service depends on delegation to a computer account?

A: Treat the dependency as a governance exception and verify whether the service truly needs to act on behalf of that machine identity. If the answer is yes, constrain the path tightly and document the justification. If the dependency exists only because nobody noticed it, that is a control gap worth remediating immediately.

Technical breakdown

Why computer accounts are eligible for Kerberos delegation

Kerberos constrained delegation lets a service obtain tickets on behalf of another identity so it can complete back-end work in the caller’s context. In Active Directory, that identity can be a user or a computer object, which means the delegation boundary is broader than many administrators assume. The risk appears when a service trusted for delegation can request tickets for a machine account that holds administrative authority or can reach privileged infrastructure. Because computer objects do not present the same UI protection as users, this trust path is easier to overlook in routine hardening.

Practical implication: Treat delegated access to computer objects as a Tier 0 governance issue, not a niche configuration detail.

Why the ADUC interface creates a blind spot for machine identities

The ADUC console exposes an easy user-side control, 'Account is sensitive and cannot be delegated', but it does not surface the equivalent protection for computer accounts. Under the hood, the same userAccountControl bit exists for machine objects, and the NOT_DELEGATED setting still works when applied through PowerShell or other directory tools. The architectural problem is therefore not the absence of a control, but the absence of a visible and routine administrative workflow around it. That gap causes privileged machines to remain delegable simply because the protection is not obvious in day-to-day administration.

Practical implication: Build a non-UI workflow to identify and mark sensitive machine accounts as non-delegable.

How CVE-2025-60704 turns delegation into domain-level compromise

The exploit path described in the article combines a web enrollment request with Kerberos delegation abuse. The attacker can alter the certificate request path, obtain a certificate tied to a privileged machine identity, and then use that trust to reach DCSync-level impact. The important point is that the protocol chain depends on delegation being accepted on behalf of a machine account that should have been protected. Once that machine identity is reached through the delegation flow, the attacker no longer needs to target the original weak user account.

Practical implication: Audit delegation paths that terminate on privileged machine identities before they become the pivot into domain control.

Threat narrative

Attacker objective: Obtain machine-level trust that can be converted into domain administrator-equivalent control and directory replication capability.

1. Entry begins with a weak user identity that can reach a service participating in constrained delegation.
2. Credential or ticket abuse occurs when the attacker manipulates the delegation flow to act on behalf of a privileged machine account.
3. Escalation follows when the attacker uses the resulting certificate and delegated trust to obtain machine-level authority.
4. Impact is domain dominance, demonstrated through a DCSync path that exposes control over directory secrets.

Breaches seen in the wild

• Zacks breach claim 2025: A hacker leaked 12 million Zacks accounts in 2025, claiming domain admin access in 2024; HIBP verified the data, Zacks has not confirmed.

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

NHI Mgmt Group analysis

Delegation risk is not a user-only control problem: Active Directory delegation logic applies to computer accounts as well as users, so the common mental model is incomplete. That matters because machine identities often sit closer to Tier 0 services than ordinary accounts do, and the attack surface changes when those objects can be impersonated in delegated flows. The practitioner conclusion is that delegation governance must explicitly include computer objects, not just privileged humans.

The missing UI control is the governance failure, not the absence of a backend capability: AD already supports the NOT_DELEGATED bit for computer accounts, but the console hides that reality from most administrators. This is a classic governance-by-visibility failure: if the control is not part of the normal operator workflow, sensitive machines remain exposed by default. The implication is that directory hardening programmes should measure whether the control is operationalised, not merely available.

Kerberos delegation trust debt accumulates around Tier 0 machine identities: When services routinely impersonate privileged machine accounts, the organisation inherits trust paths that are hard to reason about and harder to audit. The problem is not delegation itself, but delegation on identities that can reset passwords, replicate directories, or anchor identity infrastructure. Practitioners should treat this as a Tier 0 blast-radius issue, because one delegated machine account can become the shortest path to domain control.

Domain controllers and identity infrastructure should be non-delegable by default: The article’s central lesson is that any machine identity that controls identity should be presumed sensitive until proven otherwise. That includes domain controllers, AD CS tiers, federation bridges, and replication-capable machines. The conclusion for identity governance is straightforward: if a machine account can govern identity outcomes, it belongs in the same protection class as other privileged control-plane assets.

Tier 0 machine account delegation is a specific failure mode, not a generic NHI risk: The article shows a concrete pattern where delegation on a sensitive computer object enables escalation from routine access to directory dominance. That failure mode is now named and observable, which makes it easier to baseline and audit. The practitioner takeaway is to classify delegated machine identities as a distinct governance control point, not a general hygiene task.

What this signals

Kerberos delegation becomes a Tier 0 governance issue once computer accounts are in scope: Many AD hardening programmes still focus on privileged users, but the article shows that machine identities can sit on the same delegation path and carry equal or greater authority. That means the control objective shifts from 'protect users from delegation' to 'remove delegation from the identities that control identity.'

Hidden directory defaults create trust debt: When a security control exists in the backend but is not surfaced in the normal admin workflow, it is easy for privileged machine accounts to remain delegable for years. The operational signal is simple: if a service can legitimately act on behalf of a domain controller, the trust model already needs review.

What the article really signals is a hardening baseline problem: Organisations that have already separated human privileged access from routine access still need a parallel standard for sensitive computer objects. The missing baseline is not a new technology, but a consistent rule that Tier 0 machine identities are non-delegable unless an exception is explicitly justified.

For practitioners

• Mark sensitive machine accounts as non-delegable Use the ADS_UF_NOT_DELEGATED setting on Tier 0 computer objects so S4U2Proxy requests targeting those identities fail by design.
• Audit delegation trust paths before changing machine flags Review msDS-AllowedToDelegateTo and msDS-AllowedToActOnBehalfOfOtherIdentity so you know which services depend on delegated machine identity flows.
• Inventory Tier 0 computer objects that control identity Prioritise domain controllers, AD CS tiers, federation bridges, and replication-capable machines for non-delegable treatment.
• Validate service breakage as a signal of hidden trust If a service fails after you remove delegation from a machine account, investigate whether that dependency was actually justified or a latent privilege path.

Key takeaways

• Kerberos delegation is not just a user-account issue, because computer objects can also be delegated and abused as part of a domain escalation path.
• The article’s evidence points to a widespread hardening gap, with sensitive machine accounts often left delegable because the protection is hidden from ordinary administration workflows.
• The decisive control is to mark Tier 0 machine identities as non-delegable and review any service that still requires on-behalf-of access to them.

Key terms

• Delegation authority: Delegation authority is the right for one identity to act on behalf of another within a defined scope. For agents, it must be explicit, time-bound, and auditable because the system may initiate actions independently once granted access.
• Computer Account: An Active Directory object that represents a machine, server, or domain controller and can participate in authentication and authorization flows. For NHI governance, computer accounts are not low-value objects by default, because many of them anchor privileged infrastructure and should be treated as sensitive identities.
• Not Delegable: A state in which a Kerberos identity cannot be used in on-behalf-of delegation flows. For machine identities, this control matters because the absence of a visible UI checkbox does not mean the protection is unavailable; it must still be applied where the account is sensitive.
• Tier 0 Identity: An identity that can directly control trust, authentication, or directory authority within the enterprise. For computer accounts, this typically includes domain controllers, PKI servers, federation bridges, and other machines whose compromise or delegation would collapse the security boundary for the rest of the environment.

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 building or maturing an IAM programme, it is worth exploring.