Cirro shows why Azure attack paths are a graph problem

At a glance

What this is: NHI Mgmt Group's analysis, drawing on Bishop Fox's blog post: Azure attack paths become visible only when identity, RBAC, scope, and data-plane context are modeled together.

Why it matters: IAM and cloud security teams need graph-level visibility because isolated permissions can look safe while the connected path still leads to secrets, resources, or downstream abuse.

Context

Cloud attack paths are not usually created by a single bad permission. They emerge when identities, role assignments, scopes, managed identities, secrets, and application permissions line up across Azure resources.

That means a conventional review of users, groups, and resource permissions can miss the real exposure. The governance problem is the relationship between objects, not the objects themselves.

For IAM and cloud security teams, the practical challenge is that attack path analysis must account for both management-plane reachability and data-plane artifacts if it is to reflect how access is actually abused.

Key questions

Q: Why do Azure permissions look safe until they are modelled as a path?

A: Because individual permissions often appear low risk until they are linked through group membership, scope, managed identities, and downstream secrets. Attackers care about the reachable chain, not the isolated object. A path-aware model shows where legitimate access becomes a route to a sensitive resource or credential. Security teams should therefore review connected exposure, not only standalone entitlements.

Q: When does RBAC become insufficient for cloud access review?

A: RBAC becomes insufficient when the review stops at role assignments and ignores what those roles can reach next. In Azure, scope, resource relationships, managed identities, and data-plane permissions can extend access far beyond the original assignment. If the analysis cannot trace that chain, it will miss the real blast radius. Teams need reachability analysis, not just role validation.

Q: What breaks when secrets and certificates are excluded from attack path analysis?

A: What breaks is the link between administrative access and downstream abuse. A resource may look well controlled at the management plane while still exposing secrets or certificates that let an identity move laterally or authenticate elsewhere. Excluding those artefacts makes the graph blind to how control of one resource can become control of another. That is a governance blind spot, not a data-quality issue.

Q: How should teams tell whether environment separation is actually working?

A: They should look for shared identities, shared secrets, or shared application credentials across dev, QA, staging, and prod. If the same credential material works in multiple environments, separation exists on paper but not in practice. The test is whether one environment can be compromised without exposing another. That is the sign that identity boundaries are real.

Technical breakdown

Why Azure attack paths become graph problems

An attack path is a chain of individually plausible relationships that becomes risky only when viewed end to end. In Azure, a user may inherit RBAC through group membership, reach a scope such as a resource group, touch a virtual machine, inherit a managed identity, and then obtain access to a Key Vault or application secret. Each step can look legitimate in isolation. The graph model matters because it preserves those relationships as first-class objects, which is what lets analysts ask not just who has access, but what that access can reach next.

Practical implication: model identity, scope, and downstream reachability together rather than reviewing permissions as isolated entitlements.

Why data-plane context changes the risk picture

Management-plane visibility shows who can administer a resource, but it does not always show what that resource exposes once it is running. Data-plane context adds secrets, certificates, and the identities tied to them, which can reveal how administrative access turns into credential exposure or application abuse. Cirro's example of Key Vaults linked to Entra ID applications shows why environment boundaries matter. If development, QA, staging, and production all rely on the same underlying identity material, the graph is exposing a governance issue that simple resource inventory would miss.

Practical implication: include secrets and workload credentials in attack path analysis, not just administrative access paths.

How schema-driven ingestion supports scale in Azure

Cirro's schema engine uses reusable templates, YAML definitions, and shared constants to map source data into graph nodes and relationships without hard-coding every Azure resource type into the binary. That matters because cloud environments evolve faster than bespoke parsers do. Conditional logic in the schema can handle incomplete API responses, legacy access policies, and Azure RBAC variants while preserving graph consistency. Generic ingestion for unmapped resources still keeps scope and reachability intact, which is enough to keep attack path reasoning alive until deeper schemas are added.

Practical implication: build graph ingestion so new Azure resource types can be added without rewriting the whole collection pipeline.

Threat narrative

Attacker objective: The attacker aims to turn scattered but legitimate Azure permissions into a complete path that reaches sensitive secrets, identities, or application control.

