A managed identity lets an Azure workload get Microsoft Entra tokens without storing any credential. A system-assigned identity belongs to one resource and is deleted with it. A user-assigned identity is a separate resource that several resources can share. Pick based on lifecycle and sharing needs.
Why managed identities exist
Microsoft calls manual handling of secrets and certificates a known source of security issues and outages. A managed identity removes that: the code asks the platform for a token, and the credentials are not even accessible to you. Microsoft notes it can be used at no extra cost, and that it can authenticate to any resource that supports Entra authentication, including your own apps.
Typical flow:
- Create the identity, system-assigned or user-assigned.
- Authorize it on the target service, for example a storage account, with an Azure role.
- Code uses the Azure SDK or MSAL to get a token. No secret in config.
The two types compared
- Creation: System-assigned: With the Azure resource; User-assigned: Standalone resource
- Lifecycle: System-assigned: Same as the resource. Deleted when it is deleted; User-assigned: Independent. Must be deleted explicitly
- Sharing: System-assigned: One resource only; User-assigned: Many resources
When to choose which
System-assigned fits a workload that lives in a single resource, or where each instance should have its own identity. An app on one virtual machine is the usual example. Cleanup is automatic, so you do not accumulate orphaned identities.
User-assigned fits workloads spread across several resources that should share one identity. Microsoft also lists cases where resources are recycled often but permissions should stay the same, and cases that need preauthorization to a secure resource as part of provisioning.
Microsoft says user-assigned identities are the recommended type for Microsoft services.
Security tradeoffs
The shared nature of user-assigned identities has a cost. If ten resources share one identity, a compromise of any one of them gets the permissions for all ten. Keep shared identities for resources that truly need the same access, and grant only the roles required.
System-assigned identities limit the blast radius, since each resource carries its own, but they can lead to many role assignments to maintain. Automate those assignments in your deployment code.
Orphans are the other risk. A user-assigned identity that nobody uses keeps its role assignments. Review for identities with no attached resources.
Visibility
Both types produce create, read, update and delete records in the Azure activity log, and sign-in activity appears in Entra sign-in logs. That helps with attribution.
Federation
For applications registered in Entra ID, Microsoft describes using a managed identity as a federated identity credential, so the application needs no secret or certificate of its own. Microsoft recommends this as the credential-free route when an Entra app is required, and notes a limit of 20 federated credentials per app when using managed identities this way.
Quick check
Can I move from system-assigned to user-assigned later?
They are different identities with different object IDs, so you will need to grant the new one its role assignments and update anything that referenced the old one. Plan for that rather than assuming a switch.
Do managed identities remove the need for RBAC?
No. The identity still needs roles on the resources it accesses. It only removes the stored secret.
Sources
Last reviewed: 19 October 2026.
