The Resource Is the Credential: Who Can Become a Managed Identity

A password has an owner: whoever holds it. Revoke it, rotate it, scan for it in repositories, and you are reasoning about a small, nameable set of holders. Managed identities in Microsoft Entra ID were designed to make that reasoning unnecessary. Azure creates the identity for a resource, keeps the credential behind it, rotates it on its own schedule, and hands the code running on the resource short-lived tokens through a local endpoint. There is nothing to leak because there is nothing to hold. But the credential did not disappear; it moved. Microsoft's own documentation states that the security boundary of a managed identity is the resource to which it is attached, and that any code running on that resource can call the managed identity endpoint and request tokens. Read as a design statement, that sentence is reassuring. Read as an access-control statement, it is a puzzle: if the resource is the boundary, then every principal who can place, alter or reach code inside that boundary can become the identity, and none of them appears in the identity's role assignments. This article works through that puzzle carefully, builds a model of who can actually become a managed identity, and turns it into a review method a security team can run.

Background: what a managed identity token proves

A managed identity is created in Microsoft Entra ID as a service principal of a special type. Unlike an app registration, which has two directory objects, an application object and a service principal, a managed identity has only the service principal. Microsoft documents that managed identities authenticate with certificates whose credential expires after 90 days and is rolled after 45 days, and that how they authenticate is an internal implementation detail subject to change without notice. The operator never sees, stores or rotates that credential.

Code obtains a token by asking a platform endpoint on the resource. On an Azure virtual machine this is the Instance Metadata Service at a link-local address, called with the header Metadata: true, which Microsoft describes as a mitigation against server-side request forgery (SSRF), the attack class in which a server is tricked into sending a request of the attacker's choosing; OWASP catalogues SSRF as a standing web application risk, and MITRE ATT&CK records abuse of cloud instance metadata interfaces as a credential-access technique in its own right. The response is an app-only access token based on the managed identity's service principal, together with its expiry; the refresh token field is documented as not used by managed identities. Microsoft recommends the Azure Identity client library rather than hand-built requests.

In the vocabulary of the OAuth 2.0 framework, IETF RFC 6749, the result is functionally a client-credentials grant: the client acts on its own behalf, with no user in the loop. The token itself is a JSON Web Token, or JWT, as defined in RFC 7519: a signed set of claims naming the issuer, the subject and the intended audience. RFC 7523 defines how one JWT can be presented as an assertion to obtain another, which becomes relevant when federated credentials enter the picture. The important property for this article is simple: a resource server receiving the token learns which service principal it was issued to. It does not learn which process, container, administrator or script asked for it.

NIST SP 800-207, the zero trust architecture reference, frames access decisions around the identity of the requesting subject and the state of the asset it runs on. Managed identities implement the first half elegantly. The second half, the state of the asset, is exactly where the documented boundary statement points, and it is the half that ordinary identity reviews tend to skip.

Problem statement: from holders to becomers

For a secret-based credential, the natural security question is: who holds the secret? For a managed identity, that question has a trivial and unhelpful answer, namely nobody. We therefore replace it with a question that does have a useful answer. We say a principal can become a managed identity if, by actions available to it, it can cause a token issued to that identity's service principal to be used for a purpose the principal chooses. A principal here means anything that can act: a human administrator, a deployment pipeline, another workload's identity, or code that has been injected into a process.

The effective principal set of a managed identity is the set of all principals that can become it. This is our own definition, introduced for this analysis; it is not a Microsoft term. Its value is that it makes the boundary statement measurable. If the boundary is the resource, then the effective principal set is everyone who can exercise control inside that boundary, plus everyone who can move the boundary, plus everyone who can add another way in.

We deliberately exclude two things. First, compromise of Microsoft's own platform, such as a flaw in the token service, is out of scope; the analysis assumes the platform behaves as documented. Second, we do not catalogue exploitation techniques against specific services. The goal is a defender's model of reachability, built only from documented behaviour, that can be applied to any tenant without testing anything against it.

The threat model is correspondingly modest. An adversary is any principal who should not be in the effective principal set but is, whether through over-broad role assignments, shared identities, forgotten federation rules, or a vulnerability in the code that legitimately runs on the resource. The defender's objective is to make the effective principal set equal, as nearly as possible, to the set of principals the owner intends.

Method: four documented paths into the effective principal set

We derive the paths from documented behaviour rather than from incident anecdotes, and we state for each one the documentation that grounds it and the control that bounds it. The derivation is our synthesis; the individual facts are Microsoft's.

