Azure VAPT: Managed Identity Abuse and Subscription Takeover
July 15, 2026
Azure's identity and access model differs from AWS in ways that affect the attack surface a defensive VAPT programme must consider. The tight coupling between Azure Active Directory (now Microsoft Entra ID) and Azure Resource Manager, the managed identity system for workloads, and the subscription-level administrative boundaries all produce distinctive escalation surfaces. This document describes how defensive assessments approach Azure environments and the controls that address the escalation paths that consistently appear.
The Managed Identity Attack Surface
Managed identities are Azure's solution to the credential management problem for workloads. Instead of storing credentials in application configuration, workloads receive an identity managed by Azure that they can use to authenticate to other Azure services. The tokens are obtained via a metadata endpoint similar to AWS IMDS but with different protocol details. Workload compromise typically provides access to the managed identity token, which then provides access to any Azure resource the managed identity has permissions on.
A defensive assessment enumerates every managed identity in the environment — both system-assigned identities tied to specific resources and user-assigned identities that can be attached to multiple resources — and evaluates the permissions each holds. The permission evaluation must consider role assignments at every scope: management group, subscription, resource group, and individual resource. A managed identity with subscription-scoped Contributor role grants effectively complete access to the subscription regardless of what the workload actually needs.
User-assigned managed identities that are attached to multiple resources create shared-fate risk. Compromise of any resource with the identity attached provides access to the identity's token, which then can access any resource the identity has permissions on. Assessments should identify user-assigned identities attached to multiple resources and evaluate whether the sharing is intentional or accidental. Migration to per-resource system-assigned identities is often the appropriate remediation.
Role Assignments and RBAC Analysis
Azure RBAC (Role-Based Access Control) uses role definitions and role assignments to grant permissions. Built-in roles like Owner, Contributor, and User Access Administrator have broad permissions that make them common escalation targets. Custom roles can be defined with specific permission sets but frequently accumulate permissions over time as the roles are updated to support additional use cases. A defensive assessment enumerates all role assignments across the tenant and evaluates whether the effective permissions match the intended access model.
User Access Administrator role is one of the more dangerous role assignments because it permits the holder to grant additional role assignments. A user with User Access Administrator on a subscription can assign themselves or others any role at any scope within the subscription, effectively controlling the subscription's access model. Assessments should identify User Access Administrator assignments and validate that each is intentional; frequently the role is assigned during initial subscription setup and never removed.
Owner role assignments deserve similar scrutiny. Owner combines all Contributor permissions with User Access Administrator permissions, making it the highest-impact role assignment at any scope. Assessments should enumerate Owner assignments across management groups, subscriptions, and resource groups and evaluate whether each is required for legitimate operational needs. Owner assignments to service principals used by CI/CD pipelines are a particular concern because compromise of the pipeline provides broad Azure access.
Azure AD Conditional Access and Authentication
Conditional Access policies control the conditions under which authentication requests are allowed to complete. Well-configured policies enforce multi-factor authentication, block sign-ins from unusual locations, and require compliant devices for sensitive operations. Gaps in Conditional Access policies frequently emerge from exclusions added for specific scenarios — service accounts, emergency access accounts, legacy applications — that are then not reviewed for continued necessity.
A defensive assessment reviews Conditional Access policies and their exclusions. Excluded accounts and applications should be enumerated with the justification for each exclusion; exclusions without documented justification represent unmanaged risk. Emergency access accounts (break-glass accounts) require documented monitoring — if the accounts are excluded from MFA but their use is not alerted on, they represent a persistent unmonitored escalation path.
Legacy authentication protocols (POP3, IMAP, SMTP AUTH, older Exchange Web Services versions) do not support modern authentication and cannot be protected by Conditional Access policies. Environments that still permit legacy authentication have an authentication surface where MFA cannot be enforced. Assessments should identify whether legacy authentication is disabled at the tenant level; if not, the specific applications and accounts still using legacy authentication should be enumerated for planned migration.
Key Vault Configuration and Access Control
Azure Key Vault stores cryptographic keys, secrets, and certificates for Azure applications. Compromise of a Key Vault typically provides access to credentials, encryption keys, or authentication material that the vault stored, which can then extend the compromise to the systems those credentials protect. Assessments should treat Key Vault configuration as a high-priority review area.
Key Vault access can be controlled via access policies (the older mechanism) or Azure RBAC (the newer mechanism). Vaults using access policies should be inventoried and evaluated for over-permissive policies — the "Get" and "List" permissions on secrets combined with broad principal grants are functionally equivalent to sharing the secret contents with those principals. Vaults using Azure RBAC benefit from the more granular permission model but require the same review of role assignments.
Network access to Key Vault should be restricted to specific network segments or specific service endpoints. Vaults accessible from the internet, even with correct authentication, expose their access control to global brute-force and credential-stuffing attempts. Private endpoint deployment restricts network access to specified VNet subnets and eliminates the internet-facing access surface. Assessments should identify vaults without network access restrictions and recommend private endpoint deployment for vaults storing high-value secrets.
Storage Account Security
Azure Storage accounts are the equivalent surface to AWS S3 buckets and exhibit similar failure modes. Storage accounts configured for public access, storage accounts with over-permissive shared access signatures, and storage accounts with account-level keys that have been exposed all appear in assessments. The relevant assessment surface includes storage account network configuration, access control settings, shared access signature (SAS) usage, and account key rotation practices.
Storage account keys provide broad access to all data in the account and cannot be scoped to specific containers or blobs. Applications that access storage using account keys expose themselves to complete storage account compromise if the keys are leaked. Managed identities and SAS tokens with narrow scope are the recommended alternatives. Assessments should identify applications still using account keys and recommend migration to more granular authentication mechanisms.
SAS token generation and validity require careful review. Long-validity SAS tokens function as long-lived credentials with the permissions they grant; if leaked, they provide persistent access until they expire or the underlying account key is rotated. User-delegation SAS (using Entra ID identities) provides better auditability than account-key SAS. Assessments should enumerate applications generating SAS tokens and validate that validity periods are minimized and user-delegation is used where possible.
Defender for Cloud and Detection Coverage
Microsoft Defender for Cloud provides threat protection and security posture management across Azure resources. Its detection coverage extends across Azure infrastructure, hybrid environments, and multi-cloud connections. A defensive assessment reviews Defender for Cloud enablement — which service plans are enabled for which subscriptions — and evaluates whether the detection surface matches the resource footprint.
Defender for Cloud alerts require triage processes to produce security value. Assessments should evaluate the alerting pipeline — are alerts routed to a SIEM, are they triaged within defined timeframes, are false positives suppressed correctly? Defender for Cloud producing alerts that are not triaged is functionally equivalent to Defender for Cloud being disabled from a security outcome perspective. The programmatic integration between Defender alerts and incident response processes is where security value is realised.
Azure Activity Log and Diagnostic Logs provide the forensic evidence that supports incident response. Assessments should validate that Activity Log is being exported to a durable log store (Log Analytics workspace, storage account, or SIEM), that Diagnostic Logs are enabled for security-relevant resources, and that log retention meets the organisation's regulatory and operational requirements. Log configuration gaps identified during assessment represent immediate remediation targets because they affect the organisation's ability to investigate any future incident, not just incidents related to specific VAPT findings.