Azure Entra ID Attack Surface: Misconfigurations That Enable Identity-Based Intrusion

Identity has replaced the network perimeter as the primary attack surface in cloud environments, and Azure Entra ID is the most widely targeted identity plane in enterprise cloud. The misconfigurations that matter most in 2026 are not exotic — they are the same gaps that have appeared in cloud breach analyses for three years. They persist because fixing them requires navigating complex Conditional Access policy logic, touching service principals that teams are afraid to modify, and making changes that could break legitimate workflows.

Here is what attackers consistently exploit and what remediation looks like in practice.

Misconfiguration 1: Over-Permissioned Service Principals

An Entra application registration becomes a significant risk when it holds permissions that grant broad directory access — particularly Directory.ReadWrite.All, User.ReadWrite.All, and RoleManagement.ReadWrite.Directory. Applications with these permissions effectively have global admin capability over the directory without appearing in the privileged account inventory.

Attackers who compromise a service principal through a leaked client secret, a misconfigured CI/CD pipeline variable, or a compromised developer machine inherit all of those permissions — without triggering the alerts that a compromised user account would.

Identify over-permissioned service principals with the Microsoft Graph API:

# List service principals with high-privilege application permissions
az ad sp list --all --query "[?appRoles[?value=='Directory.ReadWrite.All' || value=='User.ReadWrite.All' || value=='RoleManagement.ReadWrite.Directory']].{Name:displayName, AppId:appId, Id:id}" --output table

Using Microsoft Graph PowerShell:

# Find service principals with Directory.ReadWrite.All
$dangerousPerms = @("Directory.ReadWrite.All", "User.ReadWrite.All", "RoleManagement.ReadWrite.Directory")
Get-MgServicePrincipal -All | ForEach-Object {
    $sp = $_
    Get-MgServicePrincipalAppRoleAssignment -ServicePrincipalId $sp.Id |
    Where-Object { $_.PrincipalType -eq "ServicePrincipal" } |
    ForEach-Object {
        $role = Get-MgServicePrincipalAppRole -ServicePrincipalId $_.ResourceId |
                Where-Object { $_.Id -eq $_.AppRoleId }
        if ($dangerousPerms -contains $role.Value) {
            [PSCustomObject]@{
                ServicePrincipal = $sp.DisplayName
                Permission = $role.Value
                GrantedTo = $_.PrincipalId
            }
        }
    }
}

Remediation: Apply least privilege to all service principals. Replace Directory.ReadWrite.All with targeted permissions (User.Read.All, Group.Read.All) wherever possible. For service principals that legitimately require broad directory access, rotate client secrets on a 90-day cycle and alert on any authentication using credentials older than that threshold.

Misconfiguration 2: Conditional Access Policy Gaps

Conditional Access is only effective if it covers your entire authentication surface. The most common gaps:

Legacy authentication not blocked. Modern authentication is protected by MFA and Conditional Access. Legacy protocols (SMTP AUTH, IMAP, POP3, Exchange ActiveSync with basic auth) bypass both. Attackers perform password spray attacks against legacy auth endpoints specifically because they are excluded from MFA requirements.

# Identify users who have authenticated via legacy protocols in the last 30 days
az monitor activity-log list \
  --query "[?properties.authenticationProtocol=='BasicAuthentication'].{User:identity.userPrincipalName, Protocol:properties.authenticationProtocol, Date:eventTimestamp}" \
  --output table

Break-glass account exclusions too broad. Every tenant has break-glass accounts excluded from MFA for emergency access. When those exclusions are applied to entire Conditional Access policies rather than targeted exclusion groups, attackers who compromise a break-glass account bypass all protection.

Policies scoped to specific apps. A Conditional Access policy that only applies to “Office 365” or “Azure Management” leaves gaps for other registered applications. Any application that can request an access token needs to be included in your CA policy scope.

Remediation checklist:

