Resource-Based Constrained Delegation is a delegation model that limits which systems can act on behalf of others. It reduces the abuse potential of older delegation settings by making the target resource control the trust relationship rather than the delegating account.
Expanded Definition
Resource-Based Constrained Delegation, or RBCD, is an authorization pattern in Microsoft environments where the target resource decides which principals may delegate access on its behalf. That is different from older constrained delegation models, where the delegating account carries the trust relationship. In NHI security, the shift matters because the resource owner can limit impersonation paths more directly.
In practice, RBCD is most useful when service-to-service access must be enabled without handing out broad, persistent privilege. It is often discussed alongside PAM, ZSP, and RBAC, but it is not a replacement for any of them. RBAC defines who can do what, PAM governs privileged sessions, and RBCD controls whether a service can present a user or service identity to a downstream resource. Guidance in the industry is still evolving on how tightly RBCD should be paired with JIT and ZTA controls, but the operational direction is clear: reduce standing trust and keep delegation scoped to the resource that actually needs it. The NIST Cybersecurity Framework 2.0 reinforces this least-privilege posture through identity and access governance practices reflected in NIST Cybersecurity Framework 2.0.
The most common misapplication is treating RBCD as a safe default for any service account pair, which occurs when administrators grant delegation without validating whether the target resource truly needs to impersonate the originating principal.
Examples and Use Cases
Implementing RBCD rigorously often introduces directory and delegation-management overhead, requiring organisations to weigh service availability against tighter trust boundaries.
- A file service needs to access a backend database on behalf of an authenticated user, but only that specific database object is permitted to accept the delegation relationship.
- An internal application tier uses RBCD so a front-end service can reach a downstream API without granting the front-end account broad domain-wide delegation rights.
- A platform team migrates from older delegation settings after reviewing attack paths similar to the abuse patterns described in the ASP.NET machine keys RCE attack research, where weak trust controls magnify compromise impact.
- A security engineer aligns delegated service access with the access-control discipline described in NIST Cybersecurity Framework 2.0 so the resource owner, not the caller, defines acceptable delegation.
- An identity team uses RBCD for a narrowly scoped application migration, then removes the relationship once the temporary integration is no longer needed.
Operators should treat RBCD as a precision control, not a general convenience feature. When the delegation boundary is too broad, the resource begins to act as an unwitting amplifier for lateral movement.
Why It Matters in NHI Security
RBCD matters because compromise of a single service identity can become a stepping stone to impersonation, data access, or privilege escalation if delegation is too permissive. In NHI environments, attackers often target the relationships between identities rather than the identities alone. That makes delegated trust one of the highest-value places to reduce blast radius.
The business risk is not abstract. In the DeepSeek breach reporting, DeepSeek accidentally embedded over 11,000 secrets in training data and exposed a database containing more than one million sensitive records, showing how quickly weak control boundaries can turn into systemic exposure. Similarly, NHIMG research on secrets management shows organisations maintain an average of 6 distinct secrets manager instances, which fragments control and makes delegated trust harder to govern. RBCD does not solve secrets sprawl, but it becomes far more dangerous when overlaid on fragmented identities and poorly reviewed service accounts. Organisational confidence often outpaces actual control quality, and that gap is where delegation abuse thrives. Organisations typically encounter the consequences only after an account compromise, at which point delegation boundaries become operationally unavoidable to investigate and contain.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 | Covers over-permissive service identity trust and delegation abuse in NHI environments. |
| NIST CSF 2.0 | PR.AC-4 | Least-privilege access management aligns with limiting who can delegate on a resource. |
| NIST Zero Trust (SP 800-207) | AC-4 | Zero Trust limits implicit trust, which matches RBCD's resource-controlled delegation model. |
Scope delegation narrowly and review every trust path for unnecessary impersonation rights.
