When you visit a friend's apartment building, there are several ways you might get through the front door. You could carry a copy of the key, which works until you lose it or someone copies it. You could carry a keycard that expires and has to be reissued. You could live in the building, so the door simply recognises you. Or the concierge could phone your friend, who vouches for you, and the concierge lets you in for the afternoon. Software faces the same choice every time it needs to reach a protected service in Microsoft's cloud. It can carry a password, called a client secret; carry a certificate; use a managed identity that Azure creates and looks after; or use a federated credential that trusts another system to vouch for it. None of these choices is exotic, and all four are in daily use. But they ask very different things of the people who run the software, and they decide whether a key ever sits next to the code at all. This article walks through all four in plain words, explains the documented guidance on the most common sub-choice, points out the surprises newcomers hit, and ends with a simple order for deciding, including for the artificial intelligence (AI) agents that now call services on their own.

Why the choice matters more than it looks

Every program that calls a protected service has to prove who it is. That proof is checked by Microsoft Entra ID, Microsoft's cloud directory of users and software, which then hands the program a token: a short-lived, digitally signed pass that says who the caller is and which service it may talk to. The token is the same whichever method was used to earn it. What differs is what the program had to show to get one.

That difference has real consequences. Some methods involve a secret that a person creates, copies into place and must remember to replace before it expires. Others involve nothing a person ever handles. Some work anywhere; others only work where a particular platform can vouch for the program. Choosing well is less about which method is clever and more about which one leaves the fewest things for people to lose, forget or leak.

A useful question to carry through the rest of this article is: who holds the key, and for how long? The answer ranges from 'a person, for as long as nobody notices' to 'nobody, ever'.

From a password a person copies into place, to proof that no person ever sees: the further right, the less there is to lose or leak.Who holds the key?Client secreta person copies itCertificatea person stores itFederatedcredentialanother systemvouchesManaged identityAzure keeps it
From a password a person copies into place, to proof that no person ever sees: the further right, the less there is to lose or leak.

Option one and two: a client secret or a certificate

The oldest approach starts with an app registration, the directory entry you create in Microsoft Entra ID for an application you build. To let the application sign in, you add a credential to it. A client secret is simply a long, randomly generated password. A certificate is a more structured kind of proof: a pair of mathematically linked keys, where the private key stays with the application and the public key is uploaded to the directory, so the application can prove it holds the private key without ever sending it.

Both work from anywhere, which is their great strength: a program on a laptop, in an office server room or in any cloud can use them. Both also have the same weakness: someone creates them, stores them somewhere the program can read, and must replace them before they expire. A secret pasted into a configuration file can be copied by anyone who can read that file. A certificate's private key is harder to leak by accident, but it still has to live somewhere and still has to be renewed.

Organisations can put guard rails around these credentials. Microsoft Entra ID offers app management policies that can, for example, block new passwords from being added to applications, or limit how long passwords and certificates are allowed to live. Those policies do not remove the work of handling credentials; they keep it within limits.

⚠️
Secrets are the last resort. A client secret works everywhere precisely because anyone holding it can use it from anywhere, which is also why it is the riskiest option.

Option three: a managed identity

A managed identity is an identity that Azure creates for a resource, such as a virtual machine, a web app or a function, so that code running there can get tokens without any person handling a secret. Behind the scenes, Microsoft documents that managed identities use certificates that expire after 90 days and are rolled, meaning replaced, after 45 days, all handled by Azure and never shown to you.

There is one clear condition: the code has to run on an Azure resource that supports managed identities. That is a large and growing list of services, but it does not include a build pipeline on another platform or a server in someone else's cloud.

Managed identities come in two kinds. A system-assigned identity is switched on for one resource and is deleted automatically when that resource is deleted. A user-assigned identity is created as its own Azure resource, can be attached to several resources, and stays until you delete it. Choosing between them is the most common follow-up question, and Microsoft gives direct guidance on it.

System-assigned or user-assigned: what the guidance says

Microsoft's best-practice recommendations put it plainly: user-assigned managed identities are more efficient in a broader range of scenarios than system-assigned ones. The reasons are practical. When you run several copies of the same thing, for example ten copies of a web app behind a load balancer, giving them one shared user-assigned identity means one set of role assignments, the records that grant an identity its permissions, instead of ten. And because a user-assigned identity exists independently, it and its role assignments can be set up before the resources that will use it, so access is ready the moment the resource starts.

There are good reasons to choose system-assigned instead. If the permissions should vanish together with the resource, a system-assigned identity guarantees that the identity goes when the resource goes. And if your logs need to show exactly which individual resource did something, a separate identity per resource gives you that, while a shared identity makes every copy look the same.

Scale can matter too. Creating a large number of system-assigned identities in a short time can run into the directory's limit on how quickly new objects can be created, which shows up as an error with the code 429, meaning 'too many requests'. Reusing a user-assigned identity avoids creating a new directory object for every resource.

Sharing has a cost, however. A user-assigned identity carries its permissions to every resource it is attached to, so anyone who can run code on any one of those resources can use all of its access. Microsoft's guidance illustrates this with an example of a person who can only deploy one kind of resource gaining a shared identity's wider permissions through it. Share an identity only between resources that genuinely need, and deserve, the same access.

Whether copies share access and whether logs must name each resource point to the managed identity kind that fits best.Which kind fitsUser-assignedshared, set up aheadEither workspick by lifecycleWeigh it upshared vs traceableSystem-assignedone per resource
Whether copies share access and whether logs must name each resource point to the managed identity kind that fits best.

Option four: a federated credential

