Skip to main content

Azure Managed Identity Guide: Architecture, Use Cases, and Best Practices

For decades, applications have authenticated to databases, storage, and APIs using credentials—passwords, API keys, connection strings, and certificates. These secrets were often stored in configuration files, environment variables, or even source code. This pattern creates a significant operational burden: secrets must be rotated, access must be audited, and a single leaked credential can compromise an entire system.

In the cloud, identity has become the new security perimeter. Instead of trusting a network boundary, cloud-native applications trust proven, short-lived identities. Azure Managed Identity embodies this principle by giving your applications an identity in Microsoft Entra ID without requiring you to manage any credentials. This guide explains the architecture, patterns, and best practices for using Managed Identity to build secure, maintainable Azure workloads.

What Is Azure Managed Identity?​

An Azure Managed Identity is an automatically managed identity in Microsoft Entra ID that your application can use to authenticate to any service that supports Entra ID authentication. It is not a separate identity store or a new type of user. Under the hood, Azure creates and manages a special type of service principal on your behalf.

The core idea is simple:

  • Your application runs on an Azure resource (a virtual machine, App Service, Function, etc.).
  • Azure gives that resource an identity.
  • Your code asks the Azure Instance Metadata Service (IMDS) for a token for that identity.
  • Your code presents the token to the target Azure service (Key Vault, Storage, SQL Database, etc.).
  • No secrets are stored or transmitted.
ConceptPurpose
User identityAuthenticates a human being, typically with a password, phone, or FIDO2 key.
Service principalAn identity for an application or automation script. Requires manual secret management.
Managed IdentityAn Azure-managed service principal. Azure handles creation, credential rotation, and lifecycle.

Why Use Managed Identity?​

No Secrets​

Managed Identity eliminates the need to embed passwords, client secrets, or connection strings in your application code, configuration files, or CI/CD pipelines. The credential is never exposed; it is obtained dynamically at runtime.

Automatic Credential Lifecycle​

Azure automatically creates the underlying service principal and rotates its credentials. Your application does not need to know when or how this happens—it simply requests a new token from IMDS whenever one is needed.

Better Security​

Reducing the number of long-lived secrets in your environment directly reduces the attack surface. Because each application can have its own identity, you can apply the principle of least privilege with Azure RBAC, granting exactly the permissions required and nothing more.

Developer Productivity​

Developers no longer need to write secret-retrieval code, manage key rotation schedules, or maintain separate configuration for each environment. Calling DefaultAzureCredential in your code is often the only change required.

How Managed Identity Works Internally​

When you enable a Managed Identity on an Azure resource, Azure creates a service principal in the Entra ID tenant linked to your subscription. The resource then gains access to a local REST endpoint—the Azure Instance Metadata Service (IMDS) —available only from within the resource itself.

