User-assigned managed identities are created in one resource group, but their underlying service principal can be granted roles across a broader subscription. That separation lets a privileged user in one scope attach an identity that already has wider permissions, then use it through a resource that supports managed identity authentication. The risk is scope escape, not credential theft.
Why the risk is about scope, not secret theft
User-assigned managed identities create a useful boundary break: the identity object lives in one resource group, but the permissions attached to its service principal can span far beyond that group. In Azure, that means the control surface is not the resource-group container itself, but the broader role assignment graph. If you treat the identity as “local” because it was created locally, you can miss where it can actually act.
That separation matters because a managed identity is usually consumed by a resource, not by a person typing a password. The dangerous pattern is not stolen credentials, but an identity with existing reach being attached to a less-guarded resource. A team with rights in one scope can sometimes cause actions in another scope simply by using the identity through a supported Azure service path. NHIMG’s Cloud Workload Identity Guide covers the broader pattern of how Azure managed identities and service principals become portable access primitives.
The practical implication is that the escalation path often looks legitimate from the platform’s perspective. The resource group boundary does not prevent a subscription-level role assignment from being exercised through an attached workload. That is why the real question is not “where was the identity created?” but “what can this principal do anywhere in the subscription, and who can attach it where?”
Where cross-resource-group privilege becomes dangerous
The escalation condition emerges when creation and attachment rights are easier to obtain than the permissions already granted to the identity. If a user can deploy or modify a resource in one group, and that resource can use a managed identity that has broader subscription permissions, the user may inherit effective access to actions they should never have held directly. This is a privilege composition problem, not a break in Azure authentication.
That is why user-assigned managed identities deserve the same scrutiny as any reusable workload credential. Their value is portability, but portability also means reusability across trust boundaries. Service Account Security Guide is relevant here because the control question is similar: whether a shared identity primitive is governed tightly enough to prevent overreach, reuse, and unintended delegation.
In practice, the highest-risk pattern is an identity with broad role assignments that is attached to resources in a lower-trust group, especially when those resources are easier for application owners, operators, or automation pipelines to touch than the subscription roles themselves. The managed identity becomes a bridge from local change authority to broader environment authority.
NHIMG’s Active Directory and Entra ID Hardening Guide is useful because this is still an access-control and delegation problem, even when the surface looks like cloud infrastructure rather than directory administration.
What good control design looks like in Azure
The safest posture is to treat assignment rights and use rights as separate questions. A team that can create or update a compute, app, or automation resource should not automatically be able to bind any high-privilege user-assigned managed identity to it. Likewise, the identity itself should carry only the minimum roles needed for the workload’s real function, not a convenience bundle assembled for future reuse.
Visibility also matters. If you cannot quickly inventory which identities are attached to which resources, and which subscriptions or resource groups each identity can affect, you will miss most of the escalation risk until after an incident. NHIMG’s Top 10 NHI Issues is a useful navigation point for the common failure modes that show up when identities outgrow their original scope.
For Azure specifically, the practical control objective is simple: the entity allowed to attach the identity should be much less privileged than the identity it can attach. If those two permission sets overlap too closely, the resource group boundary stops being a boundary and starts being a convenience layer.
NHIMG’s Ultimate Guide to NHIs, Key Challenges and Risks is a good reference for the broader overprivilege and visibility problems that make this pattern dangerous at scale.
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 and CSA Cloud Controls Matrix set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-9 — Identification and Authentication (Service Organizations) | Managed identities act as service credentials across resources and scopes. |
| AC-6 — Least Privilege | Escalation occurs when attachment rights and identity permissions exceed the workload's need. | |
| AC-5 — Separation of Duties | Creation, attachment, and permission assignment should not be controlled by the same low-trust actor. | |
| Recommendation — Bind service identities to least-privilege authentication paths and restrict where they can be used. Limit each managed identity to the minimum roles required for its workload. Separate identity assignment authority from resource administration rights. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | The issue is cross-scope access control over reusable Azure identities. |
| A.5.18 — Access rights | Role grants on a managed identity must be reviewed and constrained across the subscription. | |
| Recommendation — Apply access control rules that prevent reusable identities from exceeding approved scope. Review and restrict access rights on managed identities across all scopes they can reach. | ||
| CSA Cloud Controls Matrix | IAM — Identity & Access Management | Cloud identity governance covers role scope, reuse, and delegated attachment rights in Azure. |
| Recommendation — Govern cloud identities so attachment permissions never outrun the roles they can exercise. | ||
Practitioner Guidance
What to verify: Check whether the identities that can be attached to resources in lower-trust groups already hold subscription-wide or cross-group roles. If yes, treat that as an escalation candidate even if no secret is exposed and no direct credential theft is possible.
Decision rule: If a user or pipeline can change a resource but should not be able to use its attached identity to reach the broader subscription, separate attachment rights from assignment rights, and reduce the identity’s role scope before expanding the resource’s deployment privileges.
Common mistake: Teams often audit the resource group where the identity was created and stop there. The more important check is the full set of RBAC assignments and every place the identity can be consumed, because that is where the effective blast radius lives.
Practitioner takeaway: Treat user-assigned managed identities as reusable authority, not as local assets. If the identity can reach further than the resource that hosts it, the attachment path becomes a privilege-escalation path unless the assignment boundary is deliberately constrained.
