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.
Why This Matters for Security Teams
Assigned roles are a useful admin abstraction, but they are not the same as what an Azure identity can actually do. In Azure, effective access can expand through nested groups, inheritance from management groups and subscriptions, custom roles, and data-plane permissions that are easy to miss during review. That gap turns access certification into a compliance exercise rather than a real risk check.
This matters most where service principals, managed identities, and automation accounts are involved, because those non-human identities tend to be granted broad scopes to keep pipelines moving. NHI Management Group has repeatedly shown that privilege visibility is a recurring failure point, including in its Ultimate Guide to NHIs — Key Challenges and Risks and the Azure-specific Azure Key Vault privilege escalation exposure analysis. The pattern is familiar: assigned scope looks narrow, effective permission is much wider, and the exposure is only discovered after an incident or audit challenge. In practice, many security teams encounter the real blast radius only after a deployment failure or abuse path has already been tested by an attacker.
How It Works in Practice
effective permissions are the union of everything that contributes to authorisation at request time. For Azure, that usually means the assigned role, plus inherited permissions from higher scopes, plus group membership, plus custom role definitions, plus any data-plane permissions tied to the service being accessed. A reviewer who looks only at the directly assigned role can miss the exact action that would let an identity read secrets, modify a resource, or move laterally across subscriptions.
Practitioners should treat this as an access-path problem, not a naming problem. Current guidance from the OWASP Non-Human Identity Top 10 and NIST SP 800-53 Rev. 5 Security and Privacy Controls points toward reviewing what an identity can actually do, not just what was initially granted. In Azure terms, that means:
- Review effective permissions at the resource, resource group, subscription, and management group levels.
- Resolve nested groups and inherited role assignments before certifying access.
- Separate control-plane actions from data-plane actions, especially for storage, Key Vault, and resource providers.
- Check custom roles for wildcard actions and broad write privileges.
- Validate whether managed identities and automation accounts still need the scope they were given.
This is where manual review often breaks down, because effective permissions change as group membership, inherited scope, and custom role definitions change faster than certification cycles can keep up.
Common Variations and Edge Cases
Tighter permission review often increases operational overhead, requiring organisations to balance faster delivery against stronger access assurance. That tradeoff is especially visible in Azure environments that use platform teams, landing zones, and shared subscription models, where broad assignments are introduced to reduce friction.
There is no universal standard for every Azure estate, but current guidance suggests treating some cases as high-risk by default. For example, a service principal with a harmless-looking role can still gain powerful data access through a Key Vault policy, a storage role, or a custom role with unexpected actions. Likewise, a user in a nested group can appear low risk in the portal while still carrying effective rights that span multiple business units.
Security teams should also watch for situations where assigned-role reporting becomes misleading: deny assignments, management group inheritance, and resource-provider-specific actions can all change the answer. For that reason, many teams pair Azure reporting with identity governance evidence from NHI-focused research such as the Ultimate Guide to NHIs and incident patterns like the Microsoft Azure Key Breach write-up. The operational lesson is simple: assigned role reviews are a starting point, but they are not sufficient for real access assurance.
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 address the attack and risk surface, while NIST CSF 2.0, NIST Zero Trust (SP 800-207), NIST SP 800-63 and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 | Assigned roles can conceal over-privileged non-human identities. |
| NIST CSF 2.0 | PR.AC-4 | Effective access review supports least-privilege enforcement and certification. |
| NIST Zero Trust (SP 800-207) | PR.AC-3 | Azure permission inheritance creates trust assumptions that Zero Trust should challenge. |
| NIST SP 800-63 | Identity proofing is separate from the effective permissions an identity accumulates. | |
| NIST AI RMF | Governance should account for dynamic access risks in autonomous or automated workloads. |
Validate what identities can actually do, then recertify only the permissions that remain necessary.
Related resources from NHI Mgmt Group
- How should security teams govern effective permissions instead of just assigned roles?
- What breaks when teams rely only on direct entitlements instead of effective permissions?
- What breaks when Oracle SoD reporting relies on assigned roles instead of effective access?
- What breaks when help desk teams rely on phone numbers to confirm identity?
