Constrained delegation limits an account to specific downstream services, so a compromise does not automatically open access across the domain. It narrows the blast radius by binding delegation to a defined set of service principals. The model still needs careful protection, because stolen credentials or hashes can still be abused to request tickets on behalf of users.
Why the delegation boundary changes the blast radius
unconstrained delegation turns the delegated service into a high-value trust sink, because any user or service ticket presented to that host can be forwarded more broadly than the original request intended. Constrained Kerberos delegation narrows that trust boundary by allowing delegation only to explicitly approved downstream services, so compromise of the delegating account or host does not automatically become domain-wide impersonation.
That difference matters most in environments where service accounts, application tiers, or legacy Windows components still rely on Kerberos delegation for integrated authentication. The tighter the permitted service list, the easier it is to reason about who can impersonate whom and where a stolen ticket can actually go.
What constrained delegation still permits, and what it blocks
Constrained delegation does not remove delegation risk, it scopes it. If an attacker steals the credentials or hashes for a delegating account, they may still request service tickets on behalf of users to the approved services. What they lose is the ability to pivot freely across unrelated back-end systems simply because delegation was enabled.
That makes the control especially valuable where the real security objective is to preserve a functional on-behalf-of flow without granting a broad impersonation capability. The control is strongest when the approved service principals are few, stable, and reviewed as part of account and service ownership rather than left as an inherited configuration.
In practice, the security gain comes from reducing the number of places where a compromised delegation path can be reused. This is also why delegation should be treated as a privilege decision, not just an application setting, because the effective reach of the account determines the blast radius after compromise.
Why Active Directory operators prefer the constrained model
active directory operators choose constrained delegation because it aligns the technical trust path with the minimum set of downstream services the application genuinely needs. That gives defenders a cleaner boundary for review, audit, and incident containment, especially when compared with unconstrained delegation, which assumes the host can act as a much broader proxy for user credentials.
It also improves change control. When a service needs a new target, the delegation list must change explicitly, which creates a review point that unconstrained delegation never provides. That is useful in environments where service sprawl and forgotten trust relationships are common failure modes.
For teams managing the identity lifecycle, constrained delegation is easiest to sustain when tied to ownership, documentation, and periodic recertification. NHIMG’s NHI Lifecycle Management Guide is a useful companion for thinking about provisioning, review, and offboarding of privileged service identities, while Cisco Active Directory credentials breach is a reminder that credential compromise in AD environments can quickly become lateral movement when trust boundaries are too broad.
Risk and Threat Considerations
The main risk with unconstrained delegation is that a single compromised service can become a general impersonation path across the directory. Attackers value that because it converts one foothold into broad ticket abuse, lateral movement, and easier access to protected resources.
Failure mechanism: A host configured for unconstrained delegation can receive and forward Kerberos credentials beyond the intended downstream scope, so compromise of that host or account can expose multiple services and users.
Impact: The attacker gains a larger impersonation surface, making privilege escalation, lateral movement, and persistence materially easier than in a tightly scoped delegation design.
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, NIST CSF 2.0 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 Authentication | Kerberos delegation is a service-to-service authentication and impersonation control issue. |
| AC-6 — Least Privilege | Constrained delegation reduces the privilege available to a compromised service account. | |
| Recommendation — Restrict service authentication paths to the minimum delegation set and review them regularly. Limit delegated rights to only the downstream services the account must reach. | ||
| NIST CSF 2.0 | PR.AA-05 — Identity Management, Authentication, and Access Control | Delegation scope is an access-control decision that bounds impersonation authority. |
| Recommendation — Enforce explicit authorization boundaries for service accounts and delegated access. | ||
| CIS Controls v8 | CIS-5 — Account Management | Delegation depends on owning, reviewing, and removing powerful service accounts. |
| Recommendation — Inventory delegated accounts and remove unnecessary trust relationships. | ||
| MITRE ATT&CK | T1550 — Use Alternate Authentication Material | Stolen tickets and delegated authentication material can be abused for impersonation. |
| Recommendation — Detect abuse of delegated authentication material and ticket-based impersonation. | ||
Practitioner Guidance
What to verify: Confirm that every delegated service account has a narrowly defined downstream target set, and challenge any configuration that depends on unconstrained delegation for convenience. If the service truly needs broad impersonation, treat that as a high-risk exception that requires compensating monitoring and ownership review.
Common mistake: Teams often secure the service account password but overlook the delegation scope itself. That is incomplete, because the trust relationship, not just the secret, determines how far a compromise can spread.
Practitioner takeaway: The security value of constrained delegation is not just that it is more restrictive, it is that it converts delegation from an open-ended impersonation privilege into a bounded trust relationship that can be reviewed, reasoned about, and contained.
Related resources from NHI Mgmt Group
- Why does Kerberos reduce authentication risk in Active Directory environments?
- Why does Kerberos delegation create such a large risk in Active Directory?
- How should security teams reduce ransomware risk in Active Directory environments?
- How should security teams reduce the risk from SPN scanning in Active Directory environments?
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
