Kerberos delegation risk extends to machine accounts in Active Directory

At a glance

What this is: This is a technical analysis of Kerberos delegation in Active Directory, showing that computer accounts can be delegated on behalf of and abused to escalate from weak access to domain admin-level control.

Why it matters: It matters because IAM and PAM teams often harden users but leave sensitive machine identities exposed, creating a blind spot in Tier 0 governance, delegation controls, and NHI lifecycle management.

By the numbers:

• When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes and as quickly as 9 minutes in some cases.
• 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems, inappropriately sharing sensitive data, and revealing access credentials.

👉 Read Silverfort's research on Kerberos delegation abuse and machine-account escalation

Context

Kerberos delegation in Active Directory is a control-plane mechanism that lets a service act on behalf of another identity when it needs to reach a downstream system. The problem in this article is that the familiar delegation risk model is too narrow: many programmes treat it as a user-only issue and miss that computer accounts can also be delegated, including Tier 0 machine identities.

That gap matters because privileged machine accounts often sit at the centre of identity infrastructure, PKI, AD CS, and hybrid management planes. If those identities remain delegable, the organisation has effectively left a path open from one compromised service tier into the core of the domain, even when user hardening looks complete.

Silverfort’s analysis is especially relevant for teams that already believe they have addressed delegation through user-object settings. The article shows that the real control problem is visibility and enforcement across machine accounts, not just awareness of sensitive users.

Key questions

Q: How should security teams govern Kerberos delegation for machine accounts?

A: Security teams should govern machine-account delegation the same way they govern privileged user delegation, by treating Tier 0 computers as sensitive identities that must not be representable across tiers unless there is a documented business need. The control must be verified at the directory attribute level, because console visibility is incomplete and can hide the real exposure.

Q: Why do privileged computer accounts create more risk than ordinary service accounts?

A: Privileged computer accounts create more risk because they often sit inside identity infrastructure, PKI, or hybrid control planes, where delegated access can become domain-wide authority. If a compromised service can act on behalf of those machines, the attacker is no longer just reaching an application. They are reaching the identity plane itself.

Q: What breaks when machine accounts are not marked as not delegable?

A: What breaks is the assumption that only users need delegation protection. If sensitive machine accounts remain delegable, downstream services can request tickets or act on behalf of identities that should never be represented, which can open a route to certificate abuse, DCSync-style access, and domain compromise.

Q: Who is accountable when delegated access to a Tier 0 machine account causes compromise?

A: Accountability sits with the teams that own directory governance, Tier 0 hardening, and identity infrastructure, because delegation is an architectural trust decision rather than a single-service setting. If the organisation allows machine identities with control-plane authority to be delegable, that is a governance failure, not just an operational mistake.

Technical breakdown

Kerberos constrained delegation and the S4U path

Kerberos delegation lets a front-end service request access on behalf of another identity so downstream authorization can occur in the caller’s context. In constrained delegation, that behaviour is limited by policy, but it still creates a powerful trust bridge between tiers. The S4U family of extensions is the technical mechanism that makes this possible, and it is precisely why delegation becomes dangerous when a service can act for identities that were never meant to be represented across tiers. When the delegated target is a privileged machine account, the impact is no longer just user impersonation. It becomes identity-plane abuse with domain-wide consequences.

Practical implication: treat delegation paths as privileged identity dependencies and inventory every service allowed to represent machine accounts.

Why the ADUC console hides the machine-account control

Active Directory Users and Computers exposes the “Account is sensitive and cannot be delegated” option for users, but not for computer objects. That creates a governance blind spot, because the underlying protection still exists in userAccountControl as ADS_UF_NOT_DELEGATED and can be set on machine accounts with PowerShell. The UI gap is the problem here, not the absence of a control. Administrators who rely on console visibility can mistakenly conclude that machine identities are unprotected by design, when the real issue is that the control is simply not surfaced in the day-to-day workflow.

Practical implication: verify machine-account delegation settings through directory attributes and scripts, not just through the GUI.

How delegation becomes privilege escalation in a domain controller path

The article’s attack chain combines certificate enrollment with Kerberos delegation abuse. A request can be coerced toward a more privileged certificate template, and the delegation flow can then be abused so a weak user identity effectively reaches a domain controller context. Once a DomainController-class certificate is obtained, the attacker can move toward DCSync and domain dominance. The technical lesson is that delegation, certificate services, and machine identity authority can compound into a single escalation path when trust boundaries are assumed rather than enforced.

Practical implication: review delegation plus AD CS exposure together, because the combined path can be more dangerous than either component alone.

Threat narrative

Attacker objective: The attacker wants to convert a low-privilege foothold into domain-level control by abusing machine-account delegation and certificate authority trust.

1. Entry occurs through a weak user identity interacting with a web enrollment path that accepts a privileged certificate template request.
2. Credential access and abuse happen when the delegation flow is manipulated so the service acts on behalf of a machine account with higher authority.
3. Impact follows when the attacker obtains domain-controller-level capability and can pursue DCSync-style domain compromise.

Breaches seen in the wild

• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.
• Cisco Active Directory credentials breach — Kraken ransomware group leaked Cisco Active Directory credentials.

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 a machine-identity governance problem, not a user-only issue. The article’s central correction is that Active Directory delegation applies to computer objects as well as users, which means sensitive NHIs can be represented across tiers unless they are explicitly constrained. That changes the control conversation from protecting a class of users to governing every identity that can participate in delegated authorization. Practitioners should treat machine accounts in Tier 0 as first-class subjects of delegation policy.

