Azure Managed Identities Security Guide

Managed identities remove the secret from Azure workloads, but they do not remove the privilege, and anyone who can run code where the identity is attached inherits everything it can do. Microsoft positions managed identities as the default way for Azure compute to reach Key Vault, Storage, SQL, Microsoft Graph and anything else that accepts Microsoft Entra tokens, and that is the right default. The security problems move elsewhere: oversized role assignments, user-assigned identities shared across unrelated workloads, people who can attach identities to resources they control, federated credentials that trust the wrong subject, and logs nobody reads. This guide covers how managed identities work, which roles control them, how they connect to federation and Graph, what to log, a hardening baseline with a phased rollout, and the misconfigurations seen most often. It is written for Azure platform engineers, cloud security architects and identity teams who own non-human identities in Entra ID.

Key takeaways

The resource is the security boundary. Microsoft states that all code and scripts on a VM can request tokens for any managed identity available on it, so identity selection is not a control between processes.
Attaching an identity is a privilege escalation path. Whoever holds Microsoft.ManagedIdentity/userAssignedIdentities/*/assign/action (Managed Identity Operator) can give a resource they control every permission of that identity.
Revocation is slow by design. Managed identity tokens are cached per resource URI for about 24 hours and cannot be forced to refresh, so removing a group membership is not an emergency control.
Conditional Access does not cover them. Microsoft's Conditional Access for workload identities documentation says managed identities are not covered by policy, so scoping and monitoring carry the whole load.
Cleanup is manual. Role assignments outlive deleted identities, user-assigned identities outlive their workloads, and both need a recurring inventory and removal process.

How identity and access work in Azure managed identities

A managed identity is a special type of service principal in Microsoft Entra ID whose credential Azure creates, stores and rotates. Workload code asks a local endpoint for a token, never sees a secret, and presents the token to the target service. Microsoft documents that the backing credential is certificate based, expires after 90 days and is rolled after 45 days, and describes this as an implementation detail that may change. Managed identities have a service principal but no application object, so Microsoft Graph application permissions are granted directly to the service principal.

Token flow on a virtual machine

Endpoint: the Azure Instance Metadata Service (IMDS) at http://169.254.169.254/metadata/identity/oauth2/token, with api-version=2018-02-01 or later and a resource parameter that becomes the token's aud claim (for example https://management.azure.com/).
Header: Metadata: true is mandatory. Microsoft describes it as the mitigation against server-side request forgery (SSRF), because a naive SSRF primitive usually cannot set custom headers.
Identity selection: when several user-assigned identities are attached, the caller chooses one with client_id, object_id or msi_res_id. Any local process can pass any of these values.
Lifetime: the sample response shows expires_in of about one hour, there is no refresh token, and Microsoft advises caching tokens in code and not placing IMDS behind a proxy.

App Service, Functions, Logic Apps, Container Apps, AKS and other hosts expose equivalent local endpoints or connectors; the SDKs (Azure.Identity and MSAL) hide the difference. See the Cloud Workload Identity Guide for the cross-cloud pattern this follows.

System-assigned or user-assigned

Property	System-assigned	User-assigned
Created as	Part of one Azure resource	Standalone resource (`Microsoft.ManagedIdentity/userAssignedIdentities`)
Lifecycle	Deleted with the resource	Independent; must be deleted explicitly
Sharing	One resource only	Can be attached to many resources of any type
Pre-authorisation before deployment	Not possible: the identity does not exist until the resource does	Possible: roles can be granted before the workload is built
Audit attribution	Logs name the specific resource	Logs name the identity, which may be shared
Federated identity credentials	Not supported	Up to 20 per identity
Main risk	Identity sprawl at scale, rate limits on rapid creation	Blast radius and escalation through sharing and assignment

Decision guidance: Microsoft's best practice article recommends user-assigned identities for ephemeral or replicated compute, approval-heavy environments and pre-provisioned access, and system-assigned identities where per-resource audit attribution and automatic permission removal matter. A practical rule: one user-assigned identity per application tier and environment (never shared between production and non-production, never shared across business applications), and system-assigned identities for single-purpose resources such as an automation account that runs one job. Small organisations can live with a handful of user-assigned identities managed by the platform team; large estates need naming standards, an owner tag and an inventory pipeline before the count runs into thousands, because each identity counts toward the tenant directory object quota and creation is blocked at 98 per cent usage.

Admin roles and privileged access

Three separate permission sets decide what a managed identity can do and who can use it. Treat each as privileged.

Permission	Granted by	What it allows	Why it matters
Create, update, delete user-assigned identities and their federated credentials	Managed Identity Contributor (also Contributor, Owner)	`userAssignedIdentities/write`, `federatedIdentityCredentials/write`, `revokeTokens/action`	Adding a federated credential lets an external workload, such as a CI pipeline, act as the identity
Attach a user-assigned identity to a resource	Managed Identity Operator (also Contributor, Owner)	`userAssignedIdentities/*/assign/action`	Attaching an identity to a VM or Logic App you control gives you its permissions
Run code on a resource with an identity	Virtual Machine Contributor, Website Contributor, Logic App Contributor, Automation roles, Contributor and similar	Run Command, extensions, deployments, workflow edits	Code execution equals token access; Microsoft's example shows a user with no storage rights reading and writing storage through a Logic App's identity
Grant the identity access	Owner, User Access Administrator, Role Based Access Control Administrator; Entra roles for Graph app roles	`Microsoft.Authorization/roleAssignments/write`, app role assignment	Defines the blast radius of every resource the identity is attached to

Scope Operator narrowly: assign Managed Identity Operator at the individual identity, not the subscription. Deployment pipelines need it; developers usually do not.
Treat code-execution roles as identity roles: before granting a role on a resource that hosts an identity, check whether it allows installing or running code. If it does, the holder effectively holds the identity's permissions. This is the same pattern as the management-plane-to-data-plane jump in the Azure Key Vault Contributor Escalation, where a role described as having no data access could grant itself vault contents.
Use PIM for the humans: Owner, User Access Administrator and Managed Identity Contributor on production identities should be eligible, not active. See the Azure RBAC and Service Principals Guide for RBAC scoping and PIM detail.
Keep identities out of directory roles: a managed identity holding Global Administrator, Privileged Role Administrator or Graph permissions such as RoleManagement.ReadWrite.Directory turns any code execution on its host into tenant compromise. Entra access reviews can include service principals in privileged directory roles; Microsoft suggests access reviews as the governance route for managed identities that Conditional Access cannot reach.

Integrations, API tokens and service accounts

Managed identities replace most stored secrets, but they connect to other credential types in ways that need review.

Federated identity credentials (FICs) on user-assigned identities: an external issuer (AKS OIDC issuer, GitHub Actions, Google Cloud) is trusted for an exact issuer and subject, with audience api://AzureADTokenExchange. Wildcards are not supported and the issuer plus subject pair must be unique. Microsoft notes that a wrong subject is accepted silently at creation and fails only at exchange time, so review FICs by reading them, not by waiting for errors. Prefer GitHub environment-scoped subjects over branch or pull request subjects for production. See the Workload Identity Federation Guide for issuer and subject design.
Managed identity as a credential for an Entra application: an app registration can trust a managed identity as a federated credential, which Microsoft calls the recommended way to be credential-free when an application object is required (for example for multi-tenant access). The limit is 20 such FICs per application. This removes client secrets and certificates from app registrations; see the Entra ID Applications and Consent Guide for the application side.
Kubernetes: on AKS the subject is system:serviceaccount:<namespace>:<serviceaccount>. Anyone who can create pods with that service account in that namespace obtains the identity, so Kubernetes RBAC on the namespace is part of the identity's access control.
Microsoft Graph: application permissions are assigned to the managed identity's service principal (PowerShell or Graph API, not the portal consent screen). Inventory these separately from Azure RBAC; Graph permissions such as Mail.Read or Sites.ReadWrite.All often outweigh any Azure role the identity holds.
Residual secrets: connection strings, storage account keys, SAS tokens and Cosmos DB keys still in app settings bypass the identity entirely. Disable shared key access and local authentication where the service allows it once the identity path works. See the Cloud Secrets Managers Guide for the secrets that remain.
Cross-tenant limits: Microsoft states managed identities do not support cross-directory scenarios, and moving a subscription to another directory requires re-creating identities and role assignments. Plan tenant migrations around this.

Logging and detection

Two planes produce evidence. The Azure Activity log records control-plane changes to identities, attachments and role assignments. The Entra managed identity sign-in log records token issuance, grouped into one row per identity, status and resource, with individual sign-ins and timestamps available on expansion. Token caching means far fewer sign-in entries than API calls, so absence of sign-ins is weak evidence of inactivity. Export both to a SIEM through diagnostic settings; portal retention depends on licence.

Signal	Source	What to alert on	ATT&CK
Role assignment created for a managed identity principal	Activity log, `Microsoft.Authorization/roleAssignments/write`	Owner, Contributor or User Access Administrator at subscription or management group scope; any assignment outside the deployment pipeline	T1098.003 Additional Cloud Roles
User-assigned identity attached to a resource	Activity log, resource write with `identity` block changes	Production identity attached to a VM, Logic App or Automation account not in its approved list	T1078.004 Cloud Accounts
Federated identity credential added or changed	Activity log, `federatedIdentityCredentials/write`	New issuer, new subject, or any change outside change control	T1098.003, T1078.004
Code execution on an identity-bearing host	Activity log (VM Run Command, extension writes, Logic App workflow writes)	Run Command by a human on a VM whose identity has write access to data stores	T1552.005 Cloud Instance Metadata API
Managed identity sign-ins	Entra managed identity sign-in log	First-seen resource (audience) for an identity, failures spiking, sign-ins from an identity with no expected workload	T1528 Steal Application Access Token
Data-plane use	Key Vault, Storage, SQL diagnostic logs	Identity reading secrets or blobs it has never touched before, bulk reads	T1078.004

Microsoft Defender for Cloud includes the recommendations "Azure overprovisioned identities should have only the necessary permissions" and "Permissions of inactive identities in your Azure subscription should be revoked", which give a starting list for right-sizing.

Metrics that show the programme is working:

Percentage of managed identities with a role at subscription scope or above (target: near zero outside platform automation).
Number of user-assigned identities attached to resources in more than one application or environment.
Orphaned role assignments (ObjectType Unknown) found per month, trending to zero.
Number of principals holding Managed Identity Operator or Contributor at subscription scope.
Share of workloads still using connection strings or account keys where a managed identity path exists.
Median time from an unapproved FIC or role assignment to alert triage.

Framework mapping

Control area	NIST SP 800-53 Rev. 5	NIST CSF 2.0	ATT&CK techniques addressed
Inventory and ownership of identities	AC-2 Account Management, CM-8 System Component Inventory	PR.AA-01	T1078.004
Least privilege role assignments	AC-6 Least Privilege	PR.AA-05	T1098.003
Service authentication without stored secrets	IA-9 Service Identification and Authentication, IA-5 Authenticator Management	PR.AA-01	T1552.005, T1528
Logging and review	AU-12 Audit Record Generation, AU-6 Audit Record Review, Analysis, and Reporting	DE.CM-03	All of the above

Hardening baseline

Scope: grant data-plane roles (Storage Blob Data Reader, Key Vault Secrets User) on the specific resource, not Contributor on a resource group or subscription. Read-only workloads get read-only roles.
Isolation: one identity per application tier per environment; no identity shared between production and non-production.
Assignment control: Managed Identity Operator only for deployment pipelines, scoped to the identity; Azure Policy or pipeline checks to block attachment of production identities outside approved resource groups.
Direct permissions: assign roles directly to the user-assigned identity rather than through group membership, because Microsoft notes group changes can take hours to reach a cached managed identity token.
Host hardening: on VMs, restrict who can log in, use Run Command and install extensions; on web apps, fix SSRF and avoid features that let users supply arbitrary URLs or headers. Containers on a node share the node's IMDS unless network policy blocks it, so use per-pod workload identity on AKS.
Secret removal: disable storage account key access, SQL local authentication and similar where supported once identity access is proven.
Lifecycle: owner and application tags on every user-assigned identity; scheduled removal of orphaned role assignments; deletion of unattached identities after a grace period.

Phased rollout

Inventory (weeks 1 to 2): list identities with az resource list --query "[?identity.type=='SystemAssigned']" and the user-assigned identity resources, then join to role assignments, Graph app role assignments and FICs. Record owner, environment and attached resources.
Turn on evidence (week 2): export Activity logs and Entra sign-in logs, including managed identity sign-ins, to the SIEM and build the alerts in the table above in report-only form.
Remove the worst exposure (weeks 3 to 4): drop subscription-scope Owner and Contributor from identities, remove directory roles and high-impact Graph permissions that are not justified, and narrow Managed Identity Operator holders.
Right-size per workload (weeks 4 to 10): pilot on one non-production application. Add the narrow role alongside the broad one, confirm the data-plane logs show only expected operations for a full business cycle, then remove the broad role. Rollback is re-adding the previous assignment, so record it before removal; remember the roughly 24 hour token cache when judging whether a change has taken effect.
Split shared identities: create per-application identities, attach them, switch the client ID in configuration, verify, then detach the shared identity. Keep the old identity unattached for a short period before deletion so rollback is a configuration change.
Enforce (ongoing): switch alerts to paging for production, add policy and pipeline checks that block broad scopes and unapproved FIC issuers, and run quarterly access reviews.

Common misconfigurations

Contributor on the subscription "to make it work": the identity of a web app or function gets Contributor at subscription scope. An SSRF or code injection on that app then becomes control of the subscription. The Capital One Breach is the AWS equivalent: role credentials obtained through the metadata service carried far more storage access than a firewall needed.
One user-assigned identity for everything: a single "app-identity" attached to dozens of VMs, functions and Logic Apps across environments. Compromise of the least protected test resource yields production permissions, and logs cannot say which resource acted.
Developers holding Managed Identity Operator at subscription scope: they can attach any production identity to a VM they own and act as it, without any role assignment change that would trip an alert.
Relying on group removal for incident response: removing a compromised identity from a privileged group does not take effect until cached tokens expire. Contain by removing direct role assignments, detaching the identity, stopping the host, and for user-assigned identities using the token revocation action available to Managed Identity Contributor, then verify with data-plane logs.
Loose or stale federated credentials: a FIC trusting a GitHub branch subject that any contributor can push to, or one left behind after a pipeline moved. Because creation accepts any subject, these persist unnoticed.
Orphaned role assignments and identities: assignments showing "Identity not found" or ObjectType Unknown, and user-assigned identities with permissions but no attached resource. They inflate inventory, hit subscription role assignment limits and hide real changes. Review with Get-AzRoleAssignment | Where-Object {$_.ObjectType -eq "Unknown"} before removing.

Practitioner checklist

Inventory every system-assigned and user-assigned identity with owner, environment, attached resources, Azure roles, Graph permissions and FICs.
Remove subscription and management group scope Owner, Contributor and User Access Administrator from managed identities unless documented as platform automation.
Restrict Managed Identity Operator and Managed Identity Contributor to pipelines and identity owners, scoped to individual identities.
Review every role that allows code execution on identity-bearing resources as if it granted the identity itself.
Split shared user-assigned identities so none spans environments or unrelated applications.
Review all FICs for exact issuer and subject, and prefer environment-scoped CI subjects for production.
Export Activity logs and managed identity sign-in logs to the SIEM and alert on role assignments, identity attachment and FIC changes.
Write an incident runbook that accounts for the roughly 24 hour token cache: detach, remove direct assignments, revoke tokens where available, stop the host.
Schedule monthly removal of orphaned role assignments and unattached identities.
Disable account keys and local authentication on services once identity-based access is in place.

Azure Managed Identities Security Guide: Scoping, Monitoring and Avoiding Escalation