Path one is code execution on an attached resource. This is the boundary statement itself: any code running on the resource can call the managed identity endpoint and request tokens. Every principal that can run code there, whether through a legitimate deployment, an interactive session, a scheduled task, or a vulnerability in the running application, is in the set. For a virtual machine, that includes anyone who can sign in to the machine or run commands on it. For a platform service, it includes anyone who can deploy or modify the code it runs.

Path two is control-plane change that becomes code execution. Many management operations on an Azure resource are, in effect, ways to change what code runs on it: deploying a new package to a web app, editing a function's code, changing a container image, or running a command on a virtual machine through its management interface. A principal holding such rights may never touch the data plane of any target service, yet it can place code inside the boundary, which makes path two a disguised form of path one. Microsoft's best-practice guidance illustrates exactly this pattern with a worked example: a user who has no direct access to a storage account, but who has permission to execute code within a logic app whose managed identity does, can read and write that storage account's data.

Path three is attachment of a user-assigned identity. A user-assigned identity exists independently and can be associated with more than one resource. A principal that can attach an existing user-assigned identity to a resource it already controls extends the identity's boundary to include that resource, and so joins the effective principal set through path one. Assigning an existing user-assigned identity to another resource does not create a new service principal, so this step leaves no new directory object behind; it is a change in association, not a new identity.

Path four is a federated identity credential on a user-assigned identity. A user-assigned managed identity can carry federated identity credentials that trust tokens from an external identity provider and exchange them for Microsoft Entra tokens for that identity. Microsoft documents that creating a user-assigned identity and configuring a federated identity credential on it requires the Contributor or Owner role assignment. Any principal with that right can therefore add a way to become the identity from outside Azure entirely, and every workload whose external token matches the credential's issuer, subject and audience joins the set. Federated credentials cannot be configured on system-assigned identities, so this path applies to user-assigned identities only.

Composition: why sharing takes the union

The paths compose in a simple but consequential way. For a system-assigned identity, the boundary is one resource, so the effective principal set is the union of paths one and two for that single resource. Path three does not apply because a system-assigned identity cannot be shared, and path four does not apply because federated credentials cannot be configured on it.

For a user-assigned identity attached to several resources, the effective principal set is the union of paths one and two across every attached resource, plus path three for anyone who could attach it elsewhere, plus path four for every federated credential on it. The identity's permissions are the same everywhere it is attached, so the weakest resource in the group defines how easy it is to become the identity, while the identity's role assignments define how much damage that becoming can do.

This is the analytical core of Microsoft's own sharing example, generalised. In the documented case, a user whose rights cover only executing code in one logic app inherits the storage access of that logic app's identity. With a shared identity, the same inheritance happens across every resource it is attached to: the person who can deploy to the least important resource in the group gains the access the identity holds for the most important one.

Microsoft nonetheless recommends user-assigned identities as more efficient in a broader range of scenarios, and for good reasons: fewer role assignments for replicated resources, identities and access that can be configured before the resources that need them, and no new directory object for each additional attachment. There is no contradiction. The recommendation optimises operational overhead; the composition rule describes the cost. The practical synthesis is that sharing is safe exactly when every resource in the group has the same set of principals able to run or change code on it. Replicas of one application deployed by one pipeline usually meet that condition. A grab-bag of unrelated services that happen to need the same storage account usually does not.

Evaluation: applying the model to three common shapes

We do not report measurements from any tenant; doing so would require testing against real environments. Instead we apply the model analytically to three deployment shapes that recur in practice, and state for each what a conventional review would see and what the effective principal set actually contains. The shapes are illustrative constructions, not observed incidents.

Shape A is a single virtual machine with a system-assigned identity granted read access to one key vault. A conventional review lists one role assignment and concludes that one identity can read one vault. The effective principal set additionally contains every administrator who can sign in to the machine, every principal that can run commands on it through the management plane, and any attacker who achieves code execution in the software running on it. The identity review is accurate about scope and silent about reach.

Shape B is a user-assigned identity shared by three web app replicas and a nightly export function, granted write access to a storage account. A conventional review again lists one role assignment. The effective principal set is the union of the deployers and code editors of all four resources. If the export function is edited by a broader team than the web app, that team can write to the storage account without any role assignment on it, exactly as in Microsoft's logic app example.

