You enable a managed identity by turning it on for the web app in Azure App Service and then using that identity to access other Azure resources. After enabling it, grant the identity only the permissions it needs on the target resource and verify the app is using the intended system-assigned or user-assigned identity.
How to turn on managed identity in App Service
In Azure App Service, managed identity is enabled at the web app level, then the app uses that identity to authenticate to other Azure services without storing a separate secret in code or configuration. The practical question is not just switching it on, but confirming which identity type you enabled and which downstream resource permissions it now needs.
For a system-assigned identity, Azure creates and binds the identity to that specific web app. For a user-assigned identity, the identity exists independently and can be attached to one or more apps. The choice matters because it changes the lifecycle: system-assigned identities usually follow the app, while user-assigned identities are managed separately and can survive app replacement or redeployment.
The cleanest way to think about the enablement step is that Azure is giving the app a trusted workload identity. That identity can then request access tokens for supported Azure resources, but it is still only one half of the setup. You must also grant the identity access on the target service, otherwise the app is enabled but effectively not authorized to do anything useful.
Cloud Workload Identity Guide is the best starting point when you want the broader pattern behind Azure managed identities, including how workload identities replace static keys and where service principals fit into the model.
What changes after the identity is enabled
Once managed identity is on, your web app should stop relying on embedded credentials for supported Azure integrations. Instead, the application asks Azure for a token, and Azure evaluates the app’s identity and assigned permissions. That reduces secret handling, but it also means the app’s runtime identity becomes a real access boundary that needs ownership and review.
In practice, this is where teams often blur identity creation with authorization. Enabling the identity only establishes who the app can be. It does not decide what the app can read, write, start, delete, or enumerate. Those permissions still have to be assigned explicitly on the specific resource, scope, and role or access policy that fits the use case.
The difference between system-assigned and user-assigned identity also matters operationally. If you are connecting one app to a small set of Azure resources, system-assigned identity is usually simpler. If multiple apps need the same stable identity, or you need an identity that outlives a single app deployment, a user-assigned identity is often easier to govern and rotate through platform changes.
Azure RBAC and Service Principals Guide is useful when you need to understand the permission side of the setup, especially role assignment scope and least-privilege design for Azure identities.
How to verify the app is using the right identity
After enablement, verification is essential because App Service can expose more than one identity mode in the same environment. You want to confirm the application is using the intended system-assigned or user-assigned identity, not a leftover credential path, stale connection string, or a broader identity attached for convenience. The verification step is what prevents the identity change from existing only in the portal.
Check the identity selection in the App Service configuration, then test an actual downstream call, such as Key Vault, Storage, or another Azure resource, using the app’s runtime path. If the call succeeds with the intended permissions and fails outside the assigned scope, that is a good sign the setup is behaving as expected. If it succeeds with broader access than expected, the problem is usually in the role assignment or in inherited permissions, not in the managed identity feature itself.
Top 10 NHI Issues helps frame the common mistakes to look for after enabling the identity, especially excessive permissions, ownership gaps, and lifecycle drift.
Risk and Threat Considerations
Managed identity reduces secret exposure, but it does not remove access risk. If the app is granted broad permissions, a compromise of the web app can become a compromise of every resource that identity can reach. The main failure mode is over-authorization, where the identity is treated as harmless because it has no visible password or key.
Failure mechanism: The app identity is enabled correctly, but it is assigned more scope than the workload needs, or it remains attached to resources after the application’s purpose changes.
Impact: An attacker who gains code execution, deployment access, or a foothold in the app can use the managed identity to access Azure resources, move laterally, or exfiltrate data through legitimate token-based access.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 addresses the attack and risk surface, while NIST SP 800-53 Rev 5 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-9 — Identification and Authentication (Non-Organizational Users) | Managed identity is workload authentication to Azure resources. |
| AC-6 — Least Privilege | The identity must receive only the permissions the app needs. | |
| IA-5 — Authenticator Management | Managed identity lifecycle still requires control over credential-like access material and rotation paths. | |
| Recommendation — Apply IA-9 to authenticate the app as a non-human workload to Azure services. Restrict the managed identity to the minimum Azure permissions required. Manage the identity’s access material and lifecycle so unused access is removed promptly. | ||
| NIST Zero Trust (SP 800-207) | Never trust, always verify | Managed identity access should be verified at runtime before trust is granted. |
| Recommendation — Verify each token request and resource access path before allowing production use. | ||
| OWASP Non-Human Identity Top 10 | NHI-05 — Overprivileged NHI | Managed identity becomes risky when granted broader access than the app needs. |
| Recommendation — Audit the managed identity’s roles and remove any excess privileges. | ||
Practitioner Guidance
What to verify: Confirm the app is using the expected identity type, and verify the token works only against the exact target resource and scope it should reach. If the app can access multiple environments from one identity, treat that as a governance issue, not a convenience feature.
Decision rule: Use system-assigned identity when the identity should die with the app, and user-assigned identity when the identity must be shared, reused, or managed independently. If you are unsure which model you need, decide based on lifecycle and blast radius first, not on implementation speed.
Practitioner takeaway: The real control is not enabling managed identity, it is proving the application uses the intended identity with narrowly scoped permissions and no hidden fallback credentials.
Related resources from NHI Mgmt Group
- How do you enable built-in authentication on Azure App Service?
- What breaks when a low-privileged Azure user can edit a managed identity enabled Function App or Logic App?
- How do you enable Kubernetes RBAC on Azure Kubernetes Service clusters?
- How should teams reduce the risk of orphaned service accounts and stale tokens?