VM user-assigned identity gives a virtual machine a reusable Azure identity that is not tied to that VM's lifetime. Applications or agents running on the VM can use it to access services such as Key Vault, Storage, SQL, or custom APIs without passwords in files. Unlike a system-assigned identity, the identity exists as its own resource and can be attached to more than one VM. That makes it useful when several servers need the same access pattern or when a VM is rebuilt but its permissions must remain stable.
VM user-assigned managed identity, user-assigned managed identity for virtual machines, virtual machine user-assigned identity, managed identity attached to VM
Difficulty
intermediate
CLI mappings
5
Last verified
2026-05-29
Microsoft Learn
VM user-assigned identity is a reusable managed identity resource attached to a virtual machine so software on that VM can request Microsoft Entra tokens without stored credentials. Its lifecycle and permissions are managed separately from the VM across rebuilds and fleets.
Technically, a user-assigned managed identity is a Microsoft.ManagedIdentity/userAssignedIdentities resource associated with a Microsoft.Compute virtualMachines identity profile. Azure exposes the identity to the guest through the managed identity endpoint, and the workload requests Microsoft Entra tokens for downstream resources. The identity has its own client ID, principal ID, resource ID, tags, region, and role assignments. It sits across compute, identity, RBAC, and application configuration boundaries. Attaching it to a VM enables token acquisition, but authorization still depends on explicit role assignments at the target scope.
Why it matters
VM user-assigned identity matters because credentials on servers are still one of the easiest ways to create a breach or an outage. A reusable managed identity lets teams preauthorize access before VM rollout, rebuild servers without recreating permissions, and keep the same identity across blue-green or scale-out patterns. It also makes access review clearer: the identity is a named resource with role assignments, Activity Log history, and owners. The risk is that shared identity can become overprivileged if every VM inherits broad access. Good design treats it like a production service account: narrowly scoped, monitored, documented, and detached when no longer needed.
⌁
Where you see it
Signals, screens, and Azure surfaces where this term usually becomes operational.
Signal 01
On the VM Identity blade, user-assigned identities appear as attached identity resources with names, resource groups, and client IDs that operators verify before granting access.
Signal 02
In Azure CLI or ARM output, the VM identity block lists userAssignedIdentities by resource ID, which proves what the guest can request tokens for. during reviews.
Signal 03
In RBAC role assignment reviews, the identity principal ID appears as the assignee on Key Vault, Storage, SQL, or resource-group scopes. during audits and incident review.
✦
When this becomes relevant
Specific situations where this term helps solve real Azure design, operations, migration, security, reliability, cost, or governance problems.
Keep Key Vault or Storage access stable when VMs are rebuilt, reimaged, or replaced during patching.
Preauthorize a fleet identity before deploying VM-based agents, runners, or integration workers.
Share one least-privilege identity across a controlled set of servers that perform the same job.
Remove passwords from VM configuration by letting code request Microsoft Entra tokens through managed identity.
Audit and clean up VM access by reviewing identity attachments and role assignments instead of searching secrets.
◆
Real-world case studies
Different enterprise-style examples that show the term being used to hit measurable objectives.
Case study 01
Manufacturing robotics agents without stored keys
Manufacturing robotics agents without stored keys: A VM user-assigned identity gives server fleets stable, reviewable access without turning golden images into secret containers.
📌Scenario
Contoso Robotics runs plant-floor telemetry collectors on Azure VMs that send files to a locked-down storage account. Their old image contained a rotated storage key that was missed during two factory expansions.
🎯Business/Technical Objectives
Remove storage keys from VM images and scripts.
Keep access stable across image rebuilds and regional expansion.
Limit telemetry agents to write-only storage access.
Produce audit evidence for plant cybersecurity reviews.
✅Solution Using VM user-assigned identity
The platform team created a user-assigned managed identity named for the telemetry-agent workload and attached it to each collector VM during deployment. They granted the identity Storage Blob Data Contributor only on the ingestion container, then updated the agent to request tokens by the identity client ID. Azure CLI release steps verified the VM identity block, exported the principal ID, and checked the role assignment before each factory cutover. Key Vault retained unrelated secrets, but storage authentication moved fully to Microsoft Entra tokens. Activity Log alerts were added for identity assignment changes outside the pipeline.
📈Results & Business Impact
Embedded storage keys were removed from 64 VM images and startup scripts.
Credential-rotation tickets for the agent fleet dropped from monthly work to zero recurring tasks.
A failed expansion rollout was caught in precheck because one VM lacked the identity attachment.
Audit evidence collection fell from three engineer-days to under four hours per quarter.
💡Key Takeaway for Glossary Readers
A VM user-assigned identity gives server fleets stable, reviewable access without turning golden images into secret containers.
Case study 02
Game build farm with reusable package access
Game build farm with reusable package access: Reusable managed identity is a cleaner fit than copied secrets when disposable VMs need the same constrained access every time they appear.
📌Scenario
Northwind Interactive operated bursty Windows VM build workers that pulled art assets from private storage. Build failures spiked whenever short-lived VMs came up before shared secrets were copied correctly.
🎯Business/Technical Objectives
Let new build workers authenticate immediately after provisioning.
Avoid storing storage connection strings in build scripts.
Keep access limited to build artifact containers.
Support rapid scale-out during release candidate weeks.
✅Solution Using VM user-assigned identity
The DevOps team created one user-assigned identity for the build-worker pool and attached it through the VM creation template. The identity received read access to asset containers and write access only to build-output storage. Build scripts switched to Azure SDK authentication with an explicit client ID, so workers could request tokens through the local managed identity endpoint. The release pipeline used Azure CLI to create the identity in the shared platform resource group, attach it to each VM, and validate role assignments before agents joined the pool. Failed workers were deleted without deleting the identity or its permissions.
📈Results & Business Impact
First-job authentication failures dropped by 91% during the next release cycle.
Worker provisioning time fell by 14 minutes because no secret-copy step was required.
Emergency secret rotation during release week was eliminated.
Security reduced the build pool's effective storage scope from account-wide access to two containers.
💡Key Takeaway for Glossary Readers
Reusable managed identity is a cleaner fit than copied secrets when disposable VMs need the same constrained access every time they appear.
Case study 03
Research lab compute nodes with auditable data access
Research lab compute nodes with auditable data access: A user-assigned identity can act like a controlled workload passport, especially when compute is temporary but data permissions must be durable.
📌Scenario
A climate research institute used Azure VMs for seasonal simulation runs against protected datasets. Investigators needed reproducible access, while compliance needed proof that departed researchers could not keep stale credentials.
🎯Business/Technical Objectives
Separate data access from individual researcher accounts.
Preserve permissions when compute nodes are rebuilt for new experiments.
Restrict each model runner to approved dataset folders.
Show access evidence during grant-funded compliance reviews.
✅Solution Using VM user-assigned identity
The lab created user-assigned identities per simulation program rather than per VM. Each identity was attached to temporary compute nodes only during approved runs and granted dataset access through Storage Blob Data Reader at folder-aligned scopes. Runbooks required operators to show the identity assignment, role scope, and experiment tag before releasing a node to researchers. When a simulation ended, automation removed the identity from the VM and deleted the node, but the identity remained available for the next approved run. Sentinel queries watched for identity assignment outside the scheduling pipeline.
📈Results & Business Impact
Researcher-owned access keys were retired from 11 active simulation workflows.
Node rebuilds stopped causing permission tickets during quarterly model refreshes.
Compliance review time fell from five days to one day because identity evidence was centralized.
Two unauthorized manual attachments were detected within ten minutes and reversed before data access occurred.
💡Key Takeaway for Glossary Readers
A user-assigned identity can act like a controlled workload passport, especially when compute is temporary but data permissions must be durable.
Why use Azure CLI for this?
I use Azure CLI for VM user-assigned identity work because identity changes need repeatable proof, not portal memory. In real environments, I want to script creation, assignment, role grants, and evidence collection across subscriptions and resource groups. CLI output shows the client ID, principal ID, resource ID, and VM identity block that downstream teams need for debugging. It also lets pipelines attach the same identity during VM deployment, compare actual assignments against source control, and remove stale identities safely. The portal is fine for inspection, but CLI is better when identity drift can break production access or weaken least privilege.
CLI use cases
Create or inspect a user-assigned identity resource before attaching it to production VMs.
Assign the identity to one VM or a repeatable set of VMs from deployment automation.
Show the VM identity block and confirm the expected userAssignedIdentities resource ID is present.
Create narrow role assignments for the identity principal on Key Vault, Storage, SQL, or resource groups.
Remove a stale identity from a VM after migration, application retirement, or privilege cleanup.
Before you run CLI
Confirm tenant, subscription, VM resource group, identity resource group, and target resource scope before assigning anything.
Verify your account has Virtual Machine Contributor on the VM and Managed Identity Operator on the identity.
Decide whether the identity is meant for one workload, a VM fleet, or a temporary migration bridge.
Check for destructive risk before removing an identity because running code may immediately lose token access.
Use JSON output so client ID, principal ID, resource ID, and role assignment scope can be reviewed later.
What output tells you
The VM identity block shows whether the user-assigned identity is actually attached to the intended VM resource.
The identity resource output gives the client ID, principal ID, location, tags, and full resource ID needed by applications.
Role assignment output tells you whether the identity principal has authorization at the correct target scope.
Activity Log entries show who assigned, removed, or changed the identity during deployment or an incident.
If multiple identities are attached, output helps confirm which client ID application code must request explicitly.
Mapped Azure CLI commands
VM user-assigned identity CLI commands
direct
az identity show --name <identity-name> --resource-group <identity-resource-group>
az identitydiscoverCompute
az vm identity assign --name <vm-name> --resource-group <resource-group> --identities <identity-resource-id>
az vm identitysecureCompute
az vm identity show --name <vm-name> --resource-group <resource-group>
az vm identitydiscoverCompute
az role assignment create --assignee-object-id <principal-id> --assignee-principal-type ServicePrincipal --role "<role-name>" --scope <scope>
az role assignmentsecureIdentity
az vm identity remove --name <vm-name> --resource-group <resource-group> --identities <identity-resource-id>
az vm identityremoveCompute
Architecture context
Architecturally, VM user-assigned identity is the machine identity layer for VM-hosted workloads. It belongs next to Key Vault access, storage RBAC, database authentication, application configuration, and deployment automation. I design it before the VM fleet, not after, because the identity determines what the workload can call once it starts. It is especially useful for scale sets, immutable image patterns, job runners, and agent fleets that share the same permission boundary. The important boundary is not the VM; it is the identity's role assignments and where that identity is allowed to request tokens. A good architecture diagram shows the identity resource, assigned VMs, target scopes, and the approval path for permission changes.
Security
Security impact is direct because a user-assigned identity can grant production access without any password to rotate. That is the point, but it also means role assignments must be tight. Do not give the identity broad Contributor access because several VMs happen to share it. Use least-privilege roles at the narrowest practical scope, prefer data-plane roles over management-plane roles where possible, and monitor sign-in and Activity Log evidence. Restrict who can assign the identity to a VM; assignment is effectively the ability to let code use that identity. Review orphaned identities, stale role assignments, and unexpected VM attachments during access reviews.
Cost
A user-assigned managed identity has no meaningful standalone charge, but it affects cost through operational effort, failed deployments, and overbuilt security workarounds. Without it, teams often copy secrets into images, rotate credentials manually, or rebuild VMs just to change access. With poor design, one shared identity can become a risky catchall that forces expensive audits and cleanup projects. The cost-aware pattern is to use identities that match application boundaries, avoid one identity per throwaway VM when a fleet identity is clearer, and remove unused assignments. Good identity hygiene reduces incident time, rework, and duplicated secret-management tooling. It also shortens access reviews.
Reliability
Reliability improves when a rebuilt or replaced VM can regain the same authorized access without reissuing secrets. A user-assigned identity keeps permissions outside the VM lifecycle, so disaster recovery, image refresh, and blue-green replacement are less fragile. The failure mode is usually authorization drift: the identity exists, but the role assignment was removed, scoped incorrectly, delayed, or attached to the wrong VM. Token acquisition can also fail if guest code selects the wrong identity when multiple identities are present. Reliable runbooks verify assignment, client ID, target role, and token request behavior before declaring the workload healthy after deployment or failover.
Performance
Runtime performance impact is usually indirect. A managed identity token request adds a small authentication step, but the larger performance issue is whether the workload can obtain tokens consistently and cache them correctly. Bad identity selection, missing roles, or retry storms against Key Vault or Storage can look like application slowness. Good code uses Azure Identity libraries, requests the intended client ID when multiple identities are attached, caches tokens through supported SDK behavior, and surfaces authentication latency in logs. Operational performance also improves because CLI evidence quickly narrows a problem to VM assignment, token acquisition, RBAC, or the downstream service.
Operations
Operators inspect user-assigned identities when a VM can boot but cannot reach Key Vault, Storage, SQL, or an API. The workflow is to show the VM identity block, confirm the expected identity resource ID, check the identity's principal ID, and inspect role assignments on the target resource. Changes should go through deployment code or approved CLI commands, not emergency portal clicks that never reach source control. Operations teams also track ownership, tags, expiration notes for temporary access, and Activity Log entries for assignment changes. During incidents, they separate token acquisition failures from target authorization failures and document which identity the guest actually used.
Common mistakes
Granting broad Contributor access to a shared identity because it is easier than assigning focused data-plane roles.
Attaching the identity to a VM but forgetting the downstream role assignment that authorizes the target service.
Using the wrong client ID in code when both system-assigned and user-assigned identities are present.
Deleting or moving the identity without checking which VMs and pipelines still depend on it.
Letting one identity span unrelated applications, which turns a clean managed-identity design into privilege sprawl.