1. Entry begins with a legitimate identity relationship such as group membership or inherited role assignment that opens a path into Azure resources.
2. Escalation occurs when that access crosses a resource boundary into a managed identity, secret, or data-plane permission that can be reused downstream.
3. Impact follows when the full chain reaches a sensitive resource such as Key Vault or a production application, enabling unauthorized control or secret exposure.

Breaches seen in the wild

• Massive Docker Hub Secrets Leak: 10,000+ Docker Hub container images expose hardcoded secrets and authentication keys.
• Millions of Misconfigured Git Servers Leaking Secrets: Nearly 5 million misconfigured Git servers expose sensitive secrets and credentials online.

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 attack paths are a relationship problem, not an object problem: A permission, identity, or scope can look harmless in isolation and still form a dangerous route when combined with other access edges. That is why graph modelling is more accurate than object-by-object review for cloud governance. The practitioner takeaway is that entitlement reviews need path awareness, not only inventory awareness.

Data-plane context is now part of identity governance: Once secrets, certificates, and workload identities enter the graph, cloud access review is no longer limited to management-plane administration. This is where many programmes still under-model exposure, especially when the same identity material is reused across environments. The practitioner takeaway is that governance has to follow what access can unlock, not just what it can configure.

Environment boundary collapse is the real risk signal: When development, QA, staging, and production all depend on the same underlying identity artefact, the environment label stops being a security boundary. The issue is not merely reuse, but the loss of separation that lets one compromise travel across environments. The practitioner takeaway is that environment-specific identity design should be treated as a control objective, not a naming convention.

Template-driven graph ingestion is the only sustainable way to scale attack path analysis: Azure changes too quickly for hard-coded parsers to stay complete. A schema engine that normalises source data into shared nodes and relationships is what makes continuous path analysis possible across new services and incomplete APIs. The practitioner takeaway is to invest in ingestion patterns that preserve graph fidelity as the cloud estate expands.

Identity blast radius is the concept practitioners should use here: The useful question is not whether a permission exists, but how far a single identity can travel once relationships are connected. That is the real blast-radius measure in Azure, especially when resource scope, managed identities, and secrets converge. The practitioner takeaway is to assess reachability as the primary risk metric.

What this signals

Attack path management in Azure is moving from entitlement counting to relationship analysis, and that should change how cloud teams frame their control objectives. The point is not to catalogue every resource, but to understand which identities can traverse into secrets, certificates, and downstream application control.

Environment segregation deserves to be treated as an identity design issue, not only a deployment concern. When the same client secret or application identity spans multiple stages, the attack path crosses trust boundaries that most access reviews never model.

Graph fidelity matters because incomplete ingestion creates a false sense of safety. If your tooling cannot preserve scope, reachability, and data-plane context as Azure expands, your governance model will lag the estate it is meant to describe.

For practitioners

• Map identity-to-resource attack paths Trace group membership, RBAC scope, managed identities, secrets, and downstream application permissions as one connected route, not as separate access findings.
• Include data-plane artefacts in reviews Extend cloud access review to Key Vault secrets, certificates, and credential-bearing application objects so downstream abuse is visible alongside administrative access.
• Separate identities by environment Treat development, QA, staging, and production as distinct identity zones and investigate any shared client secret or application identity across them.
• Preserve graph fidelity across new resources Use schema-driven ingestion and generic fallback nodes so new Azure resource types still contribute scope, reachability, and relationship context.

Key takeaways

• Azure exposure is best understood as connected reachability, not as a list of isolated permissions.
• Including data-plane artefacts such as secrets and certificates reveals routes that management-plane reviews miss.
• Identity separation across environments is only meaningful when the underlying credentials are also separated.

Key terms

• Attack path: A sequence of identities, permissions, systems, and data stores that an attacker can traverse after obtaining trusted access. In practice, attack paths matter more than single accounts because they show how a low-risk identity can become a route to high-value exposure.
• Data-Plane Context: The runtime objects and credentials that determine what a resource can actually access or expose after deployment. In Azure, this includes secrets, certificates, and application-linked identities, which often reveal risk that management-plane administration alone cannot show.
• 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.
• Environment Isolation: Environment isolation is the practice of keeping development, test, and production access separated so compromise in one zone does not automatically reach another. For machine identities, weak isolation usually means the same credential or trust relationship can cross boundaries and enlarge the blast radius.

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.