Who is accountable when a Kerberos delegation flaw leads to domain compromise?

Why This Matters for Security Teams

kerberos delegation flaws are not just an Active Directory misconfiguration problem. They create a trust shortcut that can let one compromised account impersonate others, pivot across services, and ultimately expose domain-level control. When that happens, accountability extends beyond the identity team to patching owners, AD administrators, application teams, and detection engineers who failed to spot the abuse path. The lesson is similar to what NHI Management Group highlights in its 52 NHI Breaches Analysis: attackers routinely exploit dormant trust relationships, not just weak passwords.

This is why “who owns the account” is the wrong first question. The better question is who owns the delegated trust boundary, who can revoke it, and who verifies that it is still justified. A flaw in constrained or unconstrained delegation can become a domain compromise because the authorization model assumes trusted service behavior that does not hold once an attacker gets a foothold. For broader identity context, NHI Management Group’s Ultimate Guide to NHIs explains why hidden machine trust is often more dangerous than human account sprawl. In practice, many security teams discover delegation abuse only after credential theft has already become lateral movement and domain takeover.

How It Works in Practice

Kerberos delegation lets one service act on behalf of a user to reach downstream resources. That is useful in enterprise applications, but dangerous when delegation is too broad, poorly inventoried, or left enabled after the original business need disappears. If an attacker compromises a delegated service account, they may request service tickets, impersonate users, and move into high-value systems without needing to break encryption or guess passwords.

From an operational standpoint, accountability should be assigned across three layers. First, identity governance owns the delegation inventory and approval process. Second, infrastructure or AD teams own configuration, patching, and hardening of delegation settings. Third, application owners must justify why delegation exists and confirm that the business workflow still requires it. That distribution matches current guidance from Microsoft on Kerberos delegation hardening and aligns with incident patterns described in the 52 NHI Breaches Analysis, where trust was abused after it had been granted.

In practice, effective control usually includes:

• Inventory all accounts and services with unconstrained, constrained, or resource-based delegation.
• Replace broad delegation with the narrowest viable trust path, or remove it entirely where possible.
• Monitor Kerberos ticket activity for unusual impersonation patterns, especially service-to-service jumps.
• Rotate or disable delegated service accounts quickly when an application is retired or repurposed.
• Correlate AD changes with alerting so delegation edits are visible before they are abused.

The real accountability trigger is not the moment the flaw is disclosed, but the point at which the organisation fails to catalogue and retire unnecessary delegation paths. These controls tend to break down in large hybrid AD environments where legacy applications still depend on broad impersonation rights because the business cannot easily disentangle ownership.

Common Variations and Edge Cases

Tighter delegation control often increases operational overhead, requiring organisations to balance application continuity against privilege reduction. That tradeoff is especially visible in legacy environments, where business-critical services were built around unconstrained delegation long before modern zero trust expectations existed. Best practice is evolving, but there is no universal standard for every AD topology.

Some edge cases change the accountability picture. If resource-based constrained delegation is used correctly, responsibility may sit more heavily with the application or platform team that requested the trust, because the target resource defines the delegation boundary. In cloud-connected estates, federated identity and service accounts can blur lines further, so security ownership must include the dependency map, not just the directory itself. NHI Management Group’s DeepSeek breach coverage and Anthropic’s report on an AI-orchestrated cyber espionage campaign both reinforce a common pattern: once attackers control a trusted identity, they often chain that access in ways defenders did not anticipate.

For that reason, accountability should be documented before an incident, not argued after one. The practical answer is shared responsibility with named owners for inventory, remediation, detection, and business justification, because no single team can safely own a domain trust relationship in isolation.

Related resources from NHI Mgmt Group

• Who is accountable when a template engine flaw leads to host compromise?
• Who is accountable when a framework flaw leads to cloud compromise?
• Who is accountable when a rendering flaw leads to cluster compromise?
• Who should be accountable when certificate abuse leads to domain compromise?