Direct Managed Identity or Federated Managed Identity?

Post author: Daniel Bradley – Microsoft Entra / Microsoft Graph – May 25 2026
Reading time: ~4 minutes

What changed

A wave of community‑built tools now offers one‑click assignment of Microsoft Graph permissions to Azure Managed Identities. The convenience of that approach prompted a deeper look at the alternative: federating a Managed Identity to an App Registration and granting the Graph permissions to the App Registration instead. Both patterns deliver secret‑less, app‑only access to Microsoft Graph, yet they differ in where the permissions live, how tokens are obtained, and how the identity lifecycle is governed.

Provider comparison

Aspect	Direct permission assignment to Managed Identity	Federated (WIF) with App Registration
Identity that holds Graph permissions	Service principal that backs the Managed Identity	Service principal of the App Registration
Token acquisition	Single step – Azure resource requests an MSI token for Graph directly	Two steps – MSI token for the Managed Identity, then token exchange for the App Registration’s Graph token
Permission management	PowerShell/CLI/Graph API only (no UI view)	Entra admin UI or Graph API
Lifecycle coupling	Permissions disappear when the resource (and its System‑Assigned MI) is deleted	Permissions persist until the App Registration is removed; multiple MIs can share the same App Registration
Reusability	1‑to‑1 relationship – each MI gets its own set of permissions	1‑to‑many – up to 20 federated identities can point to a single App Registration
Operational overhead	Minimal – only one identity object to create and monitor	Slightly higher – need to configure Federated Identity Credential and maintain two objects
Auditability	Requires Graph queries to list permissions; not visible in the Enterprise Applications blade by default	Permissions appear in the UI under the App Registration’s "API permissions" tab, making audits straightforward
Typical cost impact	No extra App Registration license; only the underlying resource cost	May require additional App Registration (free tier usually sufficient) but adds a small management overhead

Direct Managed Identity (DM‑MI)

1. Setup – Enable a System‑Assigned or User‑Assigned Managed Identity on the Azure resource.
2. Permission grant – Use Microsoft Graph PowerShell or the Graph API to add Microsoft.Graph.* scopes to the Service Principal that represents the Managed Identity.
3. Token request – The resource calls the local MSI endpoint (http://169.254.169.254/metadata/identity/oauth2/token) with the resource=https://graph.microsoft.com/ parameter. Entra ID validates the direct assignments and returns a token containing the requested scopes.
4. Lifecycle – When the resource is removed, a System‑Assigned MI is automatically deleted, taking its permissions with it. User‑Assigned MIs must be cleaned up manually.

Pros

• Fewer moving parts; no need to maintain a separate App Registration.
• Permissions are tightly coupled to the workload, reducing risk of orphaned credentials.

Cons

• Permissions are not listed under the Enterprise Applications UI; admins must filter or query via Graph.
• Initial permission grant requires a secondary App Registration (the one used to call Graph), which can feel like a hidden dependency.

Federated Managed Identity (WIF)

1. Create an App Registration – Register a new application in Entra ID.
2. Add a Federated Identity Credential – Define a credential that trusts the Managed Identity’s object ID (or a specific Azure resource scope). This tells Entra ID to accept tokens issued to that MI as proof of identity for the App Registration.
3. Assign Graph permissions – Use the Entra UI or Graph API to add the required Microsoft Graph scopes to the App Registration’s Service Principal.
4. Token flow:
   • The Azure resource obtains an MSI token for its own identity.
   • It then calls the token endpoint (https://login.microsoftonline.com/{tenant}/oauth2/v2.0/token) with grant_type=urn:ietf:params:oauth:grant-type:token-exchange, presenting the MSI token as the subject token.
   • Entra ID validates the federated credential and issues a Graph access token on behalf of the App Registration.
5. Lifecycle – The App Registration lives independently; you can retire a resource without affecting other workloads that share the same App Registration.

Pros

• Permissions are visible in the Entra portal, simplifying audits and change‑control processes.
• Supports separation of duties: resource owners manage MIs, IAM teams manage App Registrations.
• One App Registration can serve many resources, reducing duplication of permission sets.

Cons

• Requires two distinct identity objects and a token‑exchange implementation.
• Slightly more complex initial configuration; developers must handle the second‑step token request.

Business impact

Decision factor	Direct Managed Identity	Federated Managed Identity
Speed of onboarding	Faster for small, single‑purpose services because only one identity is created.	Slightly slower; needs App Registration and federated credential setup.
Governance & compliance	Harder to surface in UI; auditors may request Graph queries to verify permissions.	Permissions are UI‑visible, making policy enforcement and reporting easier.
Cost of mis‑configuration	Orphaned permissions are unlikely because they disappear with the resource, but hidden permissions can be missed during reviews.	Mis‑configured federated credentials can grant broader access than intended, especially when the same App Registration is reused across many resources.
Team structure	Works well for DevOps teams that own both the workload and its identity.	Aligns with organizations that separate platform operations from security/identity teams.
Future scalability	Scaling to dozens of workloads means creating dozens of Service Principals, each with its own permission set – manageable but potentially noisy.	A single App Registration can serve many workloads, keeping the permission matrix compact, but requires careful mapping of federated identities.

Choosing a path

• Isolated workloads (e.g., a single Function App that processes a specific queue) benefit from the direct‑assignment model. The permission set lives and dies with the function, reducing cleanup effort.
• Complex environments (e.g., a micro‑service ecosystem where several services need the same Graph read/write scope) gain operational clarity from a federated App Registration. Centralised permission management, UI auditability, and the ability to grant the same scope to up to 20 identities from one place simplify governance.
• Regulatory contexts that demand explicit evidence of who can call Graph often mandate the UI‑visible approach, nudging teams toward WIF.
• Development velocity may initially favor direct assignments, but as the number of services grows, the administrative burden of tracking dozens of hidden Service Principals can outweigh the early convenience.

Final recommendation

There is no universal winner. Evaluate the trade‑offs in light of your organization’s governance model, scale, and DevOps maturity. For a greenfield project with a small team, start with direct Managed Identity permissions to keep the pipeline lean. As the solution matures and cross‑team responsibilities emerge, migrate to a federated App Registration to gain auditability and reuse.

---

*For a step‑by‑step guide on assigning Graph permissions directly to a Managed Identity, see the official Microsoft Graph PowerShell documentation.
To explore federated identity credentials, review the Entra ID documentation on workload identity federation.