Unconstrained delegation lets a server store a user’s ticket-granting ticket in memory and reuse it later. If a privileged account authenticates to that host, the server can impersonate that user to other services in the domain. That turns one compromised application server into a broad impersonation point, which is why it should be avoided wherever possible.
Why unconstrained delegation breaks trust boundaries
Unconstrained kerberos delegation breaks the assumption that an application server should only act within a narrowly defined trust boundary. Once the host can cache and later reuse a user’s ticket-granting ticket, the server is no longer just a requester of downstream access, it becomes a reusable impersonation point. That turns server compromise into domain-wide identity abuse rather than a single-host event.
The practical failure is trust expansion. Any privileged session that touches the server can be captured in a form that lets the host request additional service tickets on behalf of that user. If the server is not fully trusted infrastructure, the delegation boundary is wider than the actual security boundary.
This is also why “works technically” is not the same as “safe operationally”. The feature can make legacy application patterns easier, but it removes the containment that Kerberos is supposed to preserve when a tier is compromised or misused.
What changes once the application server is compromised
With unconstrained delegation, compromise of the application server is not limited to the server’s own account or workload. The attacker inherits the host’s ability to present cached delegated credentials and can impersonate any high-value user whose session reached the server. In effect, the application server becomes a bridge from ordinary application access into lateral movement and privileged access elsewhere in the domain.
The blast radius depends on who authenticates to that server. If only low-value users ever reach it, the damage may stay narrower. If administrators, operators, service owners, or other privileged principals authenticate there, the host can become a launch point for broader domain takeover activities.
The core issue is not just access, but reuse of delegated authority. A single server should not be able to replay a privileged user’s trust across multiple services unless that trust has been deliberately constrained and monitored.
Why restriction to trusted infrastructure matters
Restricting delegation to trusted infrastructure preserves the intended separation between application tier and sensitive identity-bearing sessions. It limits which hosts are allowed to handle delegated tickets, reduces the number of systems that can become impersonation points, and keeps the highest-value credentials away from general-purpose application servers.
That restriction matters most where host hygiene, patch discipline, or workload isolation is imperfect. A carefully managed tier can be made suitable for delegation if it is hardened, monitored, and tightly scoped. A broad class of application servers usually cannot meet that standard consistently, especially when ownership, patching, and privilege boundaries are diffuse.
In practice, the control is about minimizing the number of places where delegated trust can be harvested and reused. Fewer trusted hosts means less opportunity for ticket theft, less exposure if one host is compromised, and less ambiguity about where privileged impersonation is allowed to occur.
Risk and Threat Considerations
Leaving unconstrained delegation enabled creates a high-value compromise path because a single server can become an identity replay point for privileged users. The risk is greatest when administrators, service operators, or other sensitive accounts authenticate to that server, because the server can then be abused to impersonate them to downstream services.
Failure mechanism: A compromised or misused application server can capture delegated Kerberos material and reuse it to request service access as the original user, turning one foothold into a broader impersonation and lateral movement capability.
Impact: Attackers may pivot from a normal application tier into privileged domain access, expanding blast radius, undermining trust boundaries, and increasing the likelihood of domain-wide compromise.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 and NIST CSF 2.0 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-9 — Identification and Authentication (Non-Organizational Users) | Delegated Kerberos trust for application servers is an authentication and impersonation control problem. |
| AC-6 — Least Privilege | Unconstrained delegation expands host power beyond least-privilege boundaries. | |
| IA-5 — Authenticator Management | Delegation depends on protecting reusable credential material and ticket handling. | |
| Recommendation — Restrict delegated authentication to trusted hosts and prevent broad impersonation paths. Limit each server to only the downstream access it actually needs. Protect and rotate credential material that can be reused for downstream impersonation. | ||
| ISO/IEC 27001:2022 | A.8.5 — Secure authentication | Kerberos delegation is an authentication trust decision that should be tightly constrained. |
| A.8.2 — Privileged access rights | Unconstrained delegation can magnify privileged access on application servers. | |
| Recommendation — Constrain authentication trust so application servers cannot impersonate users broadly. Restrict privileged access paths on hosts that can act on behalf of users. | ||
| NIST CSF 2.0 | PR.AA-05 — Identity and access credentials | Delegation control limits how credentials and derived access are reused across services. |
| Recommendation — Bound credential use to the minimum set of trusted systems. | ||
Practitioner Guidance
What to verify: Confirm that delegation is limited to hosts that are explicitly trusted, hardened, and monitored, and that no general application server can accept privileged interactive sessions by default. If a server does not need to present user context to downstream systems, it should not be allowed to hold that trust.
Decision rule: If the server can be reached by privileged users and the business case for unconstrained delegation is not exceptional, treat the configuration as an exposure that should be redesigned rather than accepted as a routine exception.
Practitioner takeaway: The important judgement is not whether delegation is convenient, it is whether the host is trustworthy enough to become an impersonation boundary; if not, restrict it aggressively and assume compromise of that server is an identity compromise event.
Related resources from NHI Mgmt Group
- What breaks when a PAM tool is built for static servers instead of modern infrastructure?
- What breaks when microsegmentation is based on infrastructure instead of application intent?
- What breaks when audit events are generated only on the endpoint instead of from trusted infrastructure?
- Why is OAuth considered a better alternative for MCP servers?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 25, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
