Notifications
Clear all
Topic starter
06/07/2026 9:39 am
TL;DR: Azure built-in roles can grant broader read access than their descriptions suggest, and an Azure API flaw can leak VPN keys, creating a chain from a weak identity to cloud and on-premises access, according to Token Security researchers. The trust boundary here is the role definition itself, not just the attacker’s foothold.
NHIMG editorial — based on content published by Token Security: Azure's Role Roulette, covering over-privileged Azure roles and an API vulnerability that can leak VPN keys
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.
Questions worth separating out
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.
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.
Q: What breaks when VPN secrets are exposed through identity permissions?
A: The separation between identity governance and network access breaks down.
Practitioner guidance
- 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.
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
👉 Read Token Security's analysis of Azure role over-privilege and VPN key leakage →
Azure RBAC over-privilege and VPN key leakage: what changes?
Explore further
06/07/2026 9:54 am
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: Azure role misconfiguration exposes identity and network access