Shape C is the same user-assigned identity, additionally carrying a federated identity credential that trusts a continuous integration pipeline in an external source-control system. The effective principal set now extends outside Azure: every workflow run whose token carries a matching issuer, subject and audience can obtain the identity's token, and every principal with Contributor or Owner on the identity can add further credentials. None of these principals has a role assignment anywhere in Azure.

Across the three shapes, the pattern is consistent. The role assignment list correctly describes what the identity can do. It never describes who can make the identity do it. That second list has to be assembled from resource-level control-plane permissions, identity assignment permissions and the federated credentials attached to the identity.

Attribution: what the logs can and cannot tell you

If several principals can become an identity, investigators need to know which one did. Microsoft Entra ID provides a dedicated managed identity sign-ins report. Its entries are system-generated and cannot be changed or deleted, and sign-ins are aggregated when the managed identity name or ID, the status and the resource name or ID all match. That last property is useful: for a shared user-assigned identity, the report can distinguish sign-ins originating from different resources.

At the target service the picture is narrower. The token names the identity's service principal, so a storage or key vault log records that the identity acted, not which attached resource or which process inside it requested the token. Microsoft's guidance draws the corresponding design conclusion: if you need to log which specific resource carried out an action, rather than which identity, use a system-assigned identity.

Neither log reaches inside the boundary. Neither records whether the request came from the intended application, an administrator's interactive session, or injected code. That is not a logging defect; it follows directly from the boundary statement. Attribution below the resource level has to come from the resource's own telemetry, such as process, deployment and command histories, which is one more reason to treat those histories as identity evidence rather than as operational noise.

The design trade-off is therefore explicit. Shared user-assigned identities reduce role-assignment overhead and let access be prepared in advance, at the cost of a wider effective principal set and coarser attribution at the target. System-assigned identities give per-resource attribution and a boundary of exactly one resource, at the cost of more role assignments, deletion of permissions with the resource whether or not that is wanted, and, at very large scale, the possibility of exceeding the rate limit for Microsoft Entra object creation, which fails with an HTTP 429 error.

Countermeasures: making the effective principal set match intent

Each path suggests a control, and the controls are most effective when they are run as one review rather than four. The organising principle, our synthesis, is to review an identity's reach and its scope together: who can become it, and what it can do once become.

For path one, harden the workload and restrict interactive access on any resource carrying a privileged identity, because a vulnerability in the running code is a way into the set. For services that take requests on behalf of users or other systems, keep the documented Metadata: true protection in mind: it defends against simple forged requests of the kind OWASP describes as SSRF, but it does nothing against code that legitimately runs on the resource and chooses to misuse the token.

For path two, treat deployment, code-editing and run-command rights on a resource as rights over every identity attached to it. In practice that means granting those management rights with the same care as the identity's own data-plane roles, and including them in the same access review.

For path three, restrict who can assign each user-assigned identity, and group identities by owner and trust level rather than by the target resource they happen to need. The rule that falls out of the composition analysis is concrete: share an identity only among resources whose sets of code-control principals are the same.

For path four, restrict Contributor and Owner on user-assigned identities that carry privileged access, and review every federated identity credential on them as a standing way in. A user-assigned identity can hold up to 20 federated identity credentials, and each is a potential source of outside principals.

Across all paths, keep the identity's own role assignments as narrow as the work requires. Least privilege does not shrink the effective principal set, but it limits what any member of it can do. Remember also that deleting a managed identity does not remove its role assignments; they remain until someone removes them, which makes cleanup part of the same review.

1. List every resource each managed identity is attached to.
2. For each resource, list principals with code-execution or code-change rights.
3. List principals who can assign each user-assigned identity, and every federated credential on it.
4. Compare the union with the intended owners; split or narrow where they differ.
5. Review the identity's role assignments for scope, and remove orphaned ones.

Why this matters more for AI agents

AI agents, programs that use a large language model to plan steps and invoke tools, are increasingly hosted on Azure compute with a managed identity, and for good reason: an agent whose configuration holds no secret cannot be persuaded to disclose one. Prompt injection, where crafted text steers a model into following instructions it should not, loses one of its most valuable targets.

The effective principal set view shows what remains. An agent that can execute code, call arbitrary web addresses, or invoke tools that run commands on the host is a path-one actor of unusual flexibility: its behaviour is decided at run time by inputs the operator does not fully control. If an agent's tools can reach the token endpoint, a successful injection does not need to steal a key; it can simply cause the agent to use the identity for the attacker's purpose. This is the instance-metadata technique that MITRE ATT&CK catalogues, reached through a new kind of client. The Metadata: true header raises the bar for naive forged requests, but an agent that can set headers on its outbound requests is not a naive client.

