Who is accountable when a managed directory permits RBCD-style escalation?

Why This Matters for Security Teams

When a managed directory permits RBCD-style escalation, the real risk is not the feature itself but the privilege path it creates across machine trust, delegation, and API-driven provisioning. Cloud-managed control planes can simplify operations while still leaving customers exposed if group membership, workload permissions, and delegation edges are not tightly governed. NHI Management Group’s research shows that 97% of NHIs carry excessive privileges, which makes escalation paths far more likely to become material incidents than isolated misconfigurations. Top 10 NHI Issues and the NIST Cybersecurity Framework 2.0 both reinforce the need to treat identity paths as continuously managed attack surfaces, not one-time configuration tasks. In practice, many security teams encounter RBCD abuse only after a lateral movement chain has already been used to reach privileged systems, rather than through intentional governance of delegation design.

How It Works in Practice

RBCD, or resource-based constrained delegation, allows a target resource to decide which principals may act on its behalf. In managed directories, that decision often intersects with machine creation, join rights, service accounts, and directory permissions that are spread across platform and identity teams. Accountability therefore has to be mapped by control plane, not assumed by ownership label alone. The cloud provider is responsible for the managed service boundary, the platform team for deployment patterns and API use, and the identity team for delegation policy, monitoring, and review. Practitioners usually need to define four controls explicitly:

• Who can create or join computer objects through APIs or automation
• Which groups can grant or inherit delegation-capable permissions
• Which workloads are permitted to request service-to-service impersonation
• How changes to delegation paths are logged, reviewed, and revoked

This is where Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs is useful, because it frames non-human identity governance as a lifecycle problem, not just an access review problem. For control alignment, NIST Cybersecurity Framework 2.0 supports the operational need to identify, protect, detect, and respond around privileged identity paths. A practical implementation also means separating delegated administration from workload administration, and watching for automated creation flows that can silently expand trust. These controls tend to break down when directory administrators, DevOps pipelines, and managed service defaults all have overlapping authority because no single owner sees the full escalation chain.

Common Variations and Edge Cases

Tighter delegation control often increases operational overhead, requiring organisations to balance faster platform delivery against more frequent approvals, reviews, and exception handling. Current guidance suggests there is no universal standard for RBCD ownership in managed directories, so responsibility must be assigned contractually and operationally rather than inferred from the service model alone. In some environments, the provider can only manage the directory platform while the customer still controls the objects, groups, and policies that make escalation possible. That distinction matters most in hybrid environments where on-premises join rights, cloud automation, and identity sync rules overlap. The most common edge case is delegated access that is technically “allowed” by design but never intended for workload impersonation. Another is break-glass administration that bypasses normal approvals and later becomes a standing path to privilege. The NHI Lifecycle Management Guide is relevant here because RBCD paths should be treated as lifecycle-dependent trust relationships that require review, revocation, and offboarding. The Ultimate Guide to NHIs — Regulatory and Audit Perspectives also helps frame audit responsibility: if a workload can be granted delegation through admin changes, then the customer still owns the monitoring, evidence, and approval trail even when the directory is managed. The hard boundary is not “who hosts the directory” but “who can change trust paths without being detected.”

Related resources from NHI Mgmt Group

• Who is accountable when orphaned Active Directory access is not removed?
• Why do Shai Hulud style attacks matter to NHI governance?
• How should security teams govern Active Directory service accounts?
• Why do delegated managed service accounts increase privilege escalation risk in Active Directory?