Plenty of software that needs Azure runs somewhere else: a deployment pipeline on GitHub Actions, a service inside a Kubernetes cluster, which is a system for running containers of software across many machines, or a job in another company's cloud. These platforms already know who their own workloads are, and they can issue signed tokens saying so.

A federated identity credential lets an Azure identity, either a user-assigned managed identity or an app registration, trust those outside tokens and exchange them for Microsoft Entra tokens. The credential itself holds no secret. It is a rule naming whose tokens to accept: which outside provider issued them, which specific workload they describe, and who they were meant for, all of which must match exactly.

This gives software outside Azure most of what a managed identity gives software inside it: no password to copy, store or renew. The condition is that the outside platform must be able to issue suitable tokens, and the trust is only as narrow as the rule you write.

Surprises that catch newcomers

Two behaviours regularly surprise people the first time they meet them, and both affect how you design access.

The first is timing. When you change what a managed identity is allowed to do, the change can take several hours to take effect. Microsoft explains that the token for each target service is cached for around 24 hours and that a managed identity's tokens cannot be forced to refresh. A permission you add may not work right away, and a permission you remove may keep working for a while. Microsoft's guidance is to prefer giving a user-assigned identity direct role assignments rather than moving identities in and out of groups to change their access, because group changes are where these delays bite hardest.

The second is sharing, which the guidance above already warned about: a shared identity shares its permissions with everyone who can run code wherever it is attached. Neither surprise is a flaw; both follow from how the system is built. They simply need to be in your mind before an incident, not discovered during one.

A permission change for a managed identity is not instant: cached tokens can keep the old access for hours.When a change landsNowRole changedadded or removedMinutes to hoursOld token in usecached per serviceUp to ~24 hcacheNo forced refreshcannot be pushedAfter refreshNew access appliesnext fresh token
A permission change for a managed identity is not instant: cached tokens can keep the old access for hours.

What this means for AI agents

Every AI agent, a program that uses a large language model (LLM) to plan steps and call tools, needs one of these four methods for every protected service it calls: a search index, a database, a model endpoint, a storage account. The choice decides whether a key ever sits next to the agent.

That matters because an agent is unusually exposed to persuasion. A prompt injection, text crafted to make the model follow an attacker's instructions, can try to get an agent to reveal what it can see. An agent configured with a client secret has something to reveal. An agent that runs on Azure with a managed identity, or outside Azure with a federated credential, has no stored key to give away; it only ever holds short-lived tokens.

The surprises matter too. Because removing a managed identity's access can take hours to apply, an agent's permissions should be narrow from the start rather than trimmed in a hurry later. And because sharing an identity shares its access, each agent is better served by its own identity than by borrowing one from another workload.

A simple order for choosing

Putting the documented guidance together, a simple decision order emerges. This order is a synthesis of Microsoft's recommendations rather than a single official rule, but each step follows directly from them.

First, if the code runs on an Azure resource that supports managed identities, use a managed identity, choosing user-assigned for most cases and system-assigned when permissions must disappear with the resource or logs must name each one. Second, if the code runs outside Azure on a platform that issues tokens, such as GitHub Actions, Kubernetes or another cloud, use a federated credential with the narrowest rule the platform allows. Third, if neither applies, use a certificate, keep its lifetime short, and use app management policies to limit what credentials can be added. Fourth, use a client secret only where nothing else is possible, and treat it as a known risk with an owner and an expiry date.

Whatever you choose, two habits apply to every option: grant only the access the job needs, and write down who owns each identity and why it exists. The method decides whether a key can leak; those habits decide how much harm the identity could do if anything else goes wrong.

  1. Runs on Azure: managed identity (usually user-assigned).
  2. Runs outside Azure on a token-issuing platform: federated credential.
  3. Neither: a short-lived certificate, kept within app management policies.
  4. Only when nothing else works: a client secret, with an owner and an expiry date.

Key takeaways

  • Software can sign in to Microsoft Entra ID with a client secret, a certificate, a managed identity or a federated credential; the token it gets is the same, but what people must handle is not.
  • Secrets and certificates work anywhere but must be created, stored and renewed; app management policies can limit them.
  • Managed identities remove the secret for code on Azure; Microsoft says user-assigned identities suit a broader range of scenarios, while system-assigned ones fit when permissions must vanish with the resource or logs must name it.
  • Federated credentials remove the secret for code outside Azure by trusting tokens from platforms such as GitHub Actions or Kubernetes.
  • Managed identity permission changes can take hours because tokens are cached for around 24 hours, and sharing an identity shares its access.
  • A practical order: managed identity, then federated credential, then a short-lived certificate, and a client secret only as a last resort.

Glossary

Client secret
A long, randomly generated password added to an app registration so the application can sign in.
Certificate
A pair of linked keys where the application keeps the private key and proves it holds it without sending it.
App registration
The directory entry created in Microsoft Entra ID for an application you build.
Managed identity
An identity Azure creates and maintains for a resource, so its code can get tokens without a secret.
Federated credential
A rule on an Azure identity that trusts tokens from an outside provider for a specific workload, holding no secret itself.
Role assignment
A record granting an identity a set of permissions on a specific resource.
App management policy
A Microsoft Entra ID setting that restricts what credentials applications may have, such as blocking new passwords.
Token
A short-lived, digitally signed pass that says who the caller is and which service it may use.
Prompt injection
Text crafted to make an AI model follow an attacker's instructions instead of the intended ones.

Further reading

  1. Managed identity best practice recommendations (Microsoft Learn)
  2. Managed identities for Azure resources frequently asked questions (Microsoft Learn)
  3. Workload identity federation (Microsoft Learn)
  4. applicationAuthenticationMethodPolicy resource type (Microsoft Graph)