Constrained delegation is controlled from the delegating account, where administrators list which services it may reach. Resource-based constrained delegation reverses that model, so the target resource decides which accounts may delegate to it. That shift gives the resource owner more control and can work across trusts, but it still requires careful review of who is trusted.
How the two delegation models differ in who controls trust
Constrained delegation and resource-based constrained delegation solve the same access problem, but they place the trust decision in different places. In classic constrained delegation, the delegating account is configured with the specific services it may impersonate users to reach. In resource-based constrained delegation, the target service owns that trust list, which changes both administrative control and the blast radius of a misconfiguration.
That difference matters because access control is not just about whether delegation is allowed, but how the trust decision is governed. If the delegating side is compromised, classic constrained delegation can expose every service it is already allowed to reach. With resource-based constrained delegation, the resource owner can narrow that exposure by approving only the accounts it actually expects to trust.
Why resource ownership changes the security posture
Resource-based constrained delegation is usually the better fit when the service owner, not the caller owner, should decide which principals are trusted. That is especially useful in environments where teams own their own back-end services, because the resource can enforce its own access boundary without waiting for a central account owner to update delegation settings. It also helps when delegation must cross trust boundaries, because the authorization decision lives with the resource that is being accessed.
Classic constrained delegation can still be appropriate when central platform teams manage the source account and can keep the allowed service list tightly controlled. The key trade-off is operational: the older model is easier to reason about from the caller side, while the resource-based model is often safer for distributed ownership because it prevents one account owner from unilaterally extending trust to a resource they do not control.
Active Directory review points that determine whether delegation is safe
The practical question is not which model sounds more modern, but whether the trust boundary matches the ownership model. Review who can edit the delegation configuration, which services are permitted, and whether the trusted scope is narrower than the account's real privileges. In both models, overbroad delegation can turn a normal service account into a lateral movement path.
Resource-based constrained delegation reduces that risk only when the resource-side allow list is kept deliberate and small. If the target resource trusts too many callers, or if service accounts are reused across applications, the control becomes harder to audit and easier to abuse. In Active Directory, the safest pattern is the one where the delegation boundary mirrors actual service ownership and does not depend on informal coordination between teams.
Risk and Threat Considerations
Delegation settings are attractive to attackers because they can convert one compromised account into access to multiple downstream services. Misplaced trust, overly broad service lists, or stale delegation entries can create a clean path for impersonation and lateral movement without needing the original user's password.
Failure mechanism: A delegating account that is allowed to reach too many services, or a target resource that trusts too many callers, creates an impersonation path that expands the impact of any account compromise.
Impact: Attackers can abuse the delegation relationship to access protected services as if they were an approved caller, increasing the chance of privilege escalation, service compromise, and domain-wide spread.
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 sets the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AC-3 — Access Enforcement | Delegation is an access decision that must enforce who may act for whom. |
| AC-6 — Least Privilege | Both delegation models must limit who can impersonate and reach downstream services. | |
| IA-5 — Authenticator Management | Delegation depends on managing the credentials and tickets that enable service access. | |
| Recommendation — Enforce delegation rules so only explicitly approved callers can act on a target resource. Restrict delegated access to the minimum services and actions required. Control the lifecycle and protection of credentials and tickets used in delegation. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | Access control must define and enforce who can delegate access to protected services. |
| A.8.5 — Secure authentication | Delegation relies on trusted authentication paths between accounts and services. | |
| Recommendation — Define delegation boundaries and review them as part of access control governance. Validate the authentication chain used to support delegated service access. | ||
Practitioner Guidance
What to verify: Confirm that the delegation model matches the ownership model. If the service owner cannot explain why a caller is trusted, the delegation entry is probably too broad or too old to keep.
Decision rule: Use the resource-based model when the protected service should control its own callers, and reserve classic constrained delegation for tightly managed platform-owned accounts where the caller side can be governed centrally.
Practitioner takeaway: The control is only as strong as the trust boundary it enforces, so treat delegation as an authorization decision that must be owned, reviewed, and scoped by the party best able to judge the risk.
Related resources from NHI Mgmt Group
- What is the difference between role-based access and API key governance for NHI security?
- What breaks when resource-based constrained delegation is misconfigured on highly sensitive Active Directory objects?
- What is the difference between role based access control and resource level policy decisions?
- What is the difference between context-based access control and standard directory lookup for policy decisions?
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
