Review an Azure tenant and you will find them: a guest account from a partnership that ended two years ago, still enabled; a group whose name says reporting and whose role assignments say rather more; an application granted broad permissions during a deadline. None of these is an incident. The question is what they connect to.

Azure exposure is not an AWS article with different service names. The center of gravity is identity: Entra users, groups, guests, app registrations, service principals, managed identities, and the scopes where those identities can act. In Azure, the path often starts with identity and ends at data.

The same scarcity collapse applies here. Tenant reconnaissance, role analysis, and path chaining can all be automated now. The old comfort was that stale accounts and over-powered groups were safe because nobody would bother to find them; now automation will. So the defensive move is to map the paths first and remove the easy chains.

Start with Entra ID. Who can sign in, which accounts are guests, which groups convey power, which applications hold sensitive permissions — and which identities can become privileged through assignment, membership, consent, or eligibility.

Then follow Azure RBAC down the hierarchy: management groups, subscriptions, resource groups, resources. Inheritance is convenient for administration and dangerous when broad roles land higher than the workload actually requires.

Privileged Identity Management changes what a review means, because active access is not the whole story. Eligible access, activation requirements, approvers, and review cadence determine whether privilege is controlled or merely dormant.

Conditional Access, strong authentication, device conditions, and break-glass discipline decide whether an identity path is hard to use or easy to abuse. A powerful role behind weak sign-in controls is still a reachable path.

Defender for Cloud's attack-path analysis earns its place by prioritizing combinations instead of isolated misconfigurations. Attack paths matter because separate low-grade weaknesses can become one working route to impact.

Sensitive systems are what make routes matter. Key Vault access, storage account keys, SAS tokens, database roles, and public exposure all change the severity of the identity path that reaches them. And identity is the prize precisely because it endures: a compromised identity does not break in, it logs in — it can move sideways, and it can leave a quiet way back in that outlives the fix and the next password change.

What to check now: global administrators, subscription owners, PIM-eligible users, stale guests, service principals and managed identities with strong permissions, app permissions, Key Vault access, and every Defender for Cloud attack path that ends at sensitive data.

The output should be a path map, not a prettier inventory: which identities can cross boundaries, what they can reach, which sensitive systems sit at the end, and which single control would break the chain.