The flow is:

  1. Your application code requests a token from http://169.254.169.254/metadata/identity/oauth2/token (the standard IMDS endpoint).
  2. IMDS authenticates the caller and forwards the request to Entra ID.
  3. Entra ID issues an OAuth 2.0 access token for the managed identity.
  4. IMDS returns the token to your application.
  5. Your application uses that token to call the target Azure service (e.g., https://vault.azure.net).
  6. The target service validates the token and checks Azure RBAC assignments.

Because the entire credential exchange happens behind the scenes, your code never handles a secret.

Types of Managed Identity​

Azure offers two types, matching different operational models.

System-Assigned Managed Identity​

A system-assigned identity is created on an Azure resource and shares its lifecycle. When you delete the resource, the identity is automatically removed from Entra ID.

Characteristics:

  • Created in the same region as the resource.
  • Can only be used by that specific resource.
  • Deleted automatically—no orphaned identities.
  • Simplest to configure.

When to use: Single-application scenarios where the identity does not need to be shared. For example, a single Azure Function that reads from one Key Vault.

User-Assigned Managed Identity​

A user-assigned identity is a standalone Azure resource. You create it, assign it to one or more Azure resources, and manage its lifecycle independently.

Characteristics:

  • Independent lifecycle—persists even if all assigned resources are deleted.
  • Can be assigned to multiple resources (e.g., a scale set of VMs, several Functions, or an App Service and a Container App).
  • Requires explicit creation and assignment.
  • Enables pre-provisioning of identities and RBAC assignments before resources are deployed.

When to use: Multi-resource or enterprise scenarios where you want a consistent identity with controlled permissions. For example, several microservices that need the same set of permissions, or a CI/CD pipeline that provisions infrastructure before deploying applications.

FeatureSystem-AssignedUser-Assigned
LifecycleTied to resourceIndependent
ReuseSingle resourceMultiple resources
ManagementSimpler (automatic)More control
Common usageSimple, standalone appsEnterprise workloads, shared identities

Managed Identity vs Service Principal​

Developers often confuse Managed Identities with service principals (App Registrations). They both provide application identities, but their management models differ critically.

Managed IdentityService Principal
Credential managementAzure manages credentials automaticallyDeveloper manages secrets, certificates, or federation
Secret requiredNoYes (client secret or certificate) unless federated
Best forAzure workloads (VMs, App Service, Functions, AKS)External applications, CLI tools, multi-tenant apps
RotationAutomaticManual or via automation

When NOT to use a Managed Identity:

  • Your application runs outside Azure and cannot use workload federation.
  • You need to authenticate with a service that does not support Entra ID authentication.
  • You need to share the identity across tenants (Managed Identities are tenant-scoped).

Managed Identity Authentication Flow (in detail)​

Let's walk through a concrete example: an App Service web application accessing Azure Key Vault.

Your application only needs to know the resource URI (e.g., https://vault.azure.net for Key Vault). The SDKs handle the token request and caching automatically.

Granting Permissions with Azure RBAC​

A Managed Identity provides an identity. It does not automatically provide any access. Access is granted separately through Azure role-based access control (RBAC). The model is:

Identity + RBAC Role Assignment = Access

You must assign a role to the managed identity at the desired scope (subscription, resource group, or individual resource). Common built-in roles include:

  • Reader – Read-only access to resources.
  • Contributor – Full management except granting access.
  • Storage Blob Data Reader – Read blobs.
  • Storage Blob Data Contributor – Read, write, delete blobs.
  • Key Vault Secrets User – Read secret values.
  • Azure SQL Database roles – For Entra ID authentication to databases.

Always follow the principle of least privilege: grant only the roles required for the specific task, at the narrowest scope possible.

Managed Identity with Common Azure Services​

Azure Key Vault​

This is the most common starting point. Instead of storing a Key Vault client ID and secret in appsettings.json, your App Service uses its managed identity to retrieve secrets directly.

App Service -> Managed Identity -> Key Vault (get secret)

Your code needs only the Vault URI; the SecretClient from the Azure SDK handles the rest.

Azure Storage​

Enable the managed identity and grant the Storage Blob Data Contributor role on the storage account or container. No more storage account keys in connection strings.

Azure SQL Database​

Create the managed identity as an external user in the database (CREATE USER [app-name] FROM EXTERNAL PROVIDER), grant the required database roles, and use Authentication=Active Directory Managed Identity in the connection string.

Azure Cosmos DB​

Similar to Storage, assign the appropriate Cosmos DB data plane role and use the DefaultAzureCredential class in the SDK.

Azure Kubernetes Service (AKS)​

AKS supports workload identity, which federates a Kubernetes service account with a user-assigned managed identity. Pods can securely access Azure resources without mounting secrets. This is the recommended approach for AKS workloads.

Managed Identity for AI Applications​

Modern AI applications often touch many Azure services: Blob Storage for training data, Azure AI Search for vector stores, Azure OpenAI for inference, and Cosmos DB for metadata. Managing API keys for each service is fragile and insecure.

With Managed Identity, each component can have its own scoped identity:

For a retrieval-augmented generation (RAG) application:

  • The ingestion pipeline has a managed identity that reads from Blob Storage and writes to Azure AI Search.
  • The query API has a different managed identity that queries Azure AI Search and calls Azure OpenAI.
  • No API keys are stored in the application code, Key Vault, or environment variables.

This pattern reduces the blast radius of a compromised component and makes key rotation a non-issue.

Managed Identity in Cloud-Native Architecture​

Microservices​

In a microservice architecture, each service should have its own managed identity. This ensures that the Order Service cannot accidentally access the Payment Service's database.

Event-Driven Systems​

An Azure Function triggered by a Service Bus queue can use its managed identity to connect to the queue, read messages, and write results to Cosmos DB, all without connection strings.

CI/CD Pipelines (Secretless Deployment)​

GitHub Actions and other CI/CD tools can use Workload Identity Federation to exchange an external token (e.g., a GitHub OIDC token) for an Entra ID token linked to a user-assigned managed identity. This enables pipeline deployment to Azure without storing any Azure credentials as GitHub secrets.

Managed Identity Security Best Practices​

  • Prefer Managed Identity over secrets for all Azure-to-Azure communication.
  • Apply least privilege RBAC – assign only the specific data-plane roles required, and scope them to the individual resource (e.g., a single Key Vault, a single storage container).
  • Separate identities between environments – use different managed identities for dev, test, and production. User-assigned identities help with pre-provisioning.
  • Avoid shared identities – each application or microservice should have its own identity unless there is a deliberate reason to share.
  • Monitor identity usage – enable diagnostic logging on your Azure resources and review sign-in logs in Entra ID to detect anomalous token usage.
  • Review role assignments – regularly audit which roles are assigned to your managed identities using Azure Policy or periodic manual reviews.
  • Use Azure Monitor and Microsoft Sentinel – create alerts for unexpected RBAC changes or unusual access patterns.

Common Mistakes​

  • Giving excessive RBAC permissions – granting Contributor or Owner to a managed identity that only needs to read a single secret. Start with the narrowest role.
  • Using one identity for all applications – a single shared identity creates a large blast radius. If one application is compromised, all resources accessible to that identity are at risk.
  • Confusing identity with authorization – enabling a managed identity does not grant access; you must still assign RBAC roles.
  • Granting Owner role unnecessarily – Owner grants the ability to manage access, which is almost never required by an application.
  • Hardcoding service principal secrets – if you find yourself creating a service principal with a client secret for an Azure workload, stop and use a managed identity instead.
  • Ignoring unused identities – when resources are decommissioned, their system-assigned identities are automatically deleted, but user-assigned identities must be cleaned up manually.

Managed Identity Architecture Patterns​

Web Application Pattern​

The App Service uses its identity to fetch the SQL connection string from Key Vault and then authenticates to SQL using the same identity.

AI RAG Application Pattern​

Separation of duties: the ingestion pipeline can write to storage and search, but cannot call the OpenAI model. The query API can read search and call OpenAI, but cannot write documents.

Microservices Pattern​

Each pod projects a unique managed identity via workload identity, isolating database access between services.

Managed Identity vs AWS and Google Cloud​

All major clouds offer secretless workload authentication. The terminology and specifics differ.

CapabilityAzureAWSGoogle Cloud
Workload identityManaged IdentityIAM RoleService Account
Secretless accessYesYesYes
FederationWorkload Identity FederationIAM FederationWorkload Identity Federation
AuthorizationAzure RBACIAM PolicyCloud IAM
Lifecycle managementAutomatic (system-assigned) or manual (user-assigned)Automatic with instance profileAutomatic with service account

Architecturally, the key difference is that Azure's system-assigned identity is tightly coupled to a resource's lifecycle, while AWS's IAM roles are attached to resources via instance profiles and persist if the profile is reassigned. Google Cloud's service accounts are similar to user-assigned identities but with their own key management and IAM integration.

Best Practices Summary​

  • Prefer identity-based authentication for all Azure-to-Azure communication.
  • Avoid long-lived credentials—they are a liability.
  • Use Managed Identity as the default for workloads running in Azure.
  • Combine identity with least-privilege RBAC to create defense in depth.
  • Design workload identities explicitly—each microservice, function, or job should have its own identity.
  • Monitor identity access continuously using Entra ID logs, Azure Monitor, and Microsoft Sentinel.
  • Treat your identity infrastructure as code—manage role assignments with Bicep, Terraform, or ARM templates to ensure consistency and auditability.

Managed Identity is not just a convenience feature; it is the foundation of a secure, modern Azure architecture. By eliminating the need to store and rotate secrets, it removes an entire class of security incidents and frees developers to focus on building applications. When combined with Azure RBAC, workload identity federation, and rigorous monitoring, it enables a true Zero Trust model for cloud workloads.

Further Reading​