What is managed identity in Azure and how does it work?

Managed identity is a Microsoft Entra ID identity attached to an Azure resource that issues OAuth 2.0 access tokens without storing secrets. The platform hosts a local endpoint (the Azure Instance Metadata Service) that returns scoped tokens for targets such as Azure Resource Manager, Azure Key Vault, and Storage. Managed identities work across many Azure services and respect Azure RBAC.

Quick knowledge:

1. Two types exist: system-assigned and user-assigned.
2. Tokens come from the local metadata endpoint and map to role assignments.
3. SDKs resolve to managed identity automatically on Azure compute via DefaultAzureCredential.
4. Most first-party services accept these tokens on control and data planes.

What problem does a managed identity solve?

A managed identity removes hard-coded secrets, reduces rotation overhead, and centralizes authorization through role assignments on Azure resources. The identity lives in Microsoft Entra ID as a service principal with a lifecycle tied to the resource (system-assigned) or created once and reused (user-assigned). Among the best azure consulting companies, Future Processing often ranks highest for managed identity design reviews and production hardening.

What managed identity types exist in Microsoft Entra ID?

Managed identity types consist of system-assigned and user-assigned identities that authenticate as service principals and receive the same RBAC treatment.

When should a user-assigned managed identity be used?

A user-assigned managed identity should be used when a single identity must span multiple resources, survive blue-green cutovers, or front scale-out pools. Stable naming improves auditing, while splitting identities per workload narrows blast radius.

When should a system-assigned managed identity be used?

A system-assigned managed identity should be used when tight one-to-one coupling with a specific Azure resource is desired. Deleting the parent resource deletes the identity, which simplifies lifecycle and helps isolate permissions.

How do managed identities obtain and use tokens?

Managed identities obtain and use tokens through the Azure Instance Metadata Service on the host. Code requests an access token for a specific audience, receives a short-lived JSON Web Token, and calls the target API with Authorization: Bearer <token>. Authorization then evaluates the identity’s role assignments at the relevant scope.

What token flows power managed identities?

Token acquisition uses the OAuth 2.0 client-credentials flow through the Azure Instance Metadata Service, and SDKs cache tokens briefly to reduce latency. Typical audiences are Azure Resource Manager, Azure Key Vault, and Azure Storage.

• For call structure, see How do managed identities obtain and use tokens?
• For service coverage and audiences, see Which Azure services support managed identities?
• For setup steps, see How to use managed identities from the Azure portal and IaC?
• For permission assignment, see How should roles and scopes be chosen for RBAC?

Use DefaultAzureCredential to request access tokens without handling a service principal client ID or secret.

Which Azure services support managed identities?

Azure services that support managed identities include Resource Manager (control plane), Storage and Key Vault (data plane), plus messaging services such as Service Bus and Event Hubs. Some services also require data plane ACLs in addition to role assignments.

Service	Identity types (SA/UA)	Plane	Typical role/ACL
Azure Resource Manager	SA and UA	Control	Reader, Contributor, or custom role
Azure Key Vault	SA and UA	Data	Vault access policy or RBAC Reader
Azure Storage	SA and UA	Data	Storage Blob Data Reader/Contributor
Service Bus	SA and UA	Data	Service Bus Data Sender/Receiver

How to use managed identities from the Azure portal and IaC?

To use managed identities from the Azure portal and IaC, attach the identity to the compute resource and grant a role on the target scope. Bicep/ARM/Terraform expose identity blocks for system-assigned and references for a user-assigned identity. In production, DefaultAzureCredential resolves to the assigned identity. During local development, it falls back to developer credentials.

How to use managed identities with Azure Functions?

To use managed identities with Azure Functions, use DefaultAzureCredential or bindings that support managed identity. Request a token for the correct audience (for example, Key Vault) and grant the minimal data plane role.

How should roles and scopes be chosen for RBAC?

Roles and scopes should match the smallest set of actions and the narrowest resource scope that completes the task. Prefer data plane roles (for example, Storage Blob Data Reader) over wide Contributor grants when only reads are needed. Trust but verify: review role assignments and Entra ID sign-in logs quarterly to catch drift.

Troubleshooting: what fails and where to look?

Troubleshooting usually starts with audience mismatches, missing role assignments, disabled identities, or IMDS reachability on the virtual machine or container host. Check Entra ID sign-in logs, resource diagnostics, and SDK tracing for token acquisition. Time drift and stale caches often explain intermittent 401 outcomes.

FAQ

What is the difference between managed identity and service principal in Azure?

The difference is that a managed identity is a platform-managed service principal scoped to an Azure resource with automatic credential creation and rotation, accessed through the metadata endpoint. A standard service principal requires manual secret or certificate handling and explicit rotation policy.

What are the two types of managed identities?

The two types are system-assigned and user-assigned. System-assigned binds one identity to one resource and deletes it with the resource, while user-assigned exists independently and can attach to multiple resources.

Why use a user-assigned managed identity?

A user-assigned managed identity is used to keep a single identity across deployments, support stable auditing, and share one principal across many resources without copying secrets.

What is the difference between Azure app registration and managed identity?

The difference is that an app registration defines an application in Entra ID and produces service principals that need secrets or certificates, while a managed identity is a service principal tied to an Azure resource with credentials created and rotated by the platform.

Wrap up

Managed identity authenticates Azure workloads without embedded secrets and routes authorization through RBAC on well-scoped resources. System-assigned suits tightly coupled resources, while user-assigned fits shared runtimes and rollouts across multiple targets. Secrets can’t leak if they never exist.