How do you create and manage user-assigned managed identities in Azure?

How Azure user-assigned managed identities are created and attached

A user-assigned managed identity is created first as its own Azure resource, then linked to one or more workloads that support it. That separation is the main operational difference from a system-assigned identity. It gives you a reusable identity object that can outlive the workload and be attached across multiple apps, VMs, or services that need the same trust relationship.

The practical benefit is that the identity can be managed independently of any single host or deployment. Cloud Workload Identity Guide is a useful reference when you want the broader pattern for Azure managed identities alongside other workload identity approaches. In Azure, the key design question is whether one workload should own the identity lifecycle, or whether several workloads should share one identity because they need the same permissions and boundary.

Because the identity is reusable, you should treat attachment as a deliberate governance step, not just a configuration detail. If the same user-assigned identity is connected to multiple workloads, every workload inherits the same access path, so the identity should only be shared when that is truly intended and documented.

Managing access, scope, and reuse

After creation, management is mostly about authorization and lifecycle discipline. The identity itself does not “log in” with a password or secret in the usual sense, but it still needs role assignments on the resources it should reach. That means you manage the identity the same way you would manage any other access-bearing principal: assign only the roles it needs, at the narrowest useful scope, and review those assignments regularly.

This is where Azure RBAC and Service Principals Guide becomes practical reading, because the control problem is the same even though the authentication mechanism differs. The discipline is to separate identity creation from permission grants, then verify that the assigned scopes still match the workload’s current function. If an identity is attached to several resources, review whether each attachment is still necessary and whether the permissions need to be identical across them.

Managed identity reuse can be efficient, but it also creates shared exposure. A single over-permissioned identity can become a common path to multiple services, so reuse should be justified by shared function, not convenience. If two workloads do not need the same downstream access, they should not share the same identity just because it is easier to administer.

When to remove, rotate, or separate a managed identity

The lifecycle decision is as important as creation. Unused user-assigned identities should be removed promptly, and identities that have accumulated broad permissions should be split when the design no longer fits the workload boundary. The main question is whether the identity still reflects one coherent trust domain or whether it has turned into a shared access shortcut that now exceeds its original purpose.

Top 10 NHI Issues is relevant here because stale ownership, excessive permissions, and shared identities are recurring failure modes in the broader identity lifecycle. For Azure-managed identities, the operational signal is not just whether the workload still runs, but whether the identity still has a valid owner, a clear purpose, and a bounded blast radius.

As a rule, separate identities when privilege needs diverge, when the attachment set becomes hard to explain, or when decommissioning one workload should not disturb another. If you cannot easily answer which workloads depend on the identity and why, the identity likely needs cleanup or redesign.

Risk and Threat Considerations

Shared Azure managed identities can increase blast radius because one compromise or misconfiguration may expose several workloads at once. The same risk appears when an identity is left attached to retired resources or retains permissions that no longer match the workload’s function.

Failure mechanism: Excessive role assignments, broad scope, or unnecessary reuse let a single managed identity act as a common access path across multiple services, so compromise or misuse of that identity can propagate laterally.

Impact: Attackers or careless operators can reach more Azure resources than intended, and the resulting exposure is often harder to detect because the access looks legitimate for that identity.

Practitioner Guidance

What to verify: Confirm the identity is attached only to workloads that genuinely need the same trust boundary, and confirm the role assignments still match current usage. If the identity supports more than one workload, document why the sharing is acceptable and who owns the review.

Common mistake: Teams often keep one convenient user-assigned identity for too many apps, then let permissions accumulate over time. That shortcut reduces administration effort in the short term but usually creates the hardest cleanup later, especially when a workload is retired and the identity remains in place.

Practitioner takeaway: Manage user-assigned managed identities as reusable access principals with a defined owner, a narrow role footprint, and a deliberate reuse boundary, because the real risk is not creation but silent expansion of trust.

Related resources from NHI Mgmt Group

• Why can user-assigned managed identities increase escalation risk across Azure resource groups?
• Why do compromised managed identities create such a serious cloud security risk for Azure environments?
• Why do local accounts create more IAM risk than centrally managed identities?
• Why do application-local accounts create more NHI risk than centrally managed identities?