# Check for policies that do NOT include legacy auth blocking
Get-MgIdentityConditionalAccessPolicy -All | Where-Object {
    $_.Conditions.ClientAppTypes -notcontains "ExchangeActiveSync" -or
    $_.Conditions.ClientAppTypes -notcontains "other"
} | Select-Object DisplayName, State

Create a Conditional Access policy that blocks legacy authentication for all users and all cloud applications, with only a tightly scoped break-glass group excluded.

Misconfiguration 3: Absent or Misconfigured PIM

Privileged Identity Management (PIM) is designed to eliminate standing privileged access by requiring just-in-time elevation. When PIM is not enabled for Global Administrator, Exchange Administrator, and SharePoint Administrator roles, those roles have permanent assignment — meaning every session a privileged user opens carries elevated access, and any session compromise is a privileged session compromise.

# List users with permanent (non-PIM) Global Admin assignment
az role assignment list \
  --role "Global Administrator" \
  --query "[?!(principalType=='ServicePrincipal')].{User:principalName, AssignedDirect:true}" \
  --output table

Remediation: Convert permanent role assignments to PIM eligible assignments for all privileged roles. Require MFA and a justification for all PIM activations. Set maximum activation durations of 4-8 hours depending on role sensitivity. Alert on PIM activations outside of business hours.

Misconfiguration 4: Unreviewed Consent Grant Permissions

OAuth consent grant attacks occur when a malicious application requests permissions from an Entra tenant and a user with the ability to grant those permissions approves. The attacker’s application then has persistent access to the user’s data — often including email, calendar, and files — without requiring the user’s credentials.

In many tenants, user consent is enabled for all apps, meaning any user can grant a third-party application access to their account without administrator review.

# List OAuth permission grants with broad scopes
Get-MgOauth2PermissionGrant -All | Where-Object {
    $_.Scope -match "Mail.Read|Files.ReadWrite.All|Directory.AccessAsUser.All"
} | Select-Object ClientId, ConsentType, Scope, PrincipalId | Export-Csv -Path "consent-review.csv"

Remediation: Set user consent to “Do not allow user consent” and require administrator approval for all OAuth application authorisations. Review existing consent grants quarterly and revoke any that are from unrecognised publishers or request excessive permissions.

Misconfiguration 5: Tokens with No Binding or Short-Lived Revocation

Access tokens issued by Entra ID are valid for the token lifetime even if the user’s session is terminated or their account is disabled — unless token revocation is propagated correctly. Continuous Access Evaluation (CAE) addresses this by pushing real-time token revocation to supporting applications, but it is not enabled by default for all application types.

Token theft attacks, particularly those using adversary-in-the-middle phishing kits (AiTM), acquire valid session tokens that can authenticate without triggering MFA again because MFA was already satisfied during the original session.

Remediation:

# Verify CAE is enabled for your tenant
az rest \
  --method GET \
  --uri "https://graph.microsoft.com/v1.0/policies/authenticationFlowsPolicy" \
  --query "continuousAccessEvaluation"

Implement token binding where supported, reduce access token lifetime for sensitive applications (minimum 15 minutes, maximum 1 hour for high-value apps), and enable sign-in risk policies that revoke tokens on detected anomalies.

Priority Audit Sequence

If you are doing a targeted Entra ID security review, run in this sequence:

1. Service principal inventory — identify all applications with tenant-level permissions
2. Legacy auth report — determine whether any users are still authenticating via legacy protocols
3. CA policy coverage audit — map which user groups and applications are excluded from which policies
4. PIM adoption — identify all permanently-assigned privileged roles
5. Consent grant review — export and manually review all OAuth grants with broad scopes

References

• Microsoft Entra ID Security Hardening 2026
• Common Entra ID Misconfigurations Attackers Exploit
• Entra ID Exploitation: Privilege Escalation and Persistence
• NVISO — Securing Microsoft Entra ID: Lessons from the Field