What is the difference between unconstrained and constrained delegation?

Why This Matters for Security Teams

Unconstrained delegation and constrained delegation are often discussed as if they were only Active Directory design choices, but the real issue is trust propagation. When a service can forward a user’s ticket broadly, compromise of that host can expose far more than the original application path. That is why modern guidance increasingly treats delegation as a privilege boundary, not just a configuration detail.

This matters because delegation mistakes can turn a single service account into a lateral movement bridge. The Ultimate Guide to NHIs — What are Non-Human Identities frames these identities as workloads with authority, not just technical accounts, which is exactly how defenders should think about delegation: as identity-to-identity trust that must be scoped. NIST’s NIST Cybersecurity Framework 2.0 reinforces the same point through least privilege, access control, and continuous governance. In practice, many security teams discover delegation risk only after a service account is already being abused to move laterally through a production domain.

How It Works in Practice

Unconstrained delegation allows a service to receive a user’s ticket and present it to almost any downstream service in the domain. That convenience can be useful in older multi-tier Windows environments, but it also means the service host becomes a high-value target. If an attacker compromises that host, they may extract or replay delegated credentials and impersonate users far beyond the original application boundary.

Constrained delegation narrows that trust. Instead of broad ticket reuse, administrators explicitly allow a service to delegate only to named downstream services, and in some cases only for specific protocol flows. This is a stronger fit for least privilege because the service can still function, but its delegation power is bounded. Current guidance suggests pairing this with NIST Cybersecurity Framework 2.0 access governance and strong service identity hygiene. The operational lesson aligns with the identity risks described in the DeepSeek breach: once credentials or identity paths are exposed, attackers move quickly and exploit trust edges that were assumed to be internal.

• Use unconstrained delegation only when there is no workable alternative and the system is isolated and heavily monitored.
• Prefer constrained delegation with explicit downstream service lists and protocol scoping.
• Review service accounts, SPNs, and delegation settings together, not as separate admin tasks.
• Pair delegation restrictions with tiering, JIT access, and strong detection on ticket abuse.

These controls tend to break down in legacy Windows domains with brittle application dependencies, because service owners often cannot map every downstream call path cleanly.

Common Variations and Edge Cases

Tighter delegation often increases operational overhead, requiring organisations to balance security gain against application compatibility and admin effort. That tradeoff is real, especially where legacy authentication flows, third-party middleware, or hard-coded service dependencies still exist.

There is no universal standard for every edge case, but best practice is evolving toward the narrowest practical trust path. For example, some environments need protocol transition or resource-based constrained delegation to preserve functionality while reducing blast radius. Others may need to redesign the service interaction entirely, because delegation settings alone cannot compensate for weak workload identity, poor secret handling, or over-permissive RBAC. The broader NHI view is useful here: delegation is one control in a larger identity chain, and if the service account itself has long-lived secrets or excessive rights, the benefit of constrained delegation is reduced. The identity context discussed in the Ultimate Guide to NHIs — What are Non-Human Identities helps teams separate the account, the workload, and the authorisation path. For deeper threat perspective on how identity compromise becomes abuse, the DeepSeek breach is a useful reminder that exposed secrets and weak identity controls are often part of the same failure pattern.

In short, unconstrained delegation is a broad trust model that should be rare, while constrained delegation is the safer default when a service truly needs to act on behalf of users.

Related resources from NHI Mgmt Group

• What is the difference between managed identities and hardcoded secrets for AI agents?
• What is the difference between human identity governance and AI agent governance?
• What is the difference between workload identity and API keys for AI agents?
• What is the difference between governing human access and governing AI agent access?