What Is a Managed Identity in Azure

In this comprehensive article, I will walk you through what Managed Identity is, the two distinct types you must know, how it works under the hood, and why you should likely be using it for 90% of your service-to-service communications.

What Is a Managed Identity in Azure

To understand Managed Identity, you have to shift your thinking from “User Identity” to “Resource Identity.”

When you or I log into the Azure Portal, we use a user account (like mike@example.com). We have a password and Multi-Factor Authentication (MFA).

But what about your Virtual Machine (VM)? What about your Azure Function? It needs to authenticate to other services too. Historically, we gave it a “Service Principal”—essentially a username and password for a robot. But someone still had to manage that robot’s password, rotate it, and keep it safe.

Managed Identity is a feature of Microsoft Entra ID (formerly Azure Active Directory) that provides Azure services with an automatically managed identity.

Think of it this way: When you enable Managed Identity on a Virtual Machine, Azure automatically creates an identity for that VM in the directory. It’s like giving the VM its own employee badge. When the VM needs to access an SQL Database, it simply flashes its badge. Azure checks the badge, sees that you granted it access, and lets it in.

There is no password. The VM doesn’t know a password, and the developer doesn’t know a password. Azure handles the cryptographic handshake internally.

Why Do We Need It?

Before Managed Identity, the workflow for a developer named Sarah in San Francisco might look like this:

1. Sarah creates a Storage Account.
2. She goes to the “Access Keys” tab and copies the long connection string.
3. She pastes it into her application code or configuration file.
4. Risk 1: She accidentally pushes that code to a public repository.
5. Risk 2: A year later, the key expires or needs rotation. The app breaks until Sarah updates the config.

With Managed Identity, the workflow changes:

1. Sarah enables Managed Identity on her App Service.
2. She goes to the Storage Account and says, “Allow this App Service to read blobs.”
3. She writes code that says new BlobClient().
4. Result: No keys to copy. No keys to leak. No keys to rotate.

If the application is compromised, the attacker finds no credentials in the code. They cannot take a “key” and use it from their own laptop, because the identity is intrinsically tied to the running Azure resource.

How It Works Under the Hood

You might be wondering, “If there is no password, how does the authentication technically happen?”

I love this part because it is elegant engineering. When you enable Managed Identity on a resource (like a VM), Azure does three things:

1. Identity Creation: It creates a Service Principal in your Entra ID tenant.
2. Environment Configuration: It configures the local environment of that resource. For a VM, it uses the IMDS (Instance Metadata Service).
3. Token Issuance: It establishes a trust relationship so the resource can request tokens.

