Azure identity security depends on effective permissions, not roles

At a glance

What this is: This is a practitioner checklist for Azure identity security, with the core finding that real risk comes from effective permissions, not the role names people think they assigned.

Why it matters: It matters because IAM, IGA, PAM, and cloud security teams need to govern both human and non-human identities across Azure scopes, or inherited access and standing privilege will outpace manual review.

By the numbers:

• Only 5.7% of organisations have full visibility into their service accounts.
• 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface.
• 90% of IT leaders say properly managing NHIs is essential for a successful zero-trust implementation.
• NHIs outnumber human identities by 25x to 50x in modern enterprises.

👉 Read Veza’s checklist for Azure identity security and access control

Context

Azure identity security is really a question of effective permissions. Role names, scopes, and conditional rules can look tidy on paper while inheritance, nested groups, and non-human identities create a much larger action surface than most teams expect. The article argues that the platform is not the weak point. Configuration, review discipline, and lifecycle control are.

That framing matters for IAM because Azure combines human admin access, service principals, managed identities, guests, and workload permissions in one control plane. If teams cannot answer who can take what action on which service and which data, they cannot prove least privilege, contain blast radius, or produce reliable audit evidence. For background on the problem space, see the Ultimate Guide to NHIs and the section on effective permissions in Azure role design.

The starting position here is typical for cloud estates, not exceptional. Most programmes struggle with inherited access and identity sprawl once Azure reaches production scale.

Key questions

Q: What breaks when Azure teams rely on assigned roles instead of effective permissions?

A: Assigned roles can hide inherited access, nested group grants, and data-plane actions that materially widen what an identity can do. Teams think they are certifying one scope, but the real exposure sits across subscriptions, resource groups, and custom roles. The fix is to review effective permissions, because that is the access attackers and insiders can actually use.

Q: Why do non-human identities make Azure access reviews less reliable?

A: Non-human identities do not change jobs, leave the company, or naturally trigger revocation workflows, so they keep durable access long after the original need has passed. In Azure, that becomes worse when group nesting and inheritance obscure the real scope. Reviews must therefore focus on lifecycle, not just on entitlement lists.

Q: How do security teams know whether least privilege is actually working?

A: Least privilege is working when identities have narrowly scoped permissions, unused credentials are removed or quarantined, and repeated access reviews consistently shrink entitlements. A good signal is whether a compromised identity would be unable to move beyond one bounded workflow. If broad resource reach still exists, the control is not effective.

Q: Who is accountable when over-privileged Azure identities create a breach path?

A: Accountability sits with the programme that owns identity governance, cloud configuration, and lifecycle control, not with the cloud provider alone. Azure secures the platform layer, but organisations decide who can do what inside it. That means IAM, cloud security, and control owners all share responsibility for effective permissions, revocation, and evidence.

Technical breakdown

Effective permissions in Azure RBAC and ABAC

Azure authorization is shaped by the combination of role assignments, inheritance, and conditions. RBAC defines what an identity can do, while ABAC narrows that access with attribute-based rules tied to resource context. In practice, the effective permission is the union of all inherited and direct grants, plus any data-plane actions that may be hidden inside a custom role. That is why a title or group membership rarely tells the whole story. The technical risk is not the model itself, but the gap between intended access and the actual action surface exposed at subscription, resource group, and resource level.

Practical implication: Review effective permissions, not just assigned roles, before you approve access changes or certify accounts.

Why non-human identities break manual review

Most Azure environments now depend on service principals, managed identities, and other non-human identities that accumulate durable rights over time. Unlike humans, these identities do not move roles, lose context, or get naturally removed when a project ends. That means manual access reviews often miss the real risk, especially when permissions are inherited through groups or management groups. The control problem is lifecycle. If issuance, scope, rotation, and offboarding are not explicit, the identity keeps working long after the business reason for access has expired.

Practical implication: Build lifecycle checkpoints for service principals and managed identities, then tie them to expiry and revocation workflows.

Why posture and evidence need to be attached to the resource

Cloud security breaks down when policy and evidence live outside the resource they are meant to govern. Azure security posture management works best when new subscriptions inherit policy at creation time, findings have owners, and exceptions expire by default. The same principle applies to audit evidence. Teams need repeatable records of role assignments, access reviews, policy assignments, and configuration state, otherwise compliance becomes a manual hunt. Microsoft Defender for Cloud, Microsoft Purview, and Sentinel each support parts of the picture, but the key technical requirement is continuous visibility into control state and drift.

Practical implication: Attach policy, logging, and evidence generation to the platform lifecycle so governance scales with the environment.

Threat narrative

Attacker objective: The objective is to turn one seemingly limited Azure identity into broad tenant-wide control over resources, data, or persistence.

1. entry: Initial access is often created through over-broad Azure permissions, guest access, or a non-human identity that was never scoped tightly enough for the workload it serves.
2. escalation: Inheritance, group nesting, and custom roles can turn a narrow-looking grant into wide effective permissions, allowing an attacker or insider to expand control without changing the original assignment.
3. impact: Once effective permissions are understood, the attacker can access data, alter configurations, or persist in the tenant through standing privilege and hidden scope.

Breaches seen in the wild

