Azure role misconfiguration exposes identity and network access

At a glance

What this is: This analysis shows how over-privileged Azure roles and an API flaw can turn a weak identity into access to cloud assets and connected networks.

Why it matters: It matters because IAM teams must treat role scope, service-specific permissions, and network-connected secrets as one governance problem across NHI, human, and workload identities.

By the numbers:

• In Azure, there are more than 400 built-in roles, which can be divided into 2 categories: Generic and service-specific.
• This problem recurs in 10 different roles.
• There are more than 400 built-in roles, which can be divided into 2 categories.

👉 Read Token Security's analysis of Azure role over-privilege and VPN key leakage

Context

Azure role-based access control is meant to make authorization easier by grouping permissions into reusable roles and scopes. The problem in this case is that a role name, its description, and its effective permissions do not line up cleanly, which makes identity governance decisions less reliable than they appear at assignment time.

For IAM and NHI teams, the issue is not only privilege depth but also privilege shape. A role that can read broadly, inspect deployments, or expose network-related secrets can become a path from identity misconfiguration to wider environment exposure, especially where cloud access is tied to internal connectivity.

Key questions

Q: How should teams handle Azure roles that appear service-specific but still expose broad read access?

A: Teams should inspect the effective permissions, not the role label, before approving access. If a role includes broad read actions or redundant permissions, replace it with a custom role that limits exposure to the minimum resource set required for the task. Treat broad read access as a privileged capability because it enables discovery, planning, and secret harvesting.

Q: Why do over-privileged read roles increase real-world compromise risk?

A: Because read access often reveals enough to support the next stage of attack. Attackers can enumerate resources, identify sensitive systems, discover scripts and environment variables, and map privilege relationships without ever changing a configuration. In cloud environments, visibility is frequently the path to escalation.

Q: What breaks when VPN secrets are exposed through identity permissions?

A: The separation between identity governance and network access breaks down. A leaked VPN pre-shared key can allow an attacker to join a trusted site-to-site connection and move from cloud control-plane access into internal network reach. That makes the secret itself part of the identity attack surface, not a separate issue.

Q: Who should own the review of roles, permissions, and network-connected secrets?

A: Ownership should sit across IAM, cloud security, and network teams, because the failure spans all three control planes. A role review that ignores VPN keys, deployment outputs, or service metadata is incomplete. The practical test is whether one access decision could expose both cloud resources and connected internal networks.

Technical breakdown

How Azure RBAC scope turns a role into broad exposure

Azure RBAC combines a security principal, a role definition, and a scope. When the scope is broad, such as a subscription or management group, any overly permissive action in the role definition applies across many resources at once. The danger is that built-in roles can look service-specific while still carrying generic permissions such as */read, which widens discovery across apps, storage, logs, and network objects. That makes the effective blast radius much larger than the role name suggests.

Practical implication: review both the role definition and the assigned scope before approving any Azure entitlement.

Why generic read access becomes an attack primitive

A read-only permission is not harmless when it exposes deployment metadata, application settings, environment variables, key vault references, diagnostics, or backup locations. Attackers do not need write access to use this information for credential harvesting, environment mapping, and privilege escalation planning. In cloud environments, discovery is often enough to move from one compromised identity to many more, especially when secrets are embedded in configuration or accessible through adjacent services.

Practical implication: treat broad read access as a sensitive permission class and restrict it with custom roles wherever possible.

How an Azure API secret leak extends identity risk into network access

A leaked VPN pre-shared key changes the problem from cloud authorization to cross-boundary access. A pre-shared key is a shared secret that authenticates site-to-site connectivity, so once it is exposed, the attacker can present as a trusted network participant rather than a blocked outsider. That creates a bridge from identity compromise into internal network access, where cloud roles and network trust overlap in ways many access reviews do not model well.

Practical implication: inventory network-connected secrets alongside identity roles so a single credential review covers both planes.

Threat narrative

Attacker objective: The attacker aims to convert a low-value identity into broad cloud discovery and then cross-boundary network access.

1. Entry occurs when a weak identity receives an over-privileged Azure role that exposes more read access than expected, giving the attacker an initial foothold in the control plane.
2. Escalation occurs when that read access is used to enumerate deployments, scripts, and permissions, then extract a VPN pre-shared key from Azure API behavior.
3. Impact occurs when the attacker uses the leaked key to join the site-to-site VPN path and reach internal cloud assets and on-premises networks.

Breaches seen in the wild

• Azure Key Vault privilege escalation exposure — Azure Key Vault Contributor role misconfiguration enabled privilege escalation.
• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.

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

NHI Mgmt Group analysis

Identity blast radius is now defined by role shape, not role name. Azure RBAC is supposed to express least privilege through role, principal, and scope, but this research shows that the effective permission set can be much broader than the label implies. That means governance cannot stop at catalogue review or entitlement approval. Practitioners should assume the blast radius is determined by the actual action set, not the intended service description.

