Managed identities solve a deceptively simple problem: Azure workloads need to authenticate to other services, but applications should not carry long-lived secrets in configuration files, deployment variables or source code. Azure managed identities give supported resources an identity in Microsoft Entra ID so they can request tokens and access downstream services without developers manually storing credentials.
The feature sounds simple enough that teams often stop at “turn on identity and assign a role.” Production design is more involved. You still have to choose between system-assigned and user-assigned identities, decide how permissions are scoped, understand lifecycle behavior, avoid excessive role assignments and plan for token caching and operational ownership. These are core skills for AZ-104, AZ-305 and modern cloud security roles.
Managed identity removes stored credentials, not authorization design
A managed identity allows a workload to obtain a Microsoft Entra access token without embedding an application secret or certificate that developers have to rotate manually. That reduces credential leakage and removes a large operational burden.
It does not automatically grant access. The identity still needs authorization on the target resource, usually through Azure RBAC or a service-specific access model. A VM with a managed identity cannot read a Key Vault or storage account unless the identity has the required permission.
This separation is important. Authentication answers “which workload is calling?” Authorization answers “what may that workload do?” Teams that enable managed identity and then assign Contributor at subscription scope have removed a secret but created an excessive-permission problem. The RBAC model still has to follow least privilege.
System-assigned identities follow the resource lifecycle
A system-assigned managed identity is created on an Azure resource and is tied directly to that resource. Delete the resource and the identity is deleted as part of the lifecycle. This is useful when the permission set should belong to exactly one workload and should disappear when that workload disappears.
The tight lifecycle is operationally convenient for unique resources. It also improves audit clarity when security teams want each resource to have its own principal. If one VM reads a secret, the access log can point to that VM’s identity rather than a shared identity used by many services.
The tradeoff is scale. If ten identical resources require the same permissions, ten system-assigned identities can mean ten role assignments and more objects to manage. Deployment ordering can also matter because the identity may not exist until the resource has been created, while a downstream permission assignment may need the principal identifier.
User-assigned identities can be shared and pre-provisioned
A user-assigned managed identity is an Azure resource with a lifecycle independent of the compute or application resources that use it. The same identity can be assigned to multiple supported resources. It can also be created before those resources exist.
This is useful for replicated workloads. If several identical application instances all need read access to the same storage account and secrets, one user-assigned identity can reduce the number of role assignments and make deployment permissions easier to control. Microsoft currently recommends user-assigned managed identities for a broad range of scenarios for exactly these operational reasons.
Shared identity is not automatically better. If each workload should have a distinct audit trail or different permissions, a shared user-assigned identity can hide useful separation. It can also increase blast radius: compromise of any workload that can use the shared identity potentially exposes all permissions granted to that identity.
The decision is therefore about lifecycle and trust boundaries, not about which type is newer. Use a shared user-assigned identity when the resources genuinely represent the same security principal. Use separate identities when independent accountability or permission boundaries matter.
Design role assignments around the target action
The most important security rule is to grant the smallest permission that allows the workload to do its job. If an application only reads blobs, do not give its managed identity broad Contributor rights. If it only needs one Key Vault, do not grant access across the subscription.
Scope is as important as role. Azure RBAC can be applied at management group, subscription, resource group or individual resource scope. Managed identities used by applications usually benefit from narrower scopes because their access requirements are specific. Broad scope may be administratively convenient but makes a compromised workload more damaging.
Service-specific data-plane roles also matter. A management-plane Contributor role does not necessarily grant the data access an application needs, and a data-plane role does not necessarily allow infrastructure changes. Engineers should know which control plane the application is actually using.
Permission changes may not take effect instantly
Managed identity tokens are cached by Azure infrastructure. That improves resilience and performance, but it means some authorization changes can take time to appear in effective tokens. This is especially important when permissions are derived through group or role claims.
Teams often discover this during troubleshooting: an identity is removed from a group, but a workload continues to behave as if the old permissions exist for a period of time. Restarting the application does not necessarily force the underlying managed identity infrastructure to issue a fresh token immediately.
This is one reason Microsoft recommends direct permission assignment to a user-assigned identity in scenarios where rapid permission changes matter, rather than relying on changing group membership around managed identities. Operational designs should account for propagation behavior instead of treating every role change as instantly effective.
Use identities to separate deployment from runtime privileges
One of the strongest managed-identity patterns is to give the deployment process different privileges from the running application. Infrastructure automation may need permission to create resources and assign identities. The application itself should only receive the minimal runtime permissions it needs.
User-assigned identities can help because they may be created and granted access before a workload is deployed. The team that provisions infrastructure can assign the approved identity to the resource without granting the application or its developers permission to create arbitrary identities or role assignments.
This separation supports mature platform engineering. Application teams get a predictable security primitive while central teams retain control over high-impact authorization decisions. The model also fits broader cloud architecture patterns in which identity is part of workload design rather than an afterthought.
Managed identities work best with services that support Entra authentication
The value of managed identity is highest when the target service can accept Microsoft Entra tokens directly. Azure Key Vault, Storage and many Azure platform services support this model. Application code can use an Azure SDK credential chain or workload-specific library to request a token rather than reading a secret.
Developers should still understand failure modes. Token acquisition can fail because the identity is not assigned, the wrong client ID is selected, the target audience is incorrect or the identity lacks authorization. “Managed” does not mean “no troubleshooting.” It means Azure manages the credential material and token issuance.
Code should also avoid falling back silently to developer credentials in production. Default credential chains are convenient, but production behavior should be predictable enough that engineers know which identity is actually authenticating.
Security review questions
- Does this workload need its own identity, or is a shared user-assigned identity appropriate?
- Are role assignments scoped to the smallest target resources that satisfy the requirement?
- Can the workload modify its own identity or grant itself additional permissions?
- Does the identity have management-plane rights it does not need for runtime access?
- Would sharing this identity across multiple resources create an unacceptable blast radius?
- Is the audit trail clear enough to identify which workload used the identity?
- Do deployment pipelines account for identity creation and authorization dependencies?
Managed identities are most valuable when they remove secret management without hiding authorization discipline. The best design makes the workload’s identity explicit, grants narrowly scoped permissions and aligns identity lifecycle with resource lifecycle. That is more secure than rotating application secrets forever—and much more useful than simply turning on a managed identity and giving it broad access.
For candidates building deeper Azure platform skills, managed identities connect directly to the Azure infrastructure certification family, because identity design appears across compute, automation, Key Vault, storage and application architecture.
Common implementation mistakes
A frequent mistake is assigning both a system-assigned and a user-assigned identity to a resource without making application behavior explicit. When code uses a generic credential chain and several identities are available, troubleshooting becomes difficult. Production applications should clearly select the intended identity when ambiguity is possible.
Another problem is using a user-assigned identity as a universal “application identity” across unrelated workloads. Reuse can reduce role assignments, but sharing across trust boundaries means one compromised workload may inherit permissions intended for another. Treat identity reuse the same way you would treat a shared service account: only resources with the same authorization needs and risk profile should share it.
Teams also sometimes grant access to a managed identity through a broad Microsoft Entra group because that resembles human access management. Managed-identity token caching can make group-membership changes slow to take effect. Where rapid permission revocation matters, direct assignments to a purpose-built user-assigned identity can provide a more predictable operating model.
Finally, remember that deleting a system-assigned identity removes the principal but does not automatically clean every dependent assumption in application configuration. Infrastructure code, monitoring and target-service permissions should be reviewed so orphaned role assignments and broken dependencies do not accumulate.