Glossary

Identity blast radius: what one compromised account can reach

A plain definition of identity blast radius for Microsoft Entra ID and Azure, the directory edges that make it up, a manual way to measure it at any license level, and how to shrink it.

Identity blast radius is everything an attacker can reach from one compromised account: the roles it holds, the groups that grant those roles, the applications it owns, the permissions those applications hold, the Azure subscriptions and resources its roles cover, and the data its consent grants expose. It is a measure of impact, not of likelihood. Two accounts with the same password hygiene can have very different blast radii, and the difference is decided entirely by what the directory lets each one reach.

The phrase comes from cloud infrastructure, where it describes how many resources one fault or one leaked key can affect. Applied to identities it asks a sharper question: if this user, service principal, or managed identity were taken over right now, what could the attacker do before anyone noticed?

Identities, not VPCs

Generic glossaries define blast radius in terms of VPCs, IAM policies, and storage buckets. In an Entra tenant the unit of compromise is an identity, and Microsoft's own taxonomy splits identities into human and non-human, with workload identities (applications, service principals, and managed identities) on the non-human side. A blast radius that only counts human administrators leaves out the identities whose credentials are client secrets and certificates rather than a person's password, and those often hold the broadest permissions in the tenant.

The edges that make up a blast radius in Entra ID and Azure

A blast radius is a walk through relationships, or edges, in the directory. Four chains matter most in a Microsoft tenant.

  1. User to group to role-assignable group to directory role. Microsoft recommends assigning Entra roles to role-assignable groups when an external governance system manages groups, and a Privileged Role Administrator can delegate a role by making someone the owner of such a group. Follow the chain and "member of one group" becomes "holds Global Administrator". Eligible assignments count too: Microsoft states there is no difference in the access granted by a permanent and an eligible assignment, only in whether it is held all the time.
  2. User to owned app registration to service principal to Graph application permission. One application object in the home tenant is the blueprint for the service principal, which is what actually authenticates and is authorized in your tenant. The registration is where client secrets, certificates, and federated identity credentials are added. If the service principal holds RoleManagement.ReadWrite.Directory, Microsoft's own caution is that it can grant additional privileges to itself, other applications, or any user, including adding members to Entra roles. Owning a registration is an edge to a second identity with permissions of its own.
  3. Service principal or user to an Azure RBAC role. Azure RBAC is a separate authorization system with four scope levels: management group, subscription, resource group, and resource. Microsoft classifies Owner, Contributor, Reservations Administrator, Role Based Access Control Administrator, and User Access Administrator as privileged administrator roles; Owner can assign roles, and User Access Administrator can assign itself or others Owner. A Global Administrator has no Azure access by default but can elevate to User Access Administrator at root scope, covering every subscription and management group in the tenant.
  4. OAuth grant to mailbox data. By default, users can consent to applications for permissions that do not require administrator consent, such as an app reading their own mailbox. Once consent is given in an illicit consent grant attack, the application has account-level access to data without needing an account in the organization, and Microsoft notes that password resets and MFA are not effective against it.

Why the portal cannot show it in one view

No single page in the Microsoft Entra admin center answers "what can this account reach". Directory roles, group membership, PIM eligibility, app ownership, and consent grants live in different blades: the App registrations page lists application objects, while Enterprise applications lists service principals with their permissions and who consented. Azure role assignments sit in a different system, and Privileged Role Administrators, Security Administrators, and Security Readers do not by default have access to view Azure resource role assignments in PIM. Microsoft's own illicit consent guidance calls the admin center method thorough but one user at a time. You can assemble the answer, but you have to walk the edges yourself.

How to measure it by hand at any license level

Nothing below requires Entra ID P2. Pick one account and record each hop.

  1. Directory roles. List the account's active role assignments and its group memberships, and check whether any group is role-assignable. If PIM is in use, include eligible assignments.
  2. Owned applications. On the App registrations page, list every registration the account owns. For each, open the matching service principal under Enterprise applications and record its application permissions and who consented. Treat each service principal as a second identity and repeat the walk.
  3. Azure access. Check role assignments at each of the four scope levels where the account or its groups appear. For Global Administrators, check whether the "Access management for Azure resources" toggle is set to Yes; the setting is per user, and elevate and remove events appear in the Entra audit logs and the Azure activity logs.
  4. Consent grants. Inventory the applications the account has consented to, in the admin center one user at a time or with Microsoft's PowerShell script that exports all OAuth consent grants for all users to a CSV.
  5. Write down the reachable set. Roles, groups, applications, subscriptions, resource groups, mailboxes: that list is the blast radius. Start with holders of Global Administrator, Privileged Role Administrator, and subscription Owner; a Global Administrator can read and modify almost every administrative setting, and a Privileged Role Administrator can grant themselves or others more privilege by assigning roles.

Where Orbitra fits

Orbitra calculates identity impact before it acts. Human and non-human identities (users, groups, app registrations, service principals, OAuth grants, and managed identities) sit in one graph with blast radius traversal across roles, permissions, and Azure RBAC, read through Microsoft Graph and Azure APIs and starting read-only. Blast radius shows what an identity can reach before you act, and what remains reachable after; it measures impact, not whether a route has been exploited. In Recommend mode, your team executes the response; in Approve mode, a named person signs off before Orbitra executes. See how it works or how the read-only connection starts.

How to shrink it

Every item on Microsoft's own list removes an edge, and removing edges is the only way a blast radius gets smaller.

  • Assign Global Administrator to fewer than five people; the role has essentially unrestricted access.
  • Apply least privilege in Microsoft's three dimensions: a specific set of permissions, over a specific scope, for a specific period of time.
  • Where PIM is licensed, make administrators eligible rather than permanently active, and run recurring access reviews to remove assignments nobody needs.
  • Use cloud-native accounts for Entra roles rather than on-premises synced accounts, and remove elevated root-scope access as soon as the work is done.
  • Allow user consent only for verified publishers, and review service principals that hold privileged roles as closely as the people who do.

Identity graph (security) versus identity graph (adtech)

Two unrelated things share the phrase. In security, an identity graph is a model of identities and the relationships between them: users, groups, applications, service principals, roles, permissions, and the Azure scopes they reach. Blast radius is a query against that graph from one starting node, and an attack path is one route through it. In advertising technology, an identity graph links devices, cookies, and email addresses to one person for targeting and measurement. The two share a name and nothing else; this page is about the security meaning.

Browse the full privileged identity glossary, or go straight to privileged identity response, non-human identity, Directory.ReadWrite.All, and containment verification. If an account with a large blast radius has already been taken over, start with the guide to a compromised Entra admin account.

Sources

See it on your tenant

Find the privilege that can reach your critical systems.

Get a privilege exposure review Glossary