Broad read access is an escalation path, not a benign default. When a role can reveal deployments, logs, resource metadata, and operational settings, it becomes a reconnaissance platform for future abuse. That weakens the old assumption that read-only access is low risk. IAM and NHI programmes need to treat visibility into secrets-bearing systems as a privileged capability, even when write access is absent.

Trust in cloud control planes fails when identity and network secrets overlap. The VPN key leak shows that a permissions issue can become a network trust issue in one step. This is where zero trust thinking matters: access to one plane should not imply hidden access to another. Practitioners should re-evaluate whether identity reviews, secrets reviews, and network reviews are still separated by organisational silos.

Service-specific roles are only safe when their effective permissions stay service-specific. The article shows that some built-in roles include redundant generic read permissions alongside narrower actions, which makes the role appear bounded while behaving broadly. That breaks a core governance assumption: that descriptive role names reliably communicate scope. The implication is that role design, not just role assignment, must be under continuous control.

Over-privilege becomes systemic when built-in roles are reused as governance shortcuts. The fact that the same pattern appears across multiple roles signals a platform-level problem, not an isolated misconfiguration. Governance teams should treat built-in role review as a recurring control point and not as a one-time hardening exercise.

From our research:

• 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, according to The State of Non-Human Identity Security.
• A separate finding from our research shows that 91% of former employee tokens remain active after offboarding, which reinforces how persistent identity exposure becomes when lifecycle control is weak.
• For a broader governance view, see Ultimate Guide to NHIs , Key Challenges and Risks for the controls that limit over-privilege and visibility gaps.

What this signals

Identity blast radius is becoming a programme design issue, not just a role-review issue. When cloud RBAC can expose secrets, diagnostics, and network trust paths, the control boundary shifts from individual entitlements to the full access graph. Teams should align access review, secrets handling, and network governance so one weak role cannot become a multi-plane exposure event.

Role catalogues need to be treated as living attack surfaces. A built-in role that looks harmless in documentation can still carry hidden discovery power in practice, so periodic entitlement audits are no longer enough on their own. Practitioners should pair review workflows with compensating controls such as custom roles, scope minimisation, and monitoring of sensitive read paths.

The pattern maps cleanly to Zero Trust principles because trust cannot be inferred from an internal role assignment or a network label. The NIST SP 800-207 Zero Trust Architecture model is useful here because it forces teams to separate identity, resource, and network trust decisions rather than letting one permission leak define all three.

For practitioners

• Audit built-in role definitions before assignment Review effective permissions, not just role names, and reject any role that includes broad read actions beyond the intended service boundary.
• Restrict scope to the smallest workable resource boundary Prefer resource group or single-resource scope over subscription-wide or management-group-wide assignment when the task does not require broad visibility.
• Replace generic built-in roles with custom roles Create narrowly tailored roles that expose only the required actions, and remove redundant */read permissions from any role used in production.
• Inventory secrets reachable through read access Map which roles can reveal environment variables, deployment outputs, diagnostics, key vault references, or VPN-related secrets so secret exposure is reviewed with IAM.

Key takeaways

• Azure built-in roles can look narrow while still carrying broad read permissions that materially expand attack surface.
• The evidence shows this is not isolated, with the same over-privilege pattern recurring across multiple roles and creating a reusable attack primitive.
• Teams should treat role design, scope, and network-connected secrets as one governance problem, because a single weak identity can bridge cloud and on-premises access.

Key terms

• Azure RBAC Scope: Azure RBAC scope is the boundary within which a role assignment is effective, such as a subscription, resource group, or single resource. In practice, it determines how far a permission can travel if the role is broader than intended, making scope one of the most important controls in cloud identity governance.
• Over-privileged Role: An over-privileged role grants more access than the task requires. In cloud and NHI governance, that usually means broader read, write, or secret-exposure rights than the business need justifies, which increases blast radius and creates attack paths that are easy to overlook in catalogue-based reviews.
• Site-to-Site VPN Pre-shared Key: A site-to-site VPN pre-shared key is a shared secret used to authenticate a network tunnel between environments. If that key is exposed, an attacker may be able to join trusted connectivity and move from identity compromise into internal network access, which makes the secret part of the identity attack surface.
• Identity Blast Radius: Identity blast radius is the amount of environment exposure that can be reached from one compromised identity, role, or token. It is shaped by permissions, scope, secrets access, and network trust, and it is the practical measure of how quickly a single mistake becomes a broad incident.

What's in the full article

Token Security's full blog covers the operational detail this post intentionally leaves for the source:

• Exact Azure role names and permission listings that show where the broad read access appears
• The proof-of-concept path used to extract the VPN pre-shared key from Azure API behaviour
• The full table of 10 affected built-in roles and their overlapping actions
• Token Security's mitigation guidance for auditing, scoping, and replacing affected roles

👉 The full Token Security post shows the affected role definitions, the API leak path, and the mitigation details.

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 programme maturity, it is worth exploring.