Hidden console controls create an identity governance blind spot. The “Account is sensitive and cannot be delegated” checkbox is visible for users but not for computers, which means many programmes will miss the control if they rely on the UI alone. The underlying NOT_DELEGATED bit exists for both object types, so the failure mode is governance visibility, not technical impossibility. The implication is that machine-account delegation must be validated as a directory attribute, not assumed from administrative tooling.

Least privilege for machine identities breaks when delegation is broad enough to cross trust tiers. A service trusted for delegation can inherit authority into certificate services, identity infrastructure, and domain-controller paths, which turns one exposed control into a domain-compromise vector. This is why NHI governance cannot stop at secret hygiene or service-account inventory. Practitioners need to rethink how delegated trust is approved when the target identity itself is part of the identity plane.

Tier 0 machine accounts should be treated as delegable until proven otherwise. The article shows that domain controllers, PKI systems, AD CS enrollment tiers, and hybrid identity bridge servers are all sensitive because they control identity. If those machines remain delegable, the environment is preserving an escalation route that bypasses user-centric hardening assumptions. The practitioner conclusion is straightforward: delegation governance must be anchored to identity authority, not object type labels.

The named concept here is delegated machine identity exposure. This is the condition where machine accounts that hold identity-plane authority are still eligible to be represented by other services. It matters because the security model assumes the identity being delegated is low risk, but Tier 0 machine accounts invalidate that assumption. Practitioners should recognise this as a governance failure mode, not just a configuration error.

From our research:

• 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems, inappropriately sharing sensitive data, and revealing access credentials, according to AI Agents: The New Attack Surface report.
• Only 52% of companies can track and audit the data their AI agents access, leaving 48% with a complete blind spot for compliance and breach investigation, according to AI Agents: The New Attack Surface report.
• That gap points to the next control problem: organisations need identity observability across machine and autonomous actors, not just inventory, as explored in The 52 NHI breaches Report.

What this signals

Delegated machine identity exposure is the broader pattern this article exposes, and it will matter more as identity infrastructure becomes more distributed across hybrid and cloud-connected control planes. Teams that still separate user hardening from machine-account governance will keep missing the path where delegation becomes escalation, especially in PKI and domain-controller workflows.

The immediate programme signal is that GUI-driven review is not enough for Tier 0. Directory attributes, delegation lists, and certificate-service relationships need to be reviewed together, because the attack path is created by their interaction rather than by any one control in isolation.

As machine identities continue to carry more authority, the practical boundary between IAM, PAM, and NHI governance keeps narrowing. Organisations that build a single view of delegated trust across user and machine accounts will be able to spot this class of exposure earlier than teams that still manage them as separate problems.

For practitioners

• Inventory delegated machine identities Enumerate every computer account that appears in msDS-AllowedToDelegateTo or related delegation settings, then classify whether it sits in Tier 0, PKI, or hybrid identity infrastructure. Prioritise domain controllers, AD CS tiers, and bridge servers because they carry the highest escalation value.
• Set the NOT_DELEGATED bit on sensitive computers Use Set-ADAccountControl with -AccountNotDelegated $true for machine identities that should never be represented across tiers. Validate the change through directory attributes so the control is enforced even when the GUI does not expose it.
• Review certificate services and delegation together Audit AD CS web enrollment, constrained delegation, and privileged template exposure as a single control surface. The article shows that certificate abuse and delegation abuse can combine into one escalation path, so separate reviews leave gaps in the attack chain.
• Test for legitimate services that depend on delegating to Tier 0 machines After hardening, observe which applications fail and determine whether any of them were legitimately delegating on behalf of a domain controller or other privileged machine. A dependency on that behaviour is itself a finding that should be escalated to identity governance owners.

Key takeaways

• Kerberos delegation is not a user-only issue, and machine accounts with Tier 0 authority can become a direct path to domain compromise.
• The evidence in this article shows that the control exists but is hidden from the usual UI workflow, which makes governance visibility the real failure mode.
• The limiting control is explicit non-delegation for sensitive computers, backed by attribute-level verification and a joint review of delegation plus AD CS exposure.

Key terms

• Kerberos Delegation: A Kerberos feature that allows one service to obtain access on behalf of another identity so downstream systems can authorise the call in the original caller’s context. In practice, it expands the trust boundary across tiers and can become a privilege escalation path if the delegated target is sensitive.
• Computer Account Delegation: The ability for a machine identity to be represented by another service during authentication or authorisation flows. It is often overlooked because administrators focus on user accounts, but the underlying directory controls apply to computer objects as well, making Tier 0 machines especially important to govern.
• Tier 0 Machine Identity: A non-human identity that sits inside the most sensitive identity infrastructure, such as domain controllers, PKI systems, AD CS tiers, or hybrid identity bridges. These accounts are high value because compromise or delegation abuse can affect the control plane rather than a single application.
• Not Delegated Flag: A directory attribute that prevents an identity from being used in delegation flows. For machine accounts, it exists even when the administration console does not surface the checkbox, so validation must be performed directly against the object attributes rather than through the UI alone.

Deepen your knowledge

NHI governance, agentic AI identity, machine identity security, and secrets management are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an identity security programme, it is worth exploring.

This post draws on content published by Silverfort: Kerberos delegation vulnerability research showing that machine accounts can be abused for elevation of privilege. Read the original.