Entra ID penetration testing scopes the identity plane of your Microsoft cloud: the tenant, its directory, the apps and service principals registered inside it, Conditional Access, and the role-assignment paths that quietly reach Global Administrator. That is a different engagement from pointing a scanner at a handful of Azure virtual machines. Identity is the control plane of the modern Microsoft estate, so identity is where a serious test spends most of its time.
This guide is written for the person scoping the work: the security lead, cloud owner, or buyer who has to turn "test our Azure environment" into a statement of work that testers can execute and auditors can trust. You will get a direct answer to what belongs in scope, a two-plane asset inventory to hand your testers, an identity attack-path checklist, and the rules of engagement that keep the whole exercise inside Microsoft's guidelines.
TL;DR
What it is: Entra ID penetration testing assesses the identity plane of your Microsoft cloud, the tenant, directory, apps, service principals, Conditional Access, and RBAC-to-Global-Admin paths. It is not the same as generic Azure infrastructure testing.
Two inventories: Scope the Entra directory (identity plane) and the Azure subscriptions (resource plane) together, because the attack paths cross between them.
Prove the hops: A credible test walks from a low-privilege foothold to tenant-wide control and proves each step, not just the endpoints.
Stay in bounds: All testing stays inside your own tenant and Microsoft's unified security testing rules of engagement. Denial-of-service, other tenants, and Microsoft's shared platform are off-limits.
Why identity: Real campaigns and disclosed bypasses keep landing on Entra, which is exactly why identity controls need to be tested rather than assumed.
What should be in scope for an Azure or Entra ID penetration test?
The scope of an Azure or Entra ID penetration test is your tenant and everything you own inside it: the Entra directory (users, guests, roles, and Privileged Identity Management), your app registrations and service principals, Conditional Access and MFA policies, your Azure subscriptions and their RBAC assignments, managed identities, storage accounts, key vaults, and the compute and network resources you deploy. The goal is to find the paths that let a low-privilege identity escalate to Global Administrator or subscription Owner, and to confirm that Conditional Access actually enforces what your policy documents claim.
What is not in scope is Microsoft's own platform. You test the identity and resources you control, not the shared infrastructure underneath them, and you do not run denial-of-service traffic or touch tenants you do not own. That boundary is set by Microsoft's rules of engagement, covered further down.
Two practical scoping decisions shape the engagement. First, decide whether the test is unauthenticated (assume-nothing, starting from the outside), assumed-breach (start with a low-privilege account or a leaked token to model a realistic foothold), or both. Assumed-breach almost always yields more, because the interesting identity paths live behind a first login. Second, decide how deep the resource plane goes: a directory-focused engagement can stop at Entra roles and app permissions, while a full cloud test follows the paths down into subscriptions, managed identities, and data stores.
Entra ID penetration testing is not generic Azure penetration testing
"Azure penetration testing" is the head term buyers reach for, but it hides two very different jobs. One is infrastructure testing: patch levels, exposed services, network segmentation, and misconfigured storage. The other is identity testing: who can become an administrator, which app has more permission than it needs, and whether Conditional Access has a gap. The second job is where cloud breaches actually happen, and it is the one most scanners cannot do, because escalation in Entra is a chain of legitimate-looking permissions rather than a single exploitable bug.
Scoping an engagement as "Entra ID penetration testing" keeps the focus where the risk is. It also sets the right expectation for the deliverable: not a list of missing patches, but a set of proven attack paths that show how an attacker moves from a foothold to control of the tenant, plus the specific role assignments, app consents, or policy gaps that make each path possible.
The Azure and Entra ID asset inventory to hand your testers
Good scoping starts with a good inventory. Microsoft's cloud has two planes, and a complete test covers both. The identity plane is the Entra directory: the people, machines, and applications that can authenticate. The resource plane is the Azure subscriptions: the things those identities can act on. The attack paths that matter usually cross between the two, so scope them together.
Hand your testers a written inventory that covers, at minimum:
Plane | Assets to inventory | Why it matters |
|---|---|---|
Identity (Entra directory) | Users, guests, and admin accounts; Entra roles and PIM eligibility; app registrations and service principals; Conditional Access and MFA policies; enterprise apps, consent grants, and OAuth permissions | These define who can authenticate and how far a given identity can reach, including the paths to Global Administrator |
Resource (Azure subscriptions) | Subscriptions and management groups; Azure RBAC role assignments; managed identities (system and user assigned); storage accounts and key vaults; compute, networking, and PaaS resources | These are what a compromised identity acts on, and where RBAC can quietly grant control back into the directory |
Two inventory items are worth extra attention when scoping. Service principals and managed identities are non-human identities, and they are often over-permissioned and rarely reviewed, which makes them a favourite escalation route. If your environment leans on app registrations and automation, make sure they are explicitly in scope. Non-human identity exposure is a large enough topic that it deserves its own treatment; our write-up on non-human identity attacks and leaked API keys covers why these credentials leak and how attackers use them.
The identity attack-path checklist
An Entra ID penetration test is judged on the attack paths it proves. The point is not to list every setting, but to demonstrate how a realistic attacker moves through the tenant. A useful engagement walks the full chain and evidences each hop, so you can see exactly where a control would have stopped the attack.
Scope the test to cover these hops:
Establish a foothold. Start from a valid low-privilege credential, a guest invitation, or an assumed-breach token. This models the reality that most tenant compromises begin after a first successful login.
Enumerate the directory. Map users, roles, group memberships, app permissions, and Conditional Access coverage. Attack-path mapping tools such as SpecterOps BloodHound and AzureHound exist precisely because these relationships are too tangled to reason about by eye.
Abuse an over-privileged identity. Look for a service principal, an app consent, an owned application, or a role assignment with more scope than its job requires. This is where escalation usually starts.
Escalate toward Global Administrator. Chain role assignments and follow RBAC-to-directory paths, where an Azure resource role can be leveraged to gain control of an identity that holds a privileged Entra role.
Prove tenant-wide impact. Demonstrate what Global Administrator or subscription Owner actually unlocks: access to data, persistence, and control over the identity fabric itself.
Alongside the escalation chain, scope explicit checks on the controls buyers most want validated: whether Conditional Access enforces MFA and device compliance on every sensitive app or leaves exempted clients and legacy authentication paths, whether guest identities are constrained, and whether the highest-value roles sit behind Privileged Identity Management rather than standing access. This is the identity-focused counterpart to a provider-agnostic cloud IAM penetration test, applied to Azure and Entra native assets.
Rules of engagement: stay inside Microsoft's unified guidelines
Every Azure and Entra test runs against Microsoft-operated infrastructure, so the scope line follows Microsoft's own guidance. Microsoft publishes a unified set of security testing rules of engagement that apply across its cloud, and the scoping rule is simple: you may test the tenant, subscriptions, applications, and resources you own, and you must not touch anyone else's or the shared platform beneath them.
In scope under those rules: test accounts or trial tenants for cross-tenant scenarios, your own Conditional Access policies and monitoring, fuzzing and vulnerability testing of your own Azure virtual machines, and container breakout attempts on services you deployed, with responsible reporting. Out of scope: denial-of-service and DDoS testing, tenants or data you do not own, phishing Microsoft staff, and post-compromise actions against Microsoft's own assets. Writing these boundaries into the statement of work up front keeps the engagement authorized and the findings usable.
Why identity belongs in scope
Two disclosed cases make the case better than any threat model. Proofpoint documented a campaign it tracks as UNK_SneakyStrike that has targeted more than 80,000 Entra ID accounts across roughly 100 tenants since December 2024, using the open-source TeamFiltration tool for user enumeration, password spraying, and abuse of OAuth refresh tokens against Teams, OneDrive, and Outlook. Separately, NetSPI disclosed a Conditional Access bypass through Nested App Authentication that let certain token flows reach Microsoft Graph without Conditional Access evaluation; Microsoft's Security Response Center rated it medium severity and has since deployed a fix.
Neither case is a reason to panic, and the specific bypass is remediated. Both are durable reasons to test rather than assume. Password spraying and token abuse succeed when Conditional Access has gaps and non-human identities are over-permissioned, and policy bypasses are exactly the kind of thing that only surfaces when someone tries. Scoping identity into the test is how you find your version of these gaps before someone else does.
What this means for defenders
Scope identity first, then resources. The paths that turn a single compromised account into a tenant takeover live in Entra roles, app permissions, and RBAC. Make those explicitly in scope rather than defaulting to an infrastructure-only test.
Put non-human identities in the statement of work. Service principals and managed identities are the most common over-privileged assets and the least reviewed. Name them in scope so the test actually reaches them.
Validate Conditional Access as a control, not a document. Ask for evidence that policies enforce MFA and device compliance on every sensitive app, including legacy and exempted clients.
Use the results as identity-control evidence. A documented Entra attack-path test supports the identity and access sections of your SOC 2 and ISO 27001 programs, giving auditors concrete evidence that privileged access paths were tested.
Entra, subscription, and identity attack-path work is senior human pentester work, and it maps naturally onto red teaming and adversary emulation or a scoped identity engagement delivered through PTaaS. Stingrai (founded 2021) is a CREST-accredited penetration testing provider, and our testers hold OSCP, OSCE3, and CRTO among other certifications. For the web applications and APIs that sit in front of your Azure environment, our autonomous agent Snipe hunts the complex authorization, IDOR, and business-logic flaws that generic scanners miss, complementing the human-led identity work; you can see how that fits in our web application penetration testing service.
Frequently Asked Questions
What should be in scope for an Azure or Entra ID penetration test? The scope is your tenant and everything you own inside it: the Entra directory (users, guests, roles, and PIM), app registrations and service principals, Conditional Access and MFA policies, your Azure subscriptions and RBAC assignments, managed identities, storage accounts, key vaults, and your compute and network resources. The objective is to find the paths a low-privilege identity can take to Global Administrator or subscription Owner, and to confirm Conditional Access enforces what your policies claim.
Is Entra ID penetration testing different from Azure penetration testing? Yes. "Azure penetration testing" often means infrastructure testing (patch levels, exposed services, storage misconfigurations), while Entra ID penetration testing targets the identity plane: who can become an administrator, which app is over-permissioned, and whether Conditional Access has gaps. Cloud breaches usually happen through identity, so scoping the engagement as an Entra test keeps the focus where the risk is.
What Azure and Entra ID assets should I inventory before a pentest? Inventory two planes. The identity plane covers users and guests, Entra roles and PIM, app registrations and service principals, Conditional Access and MFA policies, and enterprise app consent grants. The resource plane covers subscriptions and management groups, Azure RBAC assignments, managed identities, storage accounts and key vaults, and compute and network resources. Attack paths cross between the two, so scope them together.
What identity attack paths does an Entra ID pentest look for? It follows the chain from a low-privilege foothold to tenant-wide control: establish a foothold, enumerate the directory, abuse an over-privileged service principal or role assignment, escalate toward Global Administrator through chained roles and RBAC-to-directory paths, and prove the impact of Global Admin or subscription Owner. A credible test evidences each hop, not just the endpoints.
What are the Microsoft rules of engagement for cloud penetration testing? Microsoft publishes unified security testing rules of engagement for its cloud. You may test the tenants, subscriptions, applications, and resources you own, including Conditional Access policies and fuzzing your own virtual machines. You may not run denial-of-service or DDoS testing, access tenants or data you do not own, phish Microsoft staff, or attack Microsoft's shared platform infrastructure.
Can I test Conditional Access and MFA policies? Yes, testing your own Conditional Access and MFA policies is explicitly permitted and is one of the most valuable parts of an Entra engagement. Testers check whether policies enforce MFA and device compliance on every sensitive application, whether legacy authentication or exempted clients create a bypass, and whether guest and external identities are properly constrained.
How does an Entra ID pentest support SOC 2 or ISO 27001? A documented identity attack-path test gives auditors concrete evidence that your privileged access and access-control paths were tested, which supports the identity and access management sections of SOC 2 and ISO 27001. The pentest report becomes evidence your compliance program can hand to its auditors.
How is this different from a cloud IAM penetration test? A cloud IAM penetration test is provider-agnostic and covers concepts like role assumption, cross-account trust, and confused-deputy abuse across clouds. An Entra ID penetration test applies the same attack-path thinking to Azure and Entra native assets specifically: Entra roles, PIM, service principals, managed identities, Azure RBAC, and Conditional Access.
References
Microsoft. Microsoft Security Testing Rules of Engagement. https://www.microsoft.com/en-us/msrc/pentest-rules-of-engagement. Unified guidelines defining permitted and prohibited security testing against Microsoft cloud assets.
Microsoft Learn. Microsoft Entra built-in roles (permissions reference). https://learn.microsoft.com/en-us/entra/identity/role-based-access-control/permissions-reference. Reference for directory roles including Global Administrator and privileged role scopes.
Microsoft Learn. What is Conditional Access? https://learn.microsoft.com/en-us/entra/identity/conditional-access/overview. Overview of Conditional Access policy enforcement in Entra ID.
Microsoft Learn. Application and service principal objects in Microsoft Entra ID. https://learn.microsoft.com/en-us/entra/identity-platform/app-objects-and-service-principals. Explains app registrations and service principals as non-human identities.
Microsoft Learn. Managed identities for Azure resources. https://learn.microsoft.com/en-us/entra/identity/managed-identities-azure-resources/overview. Overview of system and user assigned managed identities.
Microsoft Learn. What is Azure role-based access control (Azure RBAC)? https://learn.microsoft.com/en-us/azure/role-based-access-control/overview. Defines Azure RBAC role assignments on subscriptions and resources.
Microsoft Learn. Securing privileged access for hybrid and cloud deployments in Microsoft Entra ID. https://learn.microsoft.com/en-us/entra/identity/role-based-access-control/security-planning. Guidance on protecting Global Administrator and privileged roles.
SpecterOps. BloodHound and AzureHound: identity attack-path mapping. https://bloodhound.specterops.io/get-started/introduction. Open-source tooling for mapping attack paths across Active Directory and Entra ID.
NetSPI. Bypassing Microsoft Entra Conditional Access Policies via Nested App Authentication. https://www.netspi.com/blog/technical-blog/cloud-pentesting/bypassing-microsoft-entra-conditional-access-policies-via-nested-app-authentication/. Disclosure of a Conditional Access bypass rated medium severity and since fixed by Microsoft.
Proofpoint. Attackers Unleash TeamFiltration: Account Takeover Campaign (UNK_SneakyStrike). https://www.proofpoint.com/us/blog/threat-insight/attackers-unleash-teamfiltration-account-takeover-campaign. Reports 80,000+ targeted Entra ID accounts across roughly 100 tenants since December 2024.
