m365expertise MICROSOFT SECURITY EXPERTISE
Entra ID

Managed identities: the Graph and Azure privileges nobody looks at

m365expertise·30 September 2026·8 min·1,926 views

Managed identities are excellent practice: no secret to store, no certificate to renew. But they are still identities, sometimes with considerable rights. Because they do not show up where people usually look for applications, their privileges often escape review.

A reminder: what a managed identity is

A managed identity is a service principal created and managed by Azure for a resource: virtual machine, Function App, Logic App, Automation account, App Service and so on. Code running on the resource obtains tokens from a local endpoint, with no secret to handle. There are two kinds:

  • System-assigned: tied to a single resource and deleted with it.
  • User-assigned: a standalone Azure resource that can be attached to several resources at once.

In Entra ID, these identities appear as service principals of type "ManagedIdentity". They are not listed under App registrations and are hidden by the default filter in Enterprise applications.

Hidden privileges

A managed identity can receive three categories of rights, each managed in a different place:

  1. Azure RBAC roles on subscriptions, resource groups or resources, such as Contributor or Owner.
  2. Microsoft Graph application permissions (or other APIs), such as User.ReadWrite.All, Mail.Send or RoleManagement.ReadWrite.Directory. The portal offers no interface to grant them: they are assigned through PowerShell or the API, which makes them even less visible.
  3. Entra ID directory roles, assigned as for any service principal.

We regularly come across Automation accounts with very broad Graph permissions for a single provisioning script, or user-assigned identities shared across many resources "for convenience".

The real escalation path

The key point is this: anyone who can run code on the resource inherits the privileges of its managed identity. A user with Contributor on a Function App can change its code; an operator of an Automation account can start a runbook; an administrator of a virtual machine can query the local endpoint. In each case they obtain a token as the identity.

The direct consequence. A managed identity holding a privileged directory role or sensitive Graph permissions turns the resource that carries it, and everyone who administers that resource, into a Tier 0 asset. Azure administration then becomes a path to control of Entra ID.

Inventorying identities and their rights

A useful inventory brings both worlds together, Entra ID and Azure:

  • list through Microsoft Graph the service principals whose type is "ManagedIdentity";
  • for each one, retrieve app role assignments (Graph and other API permissions) and any directory roles;
  • on the Azure side, list the RBAC assignments of these identities across all subscriptions, for example with Azure Resource Graph or Azure CLI;
  • identify, for each identity, the resources that use it and the people who can administer those resources;
  • spot orphaned identities: user-assigned identities attached to no resource, or whose resource is no longer in use.

Applying least privilege

Once the inventory is in place, reducing rights follows a few simple principles:

  • One identity per purpose: avoid sharing a user-assigned identity between unrelated applications.
  • Targeted permissions: prefer Sites.Selected to access to all of SharePoint, or Exchange Online application scoping to access to every mailbox.
  • Tight Azure roles: at resource or resource group level rather than subscription level, and rarely Owner.
  • Protect the hosting resources: restrict who can change the code or runbooks, or sign in to the virtual machines concerned.
  • Monitor: alert when new Graph permissions or directory roles are assigned to managed identities.

What an audit checks

  • A complete inventory of managed identities and their type.
  • The Microsoft Graph and other API permissions granted to each one.
  • Entra ID directory roles assigned to managed identities.
  • Azure RBAC roles and their scope.
  • The people able to run code on the resources hosting the most privileged identities.
  • Orphaned identities, or identities shared without justification.
Was this article useful?
4.3 / 5 · 173 ratings