A VM system-assigned identity gives one Azure VM its own Microsoft Entra identity without a password or client secret for the team to manage. Code or scripts running on the VM can ask Azure for a token and use that identity to reach services such as Key Vault, Storage, SQL, or Azure Resource Manager. The identity belongs to that VM and is removed when disabled or when the VM is deleted. It is ideal when the server itself needs access, but it must be paired with least-privilege role assignments.
VM system-assigned identity, vm system-assigned identity
Difficulty
intermediate
CLI mappings
5
Last verified
2026-05-29
Microsoft Learn
VM system-assigned identity is a Microsoft Entra managed identity created directly on an Azure virtual machine. Azure manages its credentials, ties its lifecycle to that VM, and lets the guest request tokens for authorized Azure resources without storing secrets in code.
Technically, a system-assigned identity is configured on the Microsoft.Compute virtualMachines resource under the identity property. Azure creates a service principal in Microsoft Entra ID, exposes token acquisition through the Instance Metadata Service inside the VM, and manages credential rotation. Authorization is not automatic; administrators still grant RBAC roles or service-specific permissions on target resources. The identity is different from a user-assigned identity because it cannot be shared across multiple VMs and follows the VM lifecycle. It intersects with IAM, Key Vault, storage data-plane access, automation, and governance.
Why it matters
VM system-assigned identity matters because secrets on servers age badly. Connection strings, client secrets, certificates, and saved passwords end up in scripts, config files, deployment logs, and backup images. A managed identity removes much of that credential handling by letting Azure issue tokens to the VM at runtime. It also gives security teams a clear principal to audit and remove. The tradeoff is precision: the identity is powerful only where roles are granted. Overbroad roles on a VM identity can turn a compromised server into a path toward storage, vaults, databases, or management-plane actions. That makes role design as important as enabling the identity itself.
⌁
Where you see it
Signals, screens, and Azure surfaces where this term usually becomes operational.
Signal 01
In the VM Identity blade, System assigned status shows whether Azure has created a lifecycle-bound Microsoft Entra identity for that VM. and links lifecycle to the VM resource.
Signal 02
In Azure CLI, az vm identity show returns principalId, tenantId, and identity type fields used for RBAC assignment and troubleshooting. for scripts and incident tickets.
Signal 03
In IAM and Activity Log, role assignments reference the VM identity principal when it receives access to Key Vault, Storage, SQL, or ARM scopes. at the selected scope.
✦
When this becomes relevant
Specific situations where this term helps solve real Azure design, operations, migration, security, reliability, cost, or governance problems.
Let a VM-hosted application read secrets from Key Vault without storing a client secret on disk.
Authorize backup, deployment, or maintenance scripts running on one VM to access only approved Azure resources.
Replace expired service principal credentials in legacy VM workloads with Azure-managed token acquisition.
Audit and remove access cleanly when a VM is retired because the identity lifecycle follows the VM.
Give a single-purpose VM narrow data-plane roles while avoiding shared credentials across unrelated servers.
◆
Real-world case studies
Different enterprise-style examples that show the term being used to hit measurable objectives.
Case study 01
Freight optimizer removes stored storage keys
Freight optimizer removes stored storage keys: A VM identity is valuable when it replaces secrets with scoped, auditable access to exactly the resources the workload needs.
📌Scenario
A freight analytics team ran a route-optimization service on a VM that used a storage account key embedded in an old configuration file.
🎯Business/Technical Objectives
Remove static storage keys from the VM configuration.
Grant the optimizer only the blob permissions it required.
Keep nightly route planning within the existing processing window.
Create audit evidence for the security exception closure.
✅Solution Using VM system-assigned identity
The cloud engineer enabled VM system-assigned identity on the optimizer VM and recorded its principal ID. Instead of storing a key, the application was updated to use Azure SDK default credentials and request tokens from IMDS. The storage account granted the VM identity a narrow blob data role at the container scope, while the old account key was rotated and removed from the configuration repository. CLI checks listed the identity type, role assignment, and target scope before the nightly job. The team also added an alert for future account-key usage so the exception would not return during troubleshooting.
📈Results & Business Impact
The stored key was removed from three config files and two deployment logs.
Nightly route planning completed within 2 percent of the previous runtime.
The security exception was closed after auditors verified the role scope.
Key rotation no longer required a VM application configuration change.
💡Key Takeaway for Glossary Readers
A VM identity is valuable when it replaces secrets with scoped, auditable access to exactly the resources the workload needs.
Case study 02
Broadcaster secures clip-processing access to Key Vault
Broadcaster secures clip-processing access to Key Vault: System-assigned identity turns VM credential cleanup into a clear lifecycle and RBAC exercise.
📌Scenario
A regional broadcaster used a VM to prepare video clips for distribution, and the process needed database passwords during overnight publishing.
🎯Business/Technical Objectives
Stop placing database passwords in scheduled task files.
Limit the VM to reading only the required Key Vault secrets.
Prove that publishing still worked without manual credential injection.
Create a clean offboarding path when the VM was retired.
✅Solution Using VM system-assigned identity
The media platform team enabled VM system-assigned identity and granted it Key Vault Secrets User on only the vault containing publishing credentials. The clip-processing script was changed to request a token through managed identity and retrieve secrets at runtime. Azure CLI captured the identity principal ID, Key Vault role assignment, and Activity Log entries for the change. The team ran a canary publishing job, verified secret retrieval, and then removed the old password file from the VM and backup allowlist. Because the identity lifecycle followed the VM, retirement planning became simpler: delete or disable the VM and remove any remaining vault role assignment.
📈Results & Business Impact
Plain-text password files were eliminated from the publishing VM.
The canary job published 120 clips with no credential prompt or manual step.
Vault access review time fell from two hours to 20 minutes.
Retirement documentation now includes one identity principal and one vault scope.
💡Key Takeaway for Glossary Readers
System-assigned identity turns VM credential cleanup into a clear lifecycle and RBAC exercise.
Case study 03
City transit VM gains scoped access for maintenance automation
City transit VM gains scoped access for maintenance automation: System-assigned identity helps VM automation become least-privilege instead of secret-dependent.
📌Scenario
A city transit agency used a VM-hosted scheduler to run overnight maintenance scripts against approved Azure resources for station displays.
🎯Business/Technical Objectives
Remove a long-lived service principal secret from automation scripts.
Restrict maintenance actions to the display resource group.
Keep overnight jobs running without staff sign-in.
Improve evidence for public-sector access reviews.
✅Solution Using VM system-assigned identity
The infrastructure team enabled VM system-assigned identity on the scheduler VM and replaced the service principal secret with managed identity authentication. The identity received a custom role limited to reading display resources and restarting one approved app service slot, with no permission to edit networking, storage, or unrelated applications. CLI output documented the principal ID, role definition, assignment scope, and job test results. The team also added Activity Log alerts for identity disablement or role-scope changes. During the next access review, reviewers could map each allowed action directly to a maintenance task instead of approving a broad secret-based principal used by several scripts.
📈Results & Business Impact
One shared service principal secret was retired from seven scripts.
Unauthorized resource-group access attempts failed during validation testing.
Overnight display maintenance completed with no interactive sign-in.
Quarterly access review findings dropped from five identity questions to one minor documentation note about naming consistency.
💡Key Takeaway for Glossary Readers
System-assigned identity helps VM automation become least-privilege instead of secret-dependent.
Why use Azure CLI for this?
I use Azure CLI for VM system-assigned identity because identity work must be exact, repeatable, and reviewable. An experienced Azure engineer wants to see whether identity is enabled, capture the principal ID, assign the smallest useful role at the correct scope, and verify access without browsing through several portal blades. CLI also exposes drift: VMs with identities but no useful roles, roles left after a redesign, or identities missing from servers that need Key Vault. In deployment pipelines, CLI and Bicep make identity and authorization a single auditable change instead of a manual post-build step. It keeps identity changes tied to deployment evidence.
CLI use cases
Enable system-assigned identity on a VM and capture the generated principal ID for a change record.
Assign a Key Vault, Storage, or resource-group role to the VM identity at the smallest practical scope.
List VMs with enabled identities and compare their role assignments for access-review evidence.
Disable an identity only after confirming no workload still depends on its tokens.
Troubleshoot authorization failures by comparing token acquisition, principal ID, role scope, and target service logs.
Before you run CLI
Confirm tenant, subscription, VM resource group, target resource scope, and the identity model expected by the application.
Make sure the caller has Virtual Machine Contributor for identity changes and User Access Administrator or Owner for role assignments.
Decide whether system-assigned or user-assigned identity fits lifecycle, reuse, and blue-green deployment needs.
Check whether enabling identity will trigger application behavior, secret retrieval, or automation that needs monitoring.
Use JSON output to preserve principalId, tenantId, roleDefinitionId, and scope accurately in evidence.
What output tells you
identity.type shows whether the VM has SystemAssigned, UserAssigned, both, or no managed identity enabled.
principalId identifies the Microsoft Entra service principal used in RBAC, logs, and access reviews.
tenantId confirms the directory that owns the identity and must match the authorization plan.
Role assignment output shows the exact scope and permissions the VM identity can use.
Application errors can be mapped to token acquisition, insufficient role scope, target firewall, or service-specific authorization.
Mapped Azure CLI commands
VM system-assigned identity operations
direct
az vm identity assign --name <vm-name> --resource-group <resource-group>
az vm identitysecureCompute
az vm identity show --name <vm-name> --resource-group <resource-group>
az vm identitydiscoverCompute
az role assignment create --assignee <principal-id> --role "Key Vault Secrets User" --scope <scope>
az role assignmentsecureCompute
az role assignment list --assignee <principal-id> --all --output table
az role assignmentdiscoverIdentity
az vm identity remove --name <vm-name> --resource-group <resource-group>
az vm identityremoveCompute
Architecture context
Architecturally, VM system-assigned identity is the bridge between a VM workload and Azure services that trust Microsoft Entra authentication. It should be designed as part of the workload identity model, not as an afterthought. The VM gets an identity, the target resource grants that identity narrowly scoped access, and the application retrieves tokens from the local metadata endpoint. For single-purpose servers, system-assigned identity is clean because lifecycle and ownership match. For shared identities, blue-green swaps, or multiple servers needing the same access, user-assigned identity may be better. Architecture reviews should document the scope and blast radius. This prevents convenience identities from becoming permanent shared backdoors.
Security
Security impact is direct and high. Managed identity removes stored credentials, but it does not remove the need for least privilege. Anyone who can run code on the VM may be able to request tokens for the identity, so guest hardening, patching, endpoint protection, and role scope all matter. Avoid subscription-wide roles unless absolutely justified. Prefer data-plane roles at resource or resource-group scope, review role assignments regularly, and alert on identity changes. When disabling the identity, confirm dependent apps no longer need it and remove any orphaned role assignments or service-specific permissions. Compromise impact should be tested in tabletop exercises regularly.
Cost
There is usually no direct line item for enabling a system-assigned identity on a VM. The cost effect comes from reduced secret-management labor, fewer outages from expired credentials, and tighter access that lowers breach impact. Indirect costs appear when roles are granted too broadly and a compromised VM can damage data, trigger expensive operations, or require incident response. There is also operational cost in maintaining role assignments, access reviews, and monitoring. A good FinOps and security practice is to tie each VM identity to an owner, purpose, target scope, and periodic review date. This is cheap to enable but costly to govern badly.
Reliability
Reliability impact is mostly dependency reliability. A VM that uses system-assigned identity avoids outages caused by expired client secrets or misplaced certificates, which is a major operational win. However, the workload now depends on Microsoft Entra token issuance, Instance Metadata Service availability from the guest, correct RBAC, and target service authorization. Misconfigured roles look like application outages even though the VM is running. Reliable designs cache tokens according to SDK guidance, retry transient token failures, monitor authorization errors, and include identity validation in deployment and startup checks. Backup does not recreate permissions by itself. Identity checks belong in synthetic health tests.
Performance
Performance impact is normally small but not zero. Applications request tokens from the local metadata endpoint and then call downstream services using those tokens. Poorly written code that requests a new token for every operation can add latency and unnecessary dependency pressure. Well-designed code uses Azure SDK credential caching and retries. Identity choice can also affect operational performance: deployments are faster when secrets do not need manual injection, and recovery is faster when role assignments are documented. If an app slows down, separate token latency from network, storage, database, and service throttling before blaming identity. Measure token failures separately from ordinary application retries.
Operations
Operators inspect VM system-assigned identity during deployments, access reviews, incident response, and application troubleshooting. The common workflow is to check whether identity is enabled, record the principal ID and tenant, list role assignments, verify target scopes, and test the application path. Changes should be made through infrastructure as code or scripted CLI where possible. Operations teams also watch for identity removal, VM recreation, resource moves, and role-assignment drift. During incidents, distinguish token acquisition failures, permission failures, network failures, and target service outages; they produce similar symptoms but different fixes. This evidence keeps access reviews from becoming guesswork for administrators and auditors.
Common mistakes
Enabling identity and assuming access works without assigning RBAC or service-specific permissions to target resources.
Granting broad Contributor rights when a narrow data-plane role would satisfy the workload.
Deleting or recreating the VM and forgetting that the system-assigned identity principal changes with lifecycle.
Treating managed identity as protection against guest compromise even though code on the VM can request tokens.
Moving an application to another VM without updating role assignments or choosing a reusable user-assigned identity.