When your code runs, it doesn’t send a password. Instead, it makes a standard HTTP REST call to a local endpoint (usually http://169.254.169.254) that is only accessible from within that specific VM.

Your code essentially asks the local Azure agent: “Hey, can I have a token for SQL Server?”

The agent checks if the VM is active and valid, communicates with Entra ID, and hands back an OAuth access token. Your code then sends that token to the SQL Server. The SQL Server validates the signature and grants access.

The Two Types of Managed Identities

This is the section where I see most architectural mistakes happen. Microsoft offers two flavors of Managed Identity, and choosing the wrong one can lead to management headaches down the road.

1. System-Assigned Managed Identity

This is the “strict parent” version. It is tied directly to the lifecycle of the Azure resource.

• Creation: You go to your resource (e.g., a Logic App), flip a switch to “On”, and it is created.
• Naming: It creates an identity with the same name as the resource.
• Lifecycle: If you delete the Logic App, the identity is automatically deleted.
• Relationship: One-to-One. One resource, one identity.

When to use it: I recommend System-Assigned identities for standalone resources that have unique permission requirements. For example, if you have a single VM hosting a legacy app that needs access to a specific storage container, use System-Assigned.

2. User-Assigned Managed Identity

This is the “independent contractor” version. It is created as a standalone Azure resource first, and then assigned to one or more services.

• Creation: You create a “User Assigned Identity” resource in the portal, just like you would create a generic Storage Account.
• Naming: You give it a custom name (e.g., id-marketing-app-eastus).
• Lifecycle: It exists independently. If you delete the VM using it, the identity remains alive.
• Relationship: Many-to-Many. You can assign this single identity to 100 different VMs.

When to use it: This is perfect for scaling. Imagine you have a Virtual Machine Scale Set with 50 instances, all running the same web server, all needing access to the same Key Vault. If you used System-Assigned, you would have to grant access to 50 different identities in Key Vault. With User-Assigned, you create one identity, assign it to the Scale Set, and grant access in Key Vault once.

Comparison: System-Assigned vs. User-Assigned

To make it easier to decide, here is a comparison table I use when consulting with clients.

Key Benefits of Using Managed Identity

If you are still using connection strings, here is why you should switch.

1. Security (Credential Theft Mitigation)

This is the big one. Since there are no credentials to view, copy, or save, they cannot be phished or stolen. An attacker would need to compromise the actual Azure resource (the running VM) to use its identity.

2. Operational Efficiency

I once worked on a project where we had to rotate database passwords every 90 days for compliance. It was a nightmare of coordination, downtime, and broken config files. With Managed Identity, Azure handles the rotation of the underlying certificates automatically. You never have to touch it.

3. Cost

This is my favorite benefit to tell CTOs: Managed Identity is free. It is a feature of the free tier of Entra ID. You do not pay extra for the identity or the token transactions.

4. Simplified Development

Using the Azure.Identity library in .NET, Python, or Java makes coding trivial. You often just use the DefaultAzureCredential class. It automatically detects if it is running in Azure and uses the Managed Identity without you writing specific logic for it.

Common Use Cases

In the US market, I see these patterns deployed constantly in enterprise environments.

• Azure App Service to Azure SQL: The web app uses Managed Identity to log into the SQL database. This removes the username/password from the web.config.
• Azure Functions to Key Vault: Sometimes you do need a secret (like an API key for a third-party service like Twilio or Stripe). You store that key in Azure Key Vault. The Function uses Managed Identity to read the secret from the Vault.
• Virtual Machines to Storage Accounts: A background processor on a VM uses Managed Identity to upload daily log files to a blob container without needing a SAS token.
• Azure Kubernetes Service (AKS): AKS uses “Pod Identity” (or the newer Workload Identity) which essentially maps Managed Identities to specific pods, ensuring granular security even within a cluster.

Troubleshooting Common Issues

Even though it is “managed,” things can go wrong. Here are the most common issues I troubleshoot.

1. The “Propagation Delay”

You create a User-Assigned identity, assign it to a VM, and grant it access to SQL. You run your code immediately, and it fails.

Reason: Role-Based Access Control (RBAC) assignments in Azure can take up to 5-10 minutes to propagate globally.

Solution: Get a coffee. Wait a few minutes and try again.

2. The “Wrong Scope” Error

You granted the identity permissions, but your code says “403 Forbidden.”

Reason: You likely granted the permission at the wrong scope. For example, you gave the identity “Reader” on the Resource Group, but it needs “Storage Blob Data Contributor” on the specific Storage Account.

Solution: Always check the specific “Data Plane” roles (like Storage Blob Data Reader) vs “Control Plane” roles.

3. Multiple Identities Confusion

If you assign both a System-Assigned and a User-Assigned identity to the same VM, your code might get confused about which one to use.

Reason: The code SDK tries to pick a default.

Solution: In your code, you must explicitly specify the Client ID of the User-Assigned identity so the SDK knows which badge to present.

Conclusion

Managed Identity is not just a feature; it is a paradigm shift in how we handle cloud security. It moves us away from the fragility of shared secrets and towards the robustness of identity-based access.

Enabling Managed Identity should be one of your first steps in provisioning infrastructure.

It is secure, it is free, and it saves you from the headache of password rotation.

You may also like the following articles:

• How To Get Microsoft Entra ID
• What are the main benefits of using Microsoft Entra ID
• How To Setup Microsoft Entra ID

Rajkishore

I am Rajkishore, and I am a Microsoft Certified IT Consultant. I have over 14 years of experience in Microsoft Azure and AWS, with good experience in Azure Functions, Storage, Virtual Machines, Logic Apps, PowerShell Commands, CLI Commands, Machine Learning, AI, Azure Cognitive Services, DevOps, etc. Not only that, I do have good real-time experience in designing and developing cloud-native data integrations on Azure or AWS, etc. I hope you will learn from these practical Azure tutorials. Read more.