• Coupang Signing Key Breach — Unrevoked signing key credentials expose 33.7 million records after employee offboarding failure at Coupang.
• Microsoft SAS Key Breach — Overly permissive Azure SAS token exposes 38TB of Microsoft internal data including secrets and credentials.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Effective permissions are the real security boundary in Azure. Role names and assignment intent are not enough once inheritance, group nesting, and data-plane actions stack together. The operational question is not who was granted access in theory, but what actions an identity can actually execute across scopes. Practitioners should treat effective permissions as the governing unit of risk.

Non-human identity sprawl makes Azure governance a lifecycle problem, not a review problem. Service principals, managed identities, and other durable machine identities do not behave like humans, so annual or quarterly reviews are too slow to reflect real exposure. This is why expiration, explicit issuance, and revocation logic matter more than static entitlement lists. Teams should redesign review processes around identity lifecycle events, not calendar dates.

Azure posture management fails when exceptions become an operating model. Policies that land late, findings without owners, and exemptions that never expire create a permission state that drifts away from intended control. That drift is not just a compliance issue. It is the mechanism by which blast radius expands silently. Practitioners need a control model where exceptions are temporary by default.

Visibility into effective access is becoming the prerequisite for credible zero trust in cloud estates. Zero trust depends on continuous verification, but Azure’s nested permissions and non-human identities make verification impossible without clear access intelligence. The result is an identity blast radius problem: teams believe they have tight control while hidden inheritance keeps broad access alive. The implication is that cloud identity governance now needs to be measured by what can be acted on, not by what was assigned.

From our research:

• Only 5.7% of organisations have full visibility into their service accounts, according to Ultimate Guide to NHIs.
• 79% of organisations have experienced secrets leaks, and 77% of those incidents caused tangible damage.
• For broader lifecycle context, Ultimate Guide to NHIs , Key Challenges and Risks shows why visibility gaps and over-privilege remain persistent control failures.

What this signals

Identity blast radius is the right way to think about Azure risk. Once you measure what identities can actually do across inherited scopes, the conversation moves from role administration to containment, and that changes how cloud teams prioritise review, revocation, and exception handling.

With 25x to 50x more NHIs than human identities in modern enterprises, programme design has to assume machine-scale entitlement growth. That means more automation around access discovery, more explicit expiry for temporary access, and more evidence generated at the point of change rather than at audit time.

Security teams should treat Azure governance as a continuous control system rather than a periodic certification exercise. If policy, telemetry, and offboarding are not tied to identity lifecycle events, standing privilege will keep outpacing manual review, even in otherwise mature IAM programmes.

For practitioners

• Map effective permissions, not intended roles Generate tenant-wide views that reconcile direct grants, inherited access, group membership, and custom role data actions before you certify access or approve exceptions.
• Put expiry on all temporary elevation Require time-bound elevation for admins, break-glass accounts, guest access, and service credentials that exist only for a project or incident.
• Inventory and scope non-human identities Inventory service principals and managed identities, then assign the smallest viable scope and revoke rights that are no longer tied to an active workload.
• Attach policy and evidence to subscription creation Make new subscriptions inherit the right policies at creation time, then capture access-review results and configuration evidence as part of normal operations.

Key takeaways

• Azure security fails when teams focus on assigned roles instead of effective permissions, because the real action surface is wider than the label suggests.
• Non-human identities are a governance problem as much as a security one, because durable access and weak lifecycle handling expand blast radius over time.
• The practical answer is continuous visibility, time-bound elevation, and evidence tied to policy changes, not more manual review of the same stale assignments.

Key terms

• Effective Permissions: Effective permissions are the access an identity can actually use after role inheritance, scope, and policy are applied. In Azure AI environments, they often matter more than the assigned role name because inherited rights can widen access to data, logs, and secret stores.
• Standing Privilege: Standing privilege is access that remains active even when no immediate task requires it. For NHI programmes, it is a common failure mode because long-lived credentials and persistent roles create unnecessary exposure. Reducing standing privilege usually means tighter expiry, on-demand access, and clearer review of who or what still needs access.
• Non-Human Identity (NHI): A digital identity assigned to a non-human entity such as a software application, service account, API key, bot, machine, or AI agent that enables it to authenticate and interact with systems without direct human involvement. NHIs now outnumber human identities in most enterprises by 25 to 50 times.
• Identity Blast Radius: The amount of damage a compromised identity can cause across systems, data, and infrastructure. In NHI environments, it is shaped by permissions, network reach, and administrative capability rather than by the credential alone. Reducing blast radius is a containment strategy that limits lateral movement and data exposure.

What's in the full article

Veza's full article covers the operational detail this post intentionally leaves for the source:

• Step-by-step Azure RBAC and ABAC examples that show how effective permissions are calculated across nested scopes.
• Practical walkthroughs for using Microsoft Entra ID, Conditional Access, and PIM to remove standing privilege.
• Operational guidance for service principals, managed identities, and guest access reviews in large Azure tenants.
• Evidence and audit workflows for proving access decisions across subscriptions, resource groups, and resources.

👉 The full Veza article covers Azure RBAC, ABAC, non-human identities, and access-review detail.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.