TL;DR: Azure access is split between Microsoft Entra ID directory roles and Azure resource-level RBAC, so legacy IGA that stops at the directory misses standing privilege across subscriptions, resource groups, and resources, according to Oleria Security. Effective governance requires mapping humans, managed identities, and service principals against actual resource usage, not just assigned roles.
At a glance
What this is: This analysis shows why Azure governance fails when teams certify directory roles without accounting for resource-level RBAC and workload identities.
Why it matters: It matters because IAM and IGA teams need a complete picture of effective Azure access across human and non-human identities before they can right-size privilege.
Context
Azure access governance fails when organisations treat Microsoft Entra ID and Azure RBAC as separate problems. Directory roles and resource permissions form one effective access model, so review cycles that only inspect the directory miss how privilege flows into subscriptions, resource groups, and individual resources.
That gap matters because managed identities and service principals can hold persistent Owner or Contributor access even when their workload need has changed. Key NHI challenges and risks in Azure are often not about hidden accounts, but about visible identities whose effective permissions are never re-certified against current use.
Key questions
Q: Where does Azure access governance fail when teams only review Entra ID roles?
A: It fails at the resource layer. Directory roles do not show the full effective permission set once Azure RBAC, inherited scopes, and nested group assignments are included, so teams may certify a narrow identity view while missing broad control-plane access across subscriptions and resources.
Q: Why are managed identities and service principals high-risk in Azure RBAC reviews?
A: Because they often carry durable permissions that outlive the workload need they were created for. If a service principal or managed identity still holds Owner or Contributor rights after the task changes, the organisation has standing cloud privilege that normal directory-centric governance will not remove.
Q: What do teams get wrong about access certification?
A: Teams often treat certification as proof that access is safe, when it is really only a decision process. The quality of the outcome depends on the context given to reviewers, including role, activity, and ownership. Without that context, approvals can simply preserve inherited access and outdated entitlements.
Q: What happens when guest access is not re-certifed after a project ends?
A: Guest accounts can retain resource permissions, nested group memberships, or delegated access long after their business purpose is gone. That creates lingering exposure in Azure even when the directory record still looks legitimate, because the entitlement outlives the engagement.
Technical breakdown
Why Azure directory roles do not describe effective access
Microsoft Entra ID directory roles govern identity administration, but Azure resource access is enforced through RBAC at management group, subscription, resource group, and resource scope. That means a user can have limited directory rights while still exercising broad control-plane permissions over Azure resources. The technical failure is not authentication, but incomplete authorisation visibility across two governance planes. Once scopes inherit downward, the effective permission set is larger than what a directory-only review shows. Practical implication: certify Azure access against both directory roles and resource scopes before concluding that privilege is acceptable. See the Azure RBAC and Service Principals Guide.
Practical implication: Certify Azure access against both directory roles and resource scopes before concluding that privilege is acceptable.
How managed identities and service principals create standing cloud privilege
Managed identities and service principals are workload identities, but they often receive durable RBAC assignments such as Owner or Contributor at subscription level. Those grants are not ephemeral just because the workload is machine-operated. The operational problem is that workload access can outlive the task, application, or deployment that justified it, especially when credential expiry is not tied to permission expiry. That creates standing privilege in a cloud plane many governance tools do not continuously reconcile. Practical implication: track workload identities as governed principals, not just technical app objects. See the Cloud Workload Identity Guide.
Practical implication: Track workload identities as governed principals, not just technical app objects.
Why continuous identity security graphs change the governance model
A continuous identity security graph correlates identities, resource permissions, and activity telemetry so teams can see granted access versus used access. That architecture matters because Azure privilege is distributed across multiple object types and inheritance layers, including guest users, groups, app registrations, and cross-tenant delegations. The value is not visualisation alone. It is the ability to compare entitlement against real usage and surface dormant or over-provisioned access that traditional IGA misses. Practical implication: build certification decisions from effective access evidence, not from static entitlement inventories. See the IGA Buyer's Guide.
Practical implication: Build certification decisions from effective access evidence, not from static entitlement inventories.
Threat narrative
Attacker objective: The objective is to retain or exploit durable Azure access that reaches beyond the scope originally intended by the organisation.
- Entry occurs through legitimate Azure identity assignment, typically via directory roles, app registrations, or subscription-scoped RBAC grants.
- Credential or entitlement abuse follows when managed identities, service principals, or guests retain broad permissions beyond their current business need.
- Escalation happens through inherited management group or subscription permissions that silently expand access to downstream resources.
- Impact is broad cloud control, secret exposure, or resource misuse because effective permissions were never continuously re-certified.
Breaches seen in the wild
- Azure Key Vault Contributor escalation 2024: Datadog found Azure Key Vault Contributor could add itself to access policies and read every secret, key and certificate in a vault.
- Storm-1283 OAuth apps abuse 2023: Storm-1283 added secrets to new and existing OAuth apps in Entra ID and used them to run Azure cryptomining VMs, costing victims up to $1.5 million.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Azure governance fails when directory certification is treated as the whole control plane. Azure access is split across Entra ID and resource RBAC, but governance teams often review only the directory layer. That leaves inherited subscription and resource permissions outside the certification boundary, which is a structural blind spot rather than a tooling nuisance. The practitioner conclusion is simple: effective access, not directory entitlement, is the unit of review.
Standing cloud privilege is the real problem, not merely over-assignment. Managed identities and service principals are supposed to represent workloads, but durable Owner and Contributor roles turn them into persistent control-plane actors. The issue is that workload identity governance often stops at issuance and inventory, while the actual risk lives in ongoing scope and usage. This is exactly the kind of gap NHI lifecycle management is meant to close, but only if it reaches Azure RBAC inheritance too.
Effective access graphs are becoming the new governance baseline for Azure. Static lists of accounts and groups cannot show who can actually change, read, or exfiltrate cloud resources once scope inheritance and cross-tenant delegation are in play. The article’s value lies in showing that certification, remediation, and audit evidence must be built from real activity data as well as entitlement data. Practitioners should treat this as a governance architecture shift, not a reporting enhancement.
Identity governance for Azure has to collapse the old boundary between human and non-human access reviews. Guests, admins, managed identities, and service principals all participate in the same effective access model, so separate review cadences create inconsistent risk decisions. The practical implication is that access governance has to be scope-aware across actor types, or the organisation will keep certifying the wrong layer.
From our research library:
- Nearly 60% of IT leaders cite restrictive cost and complexity as a weakness of legacy identity governance, according to the 2025 State of Identity Governance Report.
- Read next: Azure RBAC and Service Principals Guide
What this signals
Azure identity governance is moving toward effective-access review rather than entitlement review. Teams that continue to certify only directory objects will keep missing the resource-level permissions that determine what Azure identities can actually do. The shift is from inventory to usage-aware governance, where remediation is driven by the permissions that are exercised, not just the permissions that exist.
Cross-layer certification will matter more as workload identities proliferate. Managed identities, service principals, and guest accounts all contribute to the same Azure blast radius when scope inheritance is ignored. Practitioners should assume their next governance failure will come from the boundary between directory administration and resource control, not from either layer alone.
For practitioners
- Map effective Azure access across both layers Review Microsoft Entra ID directory roles and Azure RBAC assignments together, including management groups, subscriptions, resource groups, and resources.
- Certify workload identities against current use Identify managed identities and service principals with Owner or Contributor roles, then compare their assigned scope to real activity and current workload need.
- Re-certify guest and partner access at the resource layer Check whether guest accounts and external collaborators still hold nested group memberships or direct resource permissions after the project or engagement has ended.
- Reduce standing privilege with just-in-time access Replace persistent broad subscription roles with task-scoped elevation where the business process does not require continuous control-plane access.
Key takeaways
- Azure governance breaks when teams treat Entra ID roles as the full picture and ignore resource-level RBAC.
- Managed identities and service principals can retain standing cloud privilege even when workload demand has changed.
- Effective certification in Azure has to combine directory roles, resource scopes, and activity evidence, or dormant access will persist.
Related NHI Mgmt Group resources: Azure RBAC and Service Principals Guide · Cloud Workload Identity Guide · NHI Lifecycle Management Guide · IGA Buyer's Guide
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST CSF 2.0 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-05 — Overprivileged NHI | Service principals and managed identities are granted broad Azure roles that exceed workload need. |
| NHI-01 — Improper Offboarding | Guest accounts and obsolete workloads retain access after the business need ends. | |
| Recommendation — Review workload identities for excess Azure RBAC scope and remove privileges that are not required for current use. Offboard stale Azure identities and revoke their resource permissions when the project or workload ends. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The article centres on governing who can access Azure resources and at what scope. |
| Recommendation — Align Azure entitlements to current business need and continuously review effective access across scopes. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Service principal secrets, certificates, and rotation are part of the access model described. |
| Recommendation — Manage Azure authenticators so workload credentials are rotated, monitored, and retired on schedule. | ||
| MITRE ATT&CK | TA0006; TA0008 — Credential Access; Lateral Movement | Broad cloud permissions enable credential abuse and movement across Azure scopes. |
| Recommendation — Map broad Azure roles to credential-access and lateral-movement risk in your threat detection and review process. | ||
Key terms
- Effective Access: The actual permissions an identity can exercise after inheritance, nested groups, delegation, and object-level controls are evaluated. In Active Directory, effective access is more useful than direct membership because it reveals the true operational reach of a service account.
- Azure RBAC: Azure RBAC is Microsoft Azure's role-based access control system for managing who can do what on Azure resources. It assigns built-in or custom roles to users, groups, service principals, or managed identities at a subscription, resource group, or resource level, and evaluates permissions through Azure Resource Manager.
- Managed Identity: A cloud-provider-managed identity assigned to a compute resource, allowing it to authenticate to cloud services without storing credentials in application code.
- Service Principal: An application identity object in Microsoft Entra ID and Microsoft 365 that represents a specific app inside a tenant. It holds permissions, ownership, and configuration data that define what the application can do. In NHI governance, it is a high-value identity that should be reviewed like any other privileged account.
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 building or maturing an IAM programme, it is worth exploring.
Published by the NHIMG editorial team on October 21, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org