Unconstrained delegation increases lateral movement risk because a compromised server can reuse Kerberos ticketing material to impersonate users who authenticate to it. An attacker does not need to steal passwords from scratch if they can capture a ticket already trusted by the domain. That turns one host compromise into a broader identity abuse path.
Why This Matters for Security Teams
Unconstrained delegation turns a single server compromise into an identity abuse opportunity because the host is allowed to act on behalf of authenticated users. That matters most in environments where Kerberos trust is broad, service accounts are over-privileged, and lateral movement is still a realistic attacker objective. The issue is not just credential theft. It is the reuse of trusted ticketing material to reach adjacent systems without triggering the same alarms as password capture. That pattern appears repeatedly in the broader NHI problem set described in Top 10 NHI Issues and in the 52 NHI Breaches Analysis.
From a control perspective, this is a classic example of why NIST Cybersecurity Framework 2.0 stresses access governance, monitoring, and containment together rather than as separate tasks. If delegation is unconstrained, the server becomes a trust amplifier instead of a bounded workload. In practice, many security teams discover this only after one application server has already become the fastest route into tiered infrastructure, rather than through intentional design review.
How It Works in Practice
With unconstrained delegation, a service that receives Kerberos-authenticated traffic can obtain forwardable tickets and reuse them to access other resources on the user’s behalf. If an attacker controls that service, they may capture ticket-granting material or impersonation artifacts and then pivot to file servers, management interfaces, or other internal workloads. The practical failure is not the protocol itself. It is the trust boundary: the server is treated as broadly trustworthy even when its application function does not require that level of reach.
Security teams reduce this risk by shrinking where delegation is allowed, moving toward constrained delegation or alternatives that bind access to a narrower service purpose. Current guidance suggests pairing that with strong monitoring for anomalous service ticket use, privileged session creation, and unexpected authentication flows. This is also where OWASP NHI Top 10 is useful: it frames identity abuse as an operational design issue, not just a configuration mistake. For implementation discipline, NIST Cybersecurity Framework 2.0 reinforces asset visibility, protective access controls, and continuous detection.
- Limit delegation to the smallest possible set of services and accounts.
- Remove unconstrained delegation wherever the business does not require it.
- Monitor for unusual ticket forwarding, especially from servers that should not broker broad access.
- Pair identity controls with host hardening, because a compromised service account is only one part of the attack path.
These controls tend to break down in legacy Windows estates where applications depend on older authentication flows and administrators are reluctant to change service bindings.
Common Variations and Edge Cases
Tighter delegation control often increases application and operations overhead, requiring organisations to balance reduced lateral movement against compatibility and admin effort. That tradeoff is especially visible in mixed environments where some services still rely on legacy Kerberos patterns, vendor appliances, or brittle authentication chains. There is no universal standard for this yet across every enterprise stack, so best practice is evolving toward narrower trust rather than assuming a one-size-fits-all migration path.
One common edge case is a business application that appears harmless but runs under a service account with broad directory or database reach. Another is environments that combine Windows identity infrastructure with cloud-connected workloads, where ticket abuse may be only one step in a larger compromise chain. In those settings, the lesson from Ultimate Guide to NHIs — Key Challenges and Risks and Ultimate Guide to NHIs — Why NHI Security Matters Now is simple: any identity that can impersonate widely must be treated as high impact, even if it is not a human user. That is why mature teams combine delegation restrictions, PAM, and periodic review of service trust paths instead of relying on static assumptions about “internal” systems.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0 and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-03 | Delegation risk comes from over-privileged, reusable identity material. |
| NIST CSF 2.0 | PR.AC-4 | Access control scope is central to limiting ticket reuse and lateral movement. |
| NIST AI RMF | AI risk governance helps frame broad identity trust as an organisational risk. |
Reduce broad trust by constraining service identity scope and rotating sensitive credentials.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on May 27, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
