What an Azure Managed Identity Actually Does (and Why You Want One)
The short version: it lets one Azure resource talk to another without a password sitting in your code.
By Shehryar Hassan, Microsoft 365 & Azure Consultant
If you've ever pasted a connection string or an API key directly into an App Service's application settings, you already know the problem. That secret has to live somewhere, someone has to remember to rotate it, and if it ever leaks, whoever has it can use it until you notice. A managed identity is Azure's way of getting rid of that specific headache.
What it actually is
A managed identity is an identity Azure creates and manages for a resource, an App Service, a Function App, a VM, whatever. Microsoft Entra ID tracks that identity behind the scenes. You never see a password or a client secret for it, and you never have to rotate one, because Azure handles the credential internally and swaps it out on its own schedule.
Once a resource has a managed identity, you grant that identity access to something else, a Key Vault, a Storage account, a SQL database, using normal role assignments. Your code then asks for a token using a library like Azure.Identity, and Azure hands it one without any secret ever touching your app settings or your source code.
There are two flavors. A system assigned identity is tied to one resource and disappears with it, the simplest option if you just need one App Service to reach one Key Vault. A user assigned identity exists on its own and you can attach it to several resources, useful if five Function Apps all need the same permissions and you don't want to manage five separate role assignments.
Where people get stuck
The most common mistake I see is granting the identity too much. It's easy to hand a managed identity Contributor on a whole resource group because it's faster than figuring out the exact role it needs. Take the extra five minutes and use a scoped role, like Key Vault Secrets User instead of Key Vault Administrator, so a compromised app can only do the one thing it was meant to do.
The other one is forgetting that local development doesn't have a managed identity at all. Your laptop isn't an Azure resource, so testing code that relies on one usually means falling back to your own Azure CLI login or a service principal while you're developing, and only relying on the managed identity once it's actually deployed.
If you're still passing secrets around in app settings for anything that talks to another Azure resource, this is usually the fix.
Get new posts by email
One note when there is something worth reading. No spam, unsubscribe anytime.
Related articles
Azure Traffic Manager, What It Does and How It's Different From Load Balancer
Traffic Manager and Load Balancer sound like they do the same thing. They don't. One works at the DNS level across regions, the other spreads traffic inside one region. Here's what each is actually for.
Azure Front Door, What It Does and When You'd Actually Use One
Azure Front Door routes visitors to the closest healthy copy of your site and can add a free SSL certificate along the way. Here's when it actually earns its keep.
What Azure Application Insights Actually Tracks (and Why You'd Turn It On)
Application Insights sounds like another thing to configure, but once you turn it on for a web app, you stop guessing why it's slow or crashing.