Kerberos Constrained Delegation lets a service account or application obtain Kerberos tickets on behalf of a user, but only to specific downstream services. This limits delegated access in Windows environments, reducing lateral movement risk while still enabling multi-tier applications to act for authenticated users without sharing the user’s password.
What KCD is used for
Kerberos constrained delegation is a Windows delegation control for multi-tier applications. It lets a service present a user’s identity to selected downstream services without exposing the user’s password or allowing unrestricted onward delegation.
That makes KCD useful when an application must act on behalf of an authenticated user, but the delegation scope needs to stay tightly bounded. It is a control over where trusted service identity can be used, not a general-purpose permission to impersonate users everywhere.
How KCD changes the Windows trust model
KCD narrows the blast radius of delegated authentication by limiting which services may receive tickets on behalf of the user. In practice, that changes a broad “can act as the user” pattern into a specific “can act as the user only to these services” pattern.
That distinction matters in Windows environments because delegation mistakes can turn a single compromised service into a stepping stone across tiers. NHIMG’s Kerberos Delegation Security Guide covers the difference between constrained delegation, unconstrained delegation, and resource-based constrained delegation, which is the context practitioners need when they decide how trust should be bounded.
Where KCD fits in authentication flows
KCD is part of the Kerberos authentication path, so it depends on ticket handling, service trust, and directory configuration rather than passwords being forwarded through the application. The design is especially relevant for double-hop scenarios, web-to-database access, and other service chains where the backend needs user context.
Because the service receives delegated access to specific downstream services, the security outcome depends on correct service registration and on the principle that only the intended backend services are trusted. If the allowed service list is too broad, the control stops being constrained in practice.
For a broader reference point on Kerberos behavior and attack paths around tickets, NHIMG’s Kerberos Security Guide is the better companion resource, especially where constrained delegation must be understood alongside ticket abuse, detection, and KRBTGT-related compromise patterns.
Why KCD is valuable and where it fails
KCD reduces credential exposure because services do not need to store or reuse the user’s password to reach downstream systems. It also limits lateral movement by preventing the service from delegating freely to arbitrary services.
Its protection is only as strong as the trust boundary around the delegated service. If a service account is compromised, an attacker can often use that delegated trust to reach the specific services allowed by policy, so the control reduces exposure but does not eliminate the impact of service compromise.
The external delegation model is also relevant here. RFC 8693: OAuth 2.0 Token Exchange is not Kerberos, but it is a useful comparison point for on-behalf-of flows because it formalises token exchange and delegation boundaries in modern identity systems.
Risk and Threat Considerations
KCD lowers delegation risk, but it also creates a high-value trust path: if a delegated service is compromised, the attacker may inherit user-context access to the specific downstream services that KCD permits. Mis-scoped delegation, overprivileged service accounts, and poor monitoring can turn a defensive control into a controlled but still damaging path for lateral movement.
Failure mechanism: An attacker compromises the service or its credentials, then uses the legitimate delegated trust path to obtain tickets or access only the downstream services permitted by KCD, which can hide abuse inside normal Kerberos activity.
Impact: The compromise can expose backend data, elevate effective access within the application tier, and make post-compromise movement harder to distinguish from legitimate delegated use.
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, NIST Zero Trust (SP 800-207) and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-9 — Service Identification and Authentication | KCD governs service-to-service authenticated delegation |
| AC-6 — Least Privilege | KCD should limit delegated authority to the minimum required services | |
| Recommendation — Restrict service delegation paths to approved downstream services. Minimize delegated access so services can reach only required resources. | ||
| NIST Zero Trust (SP 800-207) | Least privilege and explicit trust verification | KCD is an explicit trust-boundary control for service access |
| Recommendation — Verify delegated trust boundaries before allowing service-to-service access. | ||
| CIS Controls v8 | 5 — Account Management | Delegated service accounts must be governed and reviewed |
| Recommendation — Review and remove unnecessary delegated account access paths. | ||
Practitioner Guidance
Why practitioners should care: KCD is only effective when the set of downstream services is deliberately small and well understood. If the trust list grows casually, the control still exists on paper but loses much of its security value.
What to watch for: Review delegated service mappings, service account ownership, and any application change that adds new backend dependencies. KCD should be treated as a trust boundary decision, not just an enablement setting for application developers.
Practitioner takeaway: Use KCD to enable double-hop access only where the downstream services are explicitly justified, tightly scoped, and continuously reviewed.
Related resources from NHI Mgmt Group
- Why does constrained Kerberos delegation reduce risk compared with unconstrained delegation in Active Directory environments?
- How does Kerberos constrained delegation work with Microsoft Entra ID?
- What is the difference between unconstrained and constrained delegation?
- How should security teams govern Kerberos delegation for machine accounts?