TGT delegation is the ability to use a Kerberos Ticket Granting Ticket on behalf of another account. It lets a service present delegated credentials to obtain service tickets for downstream systems, so the original user or service can be impersonated within the Kerberos trust chain.
How TGT Delegation Works in Kerberos
TGT delegation is a Kerberos trust extension, not a separate authentication system. A service that receives delegated Kerberos material can request downstream service tickets on the user's behalf, which preserves the Kerberos flow while expanding the set of systems that can be reached under that identity.
Because the Ticket Granting Ticket is the reusable root of the Kerberos session, delegation changes where trust is enforced. The downstream service is no longer acting only for itself, it is acting with a delegated context that may carry the original user's authority into other parts of the environment.
Where Delegation Fits in the Kerberos Trust Chain
TGT delegation sits between initial logon and later service access. It is most relevant when one service must call another service as the user, such as middleware, front-end to back-end application tiers, or cross-system workflows that need end-to-end user context.
The important design point is that delegation preserves the user's identity across hops, but it also extends the blast radius of that identity. If the delegated path is too broad, the service can become a conduit for actions the original user never directly initiated.
In practice, delegation only stays safe when the trust boundary is well understood. A delegated Kerberos path should be treated as a privileged access path, because it can let one compromised service impersonate users to other services inside the Kerberos realm.
Security Implications of TGT Delegation
The main security concern is impersonation. If a delegated ticket is abused, stolen, or forwarded beyond its intended scope, an attacker can pivot from a trusted service into additional systems while appearing to act as a legitimate user.
That makes delegation especially sensitive in environments with broad trust relationships, cross-domain access, or services that are allowed to request many downstream tickets. Strong scoping and trust separation matter because delegation mistakes often become lateral movement opportunities rather than isolated authentication failures.
Operationally, delegated Kerberos flows also complicate logging and incident investigation. Security teams may see activity that looks valid at the protocol level but still reflects unauthorized use of delegated authority or a service abusing a user context.
How to Evaluate and Control Delegation Paths
Organisations should identify every service allowed to accept or forward delegated Kerberos credentials, then confirm that each one truly needs that capability. Trust relationships, service account design, and cross-realm permissions should be reviewed together, because delegation often depends on configuration choices across multiple systems.
For domain and forest trust environments, Active Directory Trusts and SID Filtering Guide is useful because it explains how trust boundaries and filtering controls shape what delegated identities can do across trusts.
Where delegation reaches across protocol boundaries or non-Kerberos services, teams should also check whether the underlying application flow can be simplified so the delegated identity is not carried farther than necessary. The safest design is the one that limits where impersonation is possible in the first place.
Risk and Threat Considerations
TGT delegation creates a concentrated impersonation risk because one trusted service can act as a proxy for another identity across multiple downstream systems. If that service is compromised, the attacker may inherit the delegated ability to access data or functions that were never directly exposed to the original endpoint.
Failure mechanism: Weak trust scoping, overbroad delegation rights, or compromised delegated credentials let an attacker reuse the Kerberos trust chain to impersonate a user or service beyond the intended boundary.
Impact: The result can be lateral movement, unauthorized service access, privilege abuse, and difficult-to-detect activity that still appears authenticated within Kerberos.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack and risk surface, while NIST SP 800-53 Rev 5 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | Delegation expands effective access, so least privilege governs delegated authority. |
| IA-2 — Identification and Authentication (Organizational Users) | Kerberos delegation preserves user authentication context across service hops. | |
| Recommendation — Restrict delegated Kerberos paths to the minimum systems and actions required. Validate that delegated access still traces back to a strongly authenticated user. | ||
| MITRE ATT&CK | T1134.001 — Access Token Manipulation: Token Impersonation/Theft | Delegation abuse can let attackers impersonate a user through reused auth material. |
| Recommendation — Detect and investigate impersonation paths that reuse delegated Kerberos credentials. | ||
| NIST Zero Trust (SP 800-207) | Zero Trust Architecture | Delegation is a trust-boundary problem that Zero Trust treats as continuously verified access. |
| Recommendation — Apply continuous verification to every service-to-service delegation path. | ||
Practitioner Guidance
Why practitioners should care: TGT delegation is one of those Kerberos features that is operationally useful but easy to overextend. If it exists only to support a narrow application flow, keep that flow tightly documented and explicitly owned, because unclear delegation paths are a common source of access sprawl.
Common misunderstanding: Teams sometimes treat delegated Kerberos activity as automatically safe because it uses valid protocol mechanics. In reality, validity is not the same as intended use, and a perfectly legitimate delegation path can still be the wrong path for a given workload or trust boundary.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on November 9, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org