Managed Identities & Federated Credentials · 1 of 3
What a Managed Identity Is: An Identity Nobody Holds a Key For
How Azure gives a piece of software its own sign-in, renews it quietly, and keeps the key out of every person's hands, including yours.
Think about the staff badge you get when you start work in a large office building. You did not make it, you never see how its chip is programmed, and when it needs renewing, building security does that behind the scenes. You simply tap it on the reader and the door opens. Now imagine the badge is not issued to a person at all, but to one particular office, and it only works for whoever is sitting inside that office. That is very close to what a managed identity is. It is a way for a piece of software running in Microsoft's Azure cloud to prove who it is and get access to other services, without any person ever writing down, copying, pasting or storing a password or key for it. This article explains what a managed identity actually is, the two kinds you can choose from, how a program uses one, and the small print every newcomer should know before relying on it, including what it means for the artificial intelligence (AI) agents many teams now run in the cloud.
Why software needs an identity at all
Software talks to other software all day long. A website reads customer records from a database. A nightly job copies files into storage. An AI agent, which is a program that uses a large language model (LLM) to decide on steps and then carries them out, looks up documents and calls tools. Every one of those services wants to know who is asking before it answers, for the same reason a bank teller asks for your card before handing over cash.
For people, proving who you are is familiar: a username, a password, maybe a code from your phone. For software, the traditional answer was a secret, which is simply a long password or a digital key that the program presents when it signs in. Someone creates that secret, then has to put it somewhere the program can read it: a configuration file, a setting in the cloud portal, or a password vault.
That is where trouble starts. A secret that lives in a file can be copied. A secret pasted into a chat to help a colleague can be read by everyone in that chat. A secret that nobody remembers to renew stops working at the worst possible moment and takes a service down with it. The secret itself is not the goal; it is just the price we used to pay for software to have an identity. A managed identity is Azure's way of removing that price.
What a managed identity actually is
Microsoft Entra ID is Microsoft's cloud directory: the system that keeps track of every user, group and application allowed to sign in, and that issues the digital passes they use. A managed identity is an identity in Microsoft Entra ID that Azure creates for a resource, meaning a thing you run in Azure such as a virtual machine (a computer rented in the cloud), a web app or a function. The code running on that resource can then ask for passes without anyone handling a secret.
Those passes are called tokens. A token is a short-lived, digitally signed message that says, in effect, 'this caller is identity X, and this pass is valid for service Y until time Z'. The receiving service checks the signature and the expiry and decides whether to let the request in. A token from a managed identity is what Microsoft calls an app-only access token: it represents the software itself, not a person using it.
Under the hood, Microsoft describes a managed identity as a special type of service principal. A service principal is the directory's record of a piece of software, the entry that permissions get attached to. When you register your own application in Microsoft Entra ID, you get two records: an application object (the blueprint) and a service principal (its presence in your directory). A managed identity has only the service principal. There is no blueprint for you to edit and, crucially, no place for you to add a password.
The identity still needs some proof behind the scenes, of course. Microsoft documents that managed identities use certificate-based authentication, where each credential expires after 90 days and is rolled, meaning replaced with a new one, after 45 days. Microsoft also says exactly how this works is an internal implementation detail that can change without notice. For you, the practical meaning is simple: the proof exists, Azure owns it, Azure renews it, and you never see it.
Two kinds: one tied to a single resource, one you can share
Azure offers two kinds of managed identity, and the difference is mostly about lifetime and sharing. Going back to the office building: one kind is a badge printed for a single office that is shredded the day the office is closed; the other is a badge kept at the front desk that several offices can be given.
A system-assigned managed identity is switched on for one resource. It is tied to that resource's lifecycle, so when you delete the resource, Azure deletes the identity automatically. It cannot be shared; it belongs to exactly one resource. This is the simplest choice when one program needs its own identity and nothing else will ever need the same access.
A user-assigned managed identity is created as its own Azure resource, separate from anything that uses it. You can attach it to more than one resource, for example ten copies of the same web app that all need to read the same storage account. Because it lives on its own, deleting the apps does not remove it; you must delete it yourself when it is no longer needed.
A single resource can have both: one system-assigned identity and one or more user-assigned identities at the same time. There is one practical consequence. If a resource carries several user-assigned identities and no system-assigned one, the code has to say which identity it wants when it asks for a token, because Azure will not guess on its behalf.
| Question | System-assigned | User-assigned |
|---|---|---|
| How is it created? | Switched on for one resource | Created as its own Azure resource |
| How many resources can use it? | Exactly one | One or many |
| What happens when the resource is deleted? | Deleted automatically with it | Stays until you delete it |
| Good fit when | One program needs its own access | Many copies need the same access, or the identity must outlive a resource |
How a program gets a token, step by step
Microsoft recommends that code use the Azure Identity client library, a ready-made software package available for common programming languages, rather than writing the token request by hand. The library knows how to find the managed identity on whatever Azure service the code is running on, caches tokens so it does not ask more often than needed, and asks for a fresh one before the old one expires.
It still helps to know what happens underneath. On an Azure virtual machine, the request goes to a special local address, 169.254.169.254, which is only reachable from inside that machine. The code includes a header, a small label on the request, that reads Metadata: true. That header is a simple guard: ordinary web pages a browser might be tricked into loading do not send it, so they cannot quietly ask for a token.
The response carries the access token and the time it expires. Notice something that is missing: there is no refresh token, the long-lived pass that some sign-in systems give people so they can stay logged in. Microsoft's documentation marks that field as not used by managed identities. When a token runs out, the code simply asks the local endpoint again.
The program then attaches the token to its call to the target service, for example a storage account or a key vault. That service checks the token and looks up what this identity has been granted. If no one has given the identity a role there, the call is refused. Having an identity and having access are two separate steps.
from azure.identity import ManagedIdentityCredential
from azure.storage.blob import BlobServiceClient
credential = ManagedIdentityCredential()
client = BlobServiceClient("https://<account>.blob.core.windows.net", credential=credential)The one thing to understand about safety: the resource is the boundary
A managed identity takes the secret away, which removes a whole family of mistakes: no key in a file, no key in a chat, no key that expires unnoticed. But it is worth being precise about what is left. Microsoft's guidance states that the security boundary is the resource the identity is attached to. Any code running on that resource can request tokens for its managed identity.
Back to the office badge that works for whoever sits in the office. The badge is safe from being copied, but anybody who gets into the office can tap it on a reader. In software terms, if a program on the resource is replaced, tricked or joined by something unexpected, that something gets the same access the identity was granted. The question 'who can get this identity's tokens?' becomes 'who can run code on this resource?'
That leads to two habits that keep managed identities safe. First, grant each identity only the access its job needs, a principle called least privilege, so that even if the wrong code runs there, it cannot reach far. Second, be careful with sharing: a user-assigned identity attached to five resources can be used from all five, so its access should suit the least-protected of them.
Small print every newcomer should know
A few behaviours surprise people the first time they meet them, so it is better to learn them on a quiet day than during an incident.
Deleting a managed identity does not delete the permissions it was given. Its role assignments, the records saying 'this identity may read that storage account', stay behind until someone removes them. Good housekeeping means removing the access first, then the identity.
Deleted managed identities are kept in a soft-deleted state for 30 days. You can still see them during that time, which helps with investigations, but you cannot restore them. If you delete one by mistake, you create a new one and grant its access again.
Managed identities have their own sign-in log. In Microsoft Entra ID there is a separate 'managed identity sign-ins' report, apart from the reports for people and for registered applications. If you are looking for when an identity signed in and what it asked for, that is the place to look.
Finally, the local token endpoint has a speed limit. Requests to its managed identity category are limited to 20 per second and 5 at the same time. Code that asks for a new token on every single operation can hit that limit, which is one more reason to let the client library cache tokens for you.
- Remove role assignments before or when you delete an identity; they are not cleaned up for you.
- A deleted identity stays visible for 30 days but cannot be brought back.
- Check the managed identity sign-ins report, not the user sign-ins report, for its activity.
- Let the client library cache tokens; the local endpoint allows 20 requests per second and 5 at once.
What this means for AI agents
AI agents raise the stakes on everything above. An agent often needs to reach several services: a search index for documents, a database for records, a model endpoint for reasoning, a storage account for files it produces. In the past, that meant a configuration file holding several keys, any of which could leak through a log, a backup or a shared screenshot.
An agent running on Azure compute can use a managed identity instead. Its configuration then holds names and addresses, not secrets, and each service it calls checks a short-lived token from Microsoft Entra ID. There is also a quieter benefit: an LLM-driven program can be talked into revealing what it can see, for example through a prompt injection, which is text crafted to make the model follow an attacker's instructions instead of yours. An agent that never holds a key cannot be talked into printing one.
The boundary rule matters even more for agents, though. An agent decides at run time which tools to call, so the identity it runs under should be granted only what its tasks require. If an agent shares a user-assigned identity with other workloads, every one of them carries the union of that access. Giving each agent its own identity, and each identity a narrow set of roles, keeps a mistake in one agent from becoming a problem for everything else.
Decisions to make before you switch one on
For a leader or a practitioner, using managed identities well comes down to a handful of clear choices, made once and written down.
Which kind? Choose system-assigned when a single resource needs its own access and the identity should disappear with it. Choose user-assigned when several resources must share exactly the same access, or when the identity needs to exist before the resource is created, for example so permissions can be granted in advance.
Who owns it? Every identity should have a named owner who can answer what it is for and what it can reach. A user-assigned identity with no owner tends to outlive the project that created it, along with its permissions.
What is the smallest access that works? Grant roles on the specific resource the program needs, not on the whole subscription, and review them when the program changes.
How will you clean up? Decide that removing access comes before deleting an identity, and check the managed identity sign-ins report to confirm an identity is no longer in use before you retire it. These four answers turn a convenient feature into a dependable practice.
Key takeaways
- A managed identity is an identity in Microsoft Entra ID that Azure creates for a resource, so the code there can get tokens without anyone handling a secret.
- System-assigned identities belong to one resource and are deleted with it; user-assigned identities are separate resources that can be shared and must be deleted by hand.
- Azure owns and renews the hidden credential; code asks a local endpoint or, better, the Azure Identity client library for short-lived tokens.
- The security boundary is the resource: any code running there can get the identity's tokens, so grant only the access the job needs.
- Role assignments outlive a deleted identity, deleted identities cannot be restored, and managed identities have their own sign-in report.
- For AI agents, a managed identity keeps keys out of configuration and out of the model's reach, as long as each agent gets its own narrowly scoped identity.
Glossary
- Managed identity
- An identity in Microsoft Entra ID that Azure creates and maintains for a resource, so its code can get tokens without a secret.
- Microsoft Entra ID
- Microsoft's cloud directory that records users and software and issues the tokens they use to sign in.
- Service principal
- The directory record that represents a piece of software and that permissions are attached to.
- Token
- A short-lived, digitally signed pass saying who the caller is, which service it is for and when it expires.
- System-assigned identity
- A managed identity switched on for one resource and deleted automatically with it.
- User-assigned identity
- A managed identity created as its own resource that can be attached to many resources and must be deleted manually.
- Role assignment
- A record granting an identity a set of permissions on a specific resource.
- Least privilege
- The habit of granting an identity only the access its job actually needs.
- Prompt injection
- Text crafted to make an AI model follow an attacker's instructions instead of the intended ones.