Three consequences follow, each grounded in the analysis above. First, an agent with general-purpose code or request tools should be treated as a principal in its identity's effective principal set in its own right, and its identity scoped as if it might be steered. Second, agents should not share user-assigned identities with other workloads, because the union rule then grants every co-tenant's operators the agent's reach, and the agent the co-tenants'. Third, attribution matters more, not less: when an agent acts unexpectedly, investigators need resource-level evidence of what the agent was asked and what it did, because the target service's log will only say that the identity acted.

Limitations and threats to validity

The model is derived entirely from public documentation as of 2026. Microsoft notes that how managed identities authenticate is an internal implementation detail subject to change, and service behaviour, including which management operations amount to code execution, varies by Azure service. A team applying the method must enumerate those operations for each resource type it uses; this article does not provide a complete list and does not claim one exists.

We report no empirical measurements. The three shapes in the evaluation are analytical constructions chosen to illustrate the paths, not samples from real tenants, and no claim is made about how common each shape is. A measurement study that sampled real environments under appropriate permissions would be the natural next step, and could quantify how often the effective principal set exceeds intent.

The analysis assumes the platform behaves as documented and excludes provider-side compromise. It also treats control-plane permissions coarsely; real role definitions are fine-grained, and a careful review must work at the level of the specific actions each role grants. Finally, path four is analysed only at the level of who can add or match a federated credential; the governance properties of federated credentials as a credential type, such as their lack of expiry and their relationship to app management policies, are a separate question that this article does not address.

Practitioner Toolkit

Copy-paste, strictly defensive artifacts you can use today. Nothing here attacks a real system.

function effective_principal_set(identity, inventory):
    members = empty set
    for resource in inventory.attachments(identity):
        members += inventory.principals_with_code_execution(resource)   # path 1
        members += inventory.principals_with_code_change(resource)      # path 2
    if identity.kind == 'user-assigned':
        members += inventory.principals_who_can_assign(identity)       # path 3
        for credential in inventory.federated_credentials(identity):   # path 4
            members += external_subjects_matching(credential)
        members += inventory.principals_with_contributor_or_owner(identity)
    return members

function review(identity, inventory, intended_owners):
    excess = effective_principal_set(identity, inventory) - intended_owners
    report(identity, excess, inventory.role_assignments(identity))

RULE shared-managed-identity
  A user-assigned managed identity MAY be attached to more than one resource ONLY IF:
    1. every attached resource has the same owner team, AND
    2. the principals able to deploy, edit code or run commands are identical on every attached resource, AND
    3. no attached resource exposes general-purpose code or request tools to untrusted input (for example an AI agent), AND
    4. each federated identity credential on the identity has a named owner and a recorded review date.
  OTHERWISE create a separate identity, or use a system-assigned identity where per-resource attribution is required.

Glossary

Managed identity

A Microsoft Entra ID service principal of a special type that Azure creates and maintains for a resource, whose credential no operator handles.

System-assigned identity

A managed identity enabled on a single resource, deleted with it, and not shareable.

User-assigned identity

A managed identity created as a standalone resource that can be associated with more than one resource.

Effective principal set

This article's term for every principal able to cause a token issued to a given managed identity to be used for a purpose it chooses.

Control plane

The management interface used to create, configure and deploy to resources, as distinct from the data plane used to read and write their contents.

Federated identity credential

A trust rule on an application or user-assigned identity that accepts tokens from an external issuer matching a specific subject and audience.

Server-side request forgery (SSRF)

An attack in which a server is tricked into sending a request chosen by the attacker, for example to an internal endpoint.

Client-credentials grant

The OAuth 2.0 flow in which a client obtains a token on its own behalf, with no user involved.

Prompt injection

Crafted input that steers a language model into following instructions other than those its operator intended.

References

1. Microsoft Learn: Managed identities for Azure resources frequently asked questions
2. Microsoft Learn: Managed identity best practice recommendations
3. Microsoft Learn: Configure a user-assigned managed identity to trust an external identity provider
4. IETF RFC 6749: The OAuth 2.0 Authorization Framework
5. IETF RFC 7519: JSON Web Token (JWT)
6. IETF RFC 7523: JWT Profile for OAuth 2.0 Client Authentication and Authorization Grants
7. NIST SP 800-207: Zero Trust Architecture
8. OWASP: Server Side Request Forgery
9. MITRE ATT&CK T1552.005: Unsecured Credentials: Cloud Instance Metadata API