Why does Kerberos delegation create such a large risk in Active Directory?

Why This Matters for Security Teams

Kerberos delegation is risky because it turns an application into a trust proxy. In active directory, that proxy can request service access on behalf of a user, which means the security boundary is no longer the user alone. If an attacker compromises the delegated service, the abuse path can extend into privileged workloads, lateral movement, and token theft. That makes delegation a high-value target for both misconfiguration and post-exploitation tradecraft.

This is not a theoretical concern. NHI Management Group’s Ultimate Guide to NHIs — Key Challenges and Risks notes that 97% of NHIs carry excessive privileges, which helps explain why delegated service accounts become such effective escalation points. The operating pattern also aligns with NIST Cybersecurity Framework 2.0 guidance on reducing exposure by tightening access pathways and continuously managing identity risk. In practice, many security teams encounter delegation abuse only after a service account has already been used to impersonate a more privileged identity, rather than through intentional review of trust paths.

How It Works in Practice

Kerberos delegation exists because some services must act on behalf of users without requiring the user to re-authenticate at every hop. That convenience becomes dangerous when delegation is broad, persistent, or poorly constrained. The core issue is that the delegated service is not just authenticated, it is trusted to obtain tickets or assertions that can impersonate the user to downstream systems.

Security teams should evaluate delegation by asking three questions: who can delegate, to which services, and under what scope. In practice, the risk increases when unconstrained delegation is enabled, when sensitive accounts are permitted into delegated flows, or when service principals can be altered by operators who do not fully understand the trust chain. The attack surface is especially severe when attackers combine delegation with credential theft, because a delegated service often has enough context to access file shares, databases, management interfaces, or directory services.

• Use the least permissive delegation model available, and avoid unconstrained delegation unless there is a documented exception.
• Restrict which accounts can be delegated, especially privileged users and administrator-equivalent identities.
• Audit service principals, SPNs, and delegation settings as part of identity change management.
• Monitor for unusual ticketing patterns, especially lateral service access that does not match the application’s normal behavior.

For teams building a broader identity program, the Top 10 NHI Issues resource is useful because delegation is rarely an isolated problem. It often overlaps with overprivileged service accounts, weak secret hygiene, and poor offboarding. The practical takeaway is that Kerberos delegation should be treated as a high-impact identity control, not a convenience feature. These controls tend to break down in legacy Active Directory environments where business applications depend on unconstrained delegation and no one has mapped the downstream trust chain.

Common Variations and Edge Cases

Tighter delegation controls often increase application complexity, requiring organisations to balance security hardening against legacy compatibility. That tradeoff is real, especially in environments where older line-of-business systems depend on protocol transitions or multi-tier impersonation that cannot be quickly redesigned.

There is no universal standard for every edge case, but current guidance suggests treating each delegation type according to its blast radius. Constrained delegation is generally preferable to unconstrained delegation, while protocol transition mechanisms require extra scrutiny because they can expand who is able to obtain usable tickets. Another common failure mode is assuming that a low-privilege front-end service is harmless; if that service can delegate to sensitive back-end systems, compromise of the front end can become a directory-wide problem.

Security teams should also distinguish between technical permission and business need. Some services require delegation for user experience, but that does not justify permitting privileged targets or wide service reach. The better pattern is to document explicit delegation targets, rotate and protect service credentials, and review those settings whenever an application is changed, repointed, or retired. The Cisco Active Directory credentials breach research is a reminder that identity compromise often starts with one credential path and expands through trust relationships that were never meant to be broad. In mixed AD and cloud environments, delegation risk also grows when service identities are reused across platforms because the trust boundary becomes harder to see.

Related resources from NHI Mgmt Group

• Why do service accounts and delegation settings create so much risk in Active Directory?
• Why do AI agents create new risk in non-human identity management?
• Why do collaboration tools create such a large secrets risk?
• When does AI agent access create more risk than it reduces?