Microsoft Entra ID penetration testing guide

Microsoft Entra ID penetration testing evaluates whether a compromised user, limited administrator, application or workload identity can obtain more access than the tenant owner intended. Scope includes authentication, Conditional Access, directory roles, Azure RBAC, enterprise applications, consent, Microsoft Graph, service principals, secrets and certificates, PIM, B2B guests, hybrid synchronisation, logging and response.

The answer-first point is that Entra ID is not a single web portal. It is a graph of identities, credentials, OAuth grants, administrative scopes and trust between cloud and Active Directory. An effective assessment combines configuration with controlled negative scenarios and does not attack Microsoft infrastructure, other tenants or third-party accounts.

A strong report distinguishes the ability to obtain a token from effective rights to a resource. It also separates Microsoft Entra roles, Azure Resource Manager roles and Microsoft Graph permissions. Similar labels can belong to entirely different control planes.

Define scope and follow Microsoft rules first

A tenant owner can authorise testing of its configuration, applications and resources but cannot authorise attacks against shared provider infrastructure. Rules of engagement list tenant ID, subscriptions, applications, test accounts, approved sources, window, API limits, prohibited actions and emergency contact. Capture the current Microsoft Cloud Penetration Testing Rules of Engagement.

Do not perform denial of service, broad password spraying, phishing of Microsoft employees, attempts to access other tenants or destructive changes. Authentication, consent and role scenarios use controlled users and applications. If a read operation exposes another organisation’s data, stop and follow the incident route.

The governance is related to our AWS, Azure and GCP penetration testing guide, but Entra needs its own model: one identity can affect Microsoft 365, Azure, SaaS applications and synchronised AD.

Technical model: tenant, application and service principal

An application object represents the global definition of an app registration in its home tenant. A service principal is the application’s local instance in a particular tenant, where grants, assignments and selected properties live. A multitenant application object can have service principals in many customer tenants following consent or provisioning.

Distinguish:

delegated permissions — the app operates with a signed-in user, commonly within the intersection of user rights and granted scopes;
application permissions — the app acts as a workload without a user and can have organisation-wide access;
Microsoft Entra roles — manage directory objects and functions;
Azure RBAC roles — authorise ARM operations at management group, subscription, resource group or resource scope;
app roles and groups — may drive authorisation within a specific application;
ownership — an application or service-principal owner may have administrative capabilities that require evaluation independently of role labels.

High-impact paths often arise from control of an app credential, the right to add credentials, broad Graph application permission or role-assignment capability. A list of Global Administrators does not represent the complete blast radius.

OAuth and OpenID Connect tokens

For Entra-integrated applications, test signature, issuer, audience, lifetime, nonce/state/PKCE, redirect URIs and correct use of access versus ID tokens. An API must not accept an ID token as a bearer credential for data. A multitenant app must validate permitted issuers and map the Entra tenant to an onboarded customer rather than accept every correctly signed Entra token.

A token is not a universal Microsoft API credential. Audience identifies the resource. The roles claim commonly carries application roles, scp carries delegated scopes, and group claims can use an overage mechanism requiring another lookup. Authorisation code must not interpret a missing group list as no group membership; it must implement the documented pattern.

Test logout, role removal, session revocation, refresh tokens and Continuous Access Evaluation for supported resources. “The user has been disabled” does not guarantee that every issued token is rejected immediately by every application. Clients need to process claims challenges and resource denials correctly.

Our OAuth 2.0 security guide based on RFC 9700 covers the protocol model in depth. Penetration testing uses tester-owned sessions rather than stealing real user tokens.

Consent phishing uses a legitimate approval experience to authorise an application. Defence begins before phishing: user-consent policy determines which applications and scopes a user may approve. Microsoft generally recommends allowing end-user consent only for verified-publisher apps and selected low-impact permissions, backed by an admin-consent workflow.

Review:

user/admin consent policy and reviewers;
enterprise applications, publisher verification and first-consent date;
delegated permission grants and app role assignments;
Microsoft Graph and other API application permissions;
owners, certificates, secrets, federated credentials and reply URLs;
inactive apps, unused grants and orphaned service principals.

Rate a permission by allowed operations, not its friendly name. Organisation-wide file or mailbox access by an unattended application has a different impact from one user’s delegated access. Microsoft recommends least privilege, periodic review and removal of unused or reducible permissions. A useful report identifies the minimum documented alternative where one exists.

For controlled validation, create a test app or use the client’s sandbox application. Do not ask an administrator to grant a critical permission in production solely for a demonstration. When configuration proves that an owner can add a credential to an existing privileged service principal, demonstrate only in a dedicated app and document the effective right.

Workload identities, secrets and federation

A workload identity represents an application, script, container or service. Unlike a person, it cannot complete MFA, often owns multiple credentials and may lack a lifecycle owner. Service principals and managed identities deserve the same scrutiny as human accounts.

Prefer managed identity or workload identity federation where they can replace static secrets. Federation trusts tokens from an external identity provider, such as a CI system, based on issuer, subject and audience. An overly broad subject pattern or control of the source repository/pipeline can widen who obtains an Entra token. Review the federated credential and permissions in the source system.

For remaining secrets, check storage, expiry, rotation, exposure in code or CI, owner and actual use. An application certificate is generally preferable to a shared secret, but a stolen private key is still a credential. Use HSM or Key Vault according to risk and prevent export where unnecessary.

Conditional Access for workload identities has coverage and licensing distinct from user policy. Microsoft documents that policies must target a service principal directly; assigning a policy to a group containing the service principal does not enforce it. Managed identities and some multitenant applications also have different coverage. Never state “all apps are protected by CA” without validating those exceptions.

Directory roles, Azure RBAC and escalation paths

Inventory active, eligible and group-based role assignments. For each, inspect scope, duration, source, ability to manage credentials, role-assignable groups, apps and other roles. Apparently support-oriented roles may reset authentication methods for defined populations; administrative restrictions and protected actions need current documentation review.

Analyse Azure RBAC separately. Subscription Owner or User Access Administrator can delegate Azure-resource access but is not the same as Global Administrator. A Global Administrator can use a documented elevation process to gain management access to subscriptions; monitor that event. Cross-plane paths matter more than individual role labels.

PIM reduces standing access through eligible assignments, short activation, approval, MFA, justification and alerts. It does not automatically fix an excessive scope. If every administrator can activate Global Administrator without approval for many hours, exposure remains high. Recurring access reviews should remove obsolete roles, guests and application owners.

Our privileged access management guide develops the operating model.

Conditional Access: test decisions, not policy count

Conditional Access evaluates user or workload identity, resource, device, location, risk and authentication method. More policies do not guarantee coverage. Look for scope gaps, exclusions, report-only state, uncovered sign-in types, trusted locations and conflicting grant controls.

The test matrix should include:

a normal user and an administrator;
guest, synchronised and cloud-only identities;
compliant, registered and unmanaged devices;
interactive, legacy and selected noninteractive sign-ins;
critical applications and resources outside Microsoft 365;
service principals where workload-identity CA applies;
user/sign-in risk, Authentication Strength and phishing-resistant MFA.

Evaluate new policies with What If, report-only mode and a pilot group. Emergency exclusions are necessary but should contain at least two monitored cloud-only emergency accounts. Do not use them during routine testing without explicit approval; validate alerts and procedure with a controlled exercise.

“MFA enabled” is not enough. Method and phishing resistance matter. SMS or context-free push has a different profile from FIDO2/passkeys or certificate-based authentication. Our MFA rollout guide explains migration.

Emergency access without false assurance

Microsoft recommends at least two cloud-only emergency accounts permanently assigned Global Administrator and reserved for recovery. Their authentication should be independent of normal infrastructure, credentials protected and every use alerted.

Assess existence, independence from federation, CA exclusions, monitoring, dual-control access and exercises. Do not expose secrets or force a real lockout. A tabletop can show whether the team can retrieve the credential, reach decision-makers and restore access within its target.

A break-glass identity is a recovery control, not a convenient automation exception. Routine use should trigger incident or process-defect handling.

B2B guests, cross-tenant access and multitenant apps

A guest retains a relationship with its external home tenant. Cross-tenant access policy determines whether your tenant trusts a partner’s MFA and device claims and which inbound or outbound collaboration is allowed. Defaults, organisation-specific exceptions and direct connect need owners.

Review invitations, sponsors, expiry, access reviews, dynamic groups and guest-accessible apps. Project closure should remove roles, group membership, entitlement packages and sessions. A guest in a role-assignable group or an application owner may have impact missed by a simple “Guest users” report.

For a multitenant application, a valid token from another organisation must not automatically create a local customer context. Require explicit onboarding, issuer/tenant validation and assigned rights. Our SaaS tenant isolation penetration testing guide covers that boundary.

Hybrid identity paths from AD to cloud

Microsoft recommends avoiding synchronised accounts for cloud administrative roles where cloud-native admin identities can be used. Otherwise, on-premises compromise can cross into Entra. Review Password Hash Sync, Pass-through Authentication or federation, Microsoft Entra Connect/Cloud Sync servers, connector identities, writeback rights and staging mode.

Treat synchronisation servers as critical assets. Assess local administrators, service identities, database, patching, EDR, backups, network paths and monitoring. In AD, review control of synchronised objects and attributes influencing cloud identity. The domain side belongs in a technical Active Directory security assessment.

Do not make destructive synchronisation changes. Safe validation uses a dedicated OU and test user, observes the intended flow and confirms that a prohibited attribute or role is not propagated.

Safe Entra ID penetration testing methodology

1. Discovery through an approved identity

Collect tenant properties, domains, role assignments, CA, named locations, authentication methods, applications, service principals, grants, credential metadata, guests, devices, PIM, access reviews, logs and hybrid identity settings. Do not retrieve mailbox or file content unless separately needed for an authorised proof.

2. Permission graph and scenarios

Connect principal → credential/control → role/grant → resource → business impact. Mark whether an edge is active, eligible, subject to consent or approval, device-bound or dependent on AD. Confirm every critical step against the API documentation and tenant state.

3. Controlled validation

Use dedicated users, apps, groups and resources. Test denied access, PIM activation, report-only CA, consent revocation, credential rotation and alerting. Do not grant a test application broad production Graph application permissions solely to demonstrate impact.

4. Cleanup and reversibility proof

Remove test grants, roles, credentials, applications and sessions; verify audit events. Retesting confirms token or access denial and legitimate-flow continuity.

Microsoft Entra logging and detection

At minimum, retain and export Sign-in, Audit and Provisioning logs plus PIM/Identity Protection data to an isolated workspace or SIEM for the required period. Analyse interactive user, noninteractive user, service principal and managed identity sign-ins separately. A user-sign-in dashboard does not represent workloads.

High-value detections include:

a new credential on a privileged application or service principal;
admin consent or a high-impact application permission;
a new app owner, role assignment or role-assignable group member;
Conditional Access, trusted location, authentication-method or federation changes;
high-role PIM activation from an unusual device or location;
emergency-account use;
workload sign-in from a new ASN/IP followed by Microsoft Graph access;
disabling log export or reducing retention.

Identity Secure Score can prioritise recommendations, but Microsoft explicitly says the score is not an absolute breach-likelihood measure. Do not optimise a penetration test for a percentage; assess the control, impact and detectability.

Entra ID penetration test checklist

What should the business receive?

The report should contain a control-plane diagram, escalation graph, CA matrix, app-and-grant inventory, business impact, safe proof and remediation plan. Prioritise paths combining durable credentials, application permissions, roles and missing detection rather than isolated deviations from a best-practice list.

Our Microsoft 365 security guide covers Exchange, SharePoint, Defender and data controls. An Entra assessment is the identity core but does not replace application, cloud or endpoint testing.

If you need a controlled evaluation of the tenant, applications and hybrid privilege paths, contact Breachroad. We will deliver technical evidence without targeting Microsoft infrastructure or expanding access outside the approved tenant.