Syslifters Handbook

English

Deutsch

English

Deutsch

Appearance

Conditional Access ​

Microsoft Entra Conditional Access (CA) is the Zero Trust policy engine that gates access to resources on signals like MFA, device compliance, trusted network, and authentication strength. From an attacker's point of view, any way to reach a token without satisfying a grant control is a bypass, whether it stems from a tenant misconfiguration or from how Microsoft itself wires up first-party apps and resources. This page covers both angles: what to audit during an engagement, and which built-in bypasses still work as of late 2025.

Bypasses split into two buckets: misconfiguration (the tenant admin's mistake) and built-in (Microsoft's design or undocumented behaviour).

Misconfiguration bypasses ​

These are what most engagements actually find. Verify each against the customer's exported CA policies (roadrecon plugin policies -f caps.html -p, see Identity & policy enumeration).

  • User / group exclusions: "Break-glass" accounts excluded from every policy and not behind a phishing-resistant MFA method. Synced or guest accounts in the exclusion list that nobody noticed.
  • App exclusions: Whole app exclusions from "All cloud apps" policies. See Resource exclusion bypass below for the side effect even a single exclusion has.
  • Condition gaps: Missing platforms (e.g. only Windows/macOS targeted, leaving Linux/Other untouched), missing client app types (legacy auth not blocked), or trusted locations that are too generous.
  • Grant control weakness: "Require one of the selected controls" (logical OR) instead of "Require all" (AND). MFA OR compliant device means either is enough, so an attacker who steals a refresh token from a compliant device doesn't need MFA, and an attacker who phishes MFA doesn't need a compliant device.
  • Report-only policies left in report-only mode: intent was clearly to enforce; nobody flipped the toggle.
  • Session controls without sign-in frequency: long-lived sessions defeat the point of "require MFA every X hours" or "require compliant device" if no SIF policy forces re-evaluation.
  • Legacy authentication still reachable: Microsoft disabled basic auth for most Exchange Online protocols (IMAP, POP, EAS, EWS, MAPI, RPC, Remote PowerShell) back in October 2022, but SMTP AUTH retirement was delayed to end of December 2026 and remains on by default until then. Until that cutoff (and afterwards on any mailbox where an admin re-enabled it), SMTP AUTH and app passwords still strip MFA entirely. The Block legacy authentication CA template plus tenant-wide Set-TransportConfig -SmtpClientAuthenticationDisabled $true remain the belt-and-braces controls. Also check for third-party / hybrid LOB apps that surface basic auth through federation.
  • Device code flow not blocked or scoped: phishable on any user who isn't trained for it. See the device code flow notes on the Attack-path data collection page.

Built-in / by-design bypasses ​

The following are baked into how Entra handles certain first-party apps and resources. They apply even when CA is perfectly configured.

Resource exclusion bypass ​

If a CA policy excludes any resource from a "All cloud apps" rule, the following scope combinations stop being covered by that policy, for every resource, not just the excluded one:

  • Azure AD Graph: email, offline_access, openid, profile, User.Read
  • Microsoft Graph: email, offline_access, openid, profile, User.Read, People.Read

So a policy that excludes one obscure app for compatibility silently weakens directory-data protection across the tenant. Microsoft documents this; most admins miss it.

Audit angle: flag any "All cloud apps" policy with non-empty exclusions, then check if a second additive policy specifically protects the Microsoft Graph / Azure AD Graph scopes above.

Device registration bypass ​

The resource Device Registration Service (01cb2876-7ebd-4aa4-9cc9-d28bd4d359a9) can only be gated by Require MFA. Trusted location, compliant device, and compliant network grants do not apply (confirmed by MSRC as VULN-153600, working as intended).

Impact: an attacker with valid credentials + MFA can register a rogue device from an untrusted network even if the tenant otherwise blocks all sign-ins from untrusted locations.

Audit angle: confirm Require multifactor authentication for device registration is enabled (Microsoft guidance), and don't rely on location/compliance for device registration.

Global Secure Access (GSA) bypass ​

When a CA policy uses the Compliant Network grant, all GSA bootstrap resources are automatically excluded so the user can actually connect to the GSA tunnel that proves they're on the compliant network. Required, but means the GSA client resources themselves cannot be protected via this grant.

Device Management Service bypass ​

The resource Device Management Service (cb58b23f-9a26-4ef4-9e9e-ca08567ef56c) is reachable through the Microsoft Teams client id (1fec8e78-bce4-4aaf-ab1b-5451cc387264) without a compliant-device grant being enforced. The token includes DeviceManagement.Read and user_impersonation. MSRC closed this as by-design; no public abuse path is known as of late 2025, but the CA bypass itself is real (the sign-in log shows the policy result as failure while ConditionalAccessStatus is success).

Resources permanently outside CA ​

For a handful of first-party resources, CA enforcement is hard-coded to notApplied. There is no policy that will gate token issuance for them:

Resource idResource name
26a4ae64-5862-427f-a9b0-044e62572a4fMicrosoft Intune Checkin
04436913-cf0d-4d2a-9cc6-2ffe7f1d3d1cWindows Notification Service
0a5f63c0-b750-4f38-a71c-4fc0d58b89e2Microsoft Mobile Application Management
1f5530b3-261a-47a9-b357-ded261e17918Azure Multi-Factor Auth Connector
c2ada927-a9e2-4564-aae2-70775a2fa0afOCaaS Client Interaction Service
ff9ebd75-fe62-434a-a6ce-b3f0a8592eafAuthenticator App

Practical attacker use case: any client app that has pre-consented scopes on one of these resources can be used to verify a password without triggering MFA. The sign-in does not produce 50074 - Strong Authentication is required, which makes it a quieter password spray / validation primitive than the usual endpoints. Per-user MFA (the legacy, non-CA mechanism) does still enforce on these resources, one of the rare cases where the older feature is stricter.

Look up which apps have pre-consented scopes on a given resource at entrascopes.com.

Audit checklist ​

Run through these on every Entra engagement (links into the wider tooling docs in this section):

  • Export CA policies with ROADtools and review them as code, not in the portal UI.
  • Verify every "All cloud apps" rule for exclusions; if any exist, confirm an additive policy protects the Graph / AAD Graph scopes listed above.
  • Confirm a baseline Require MFA for all users policy exists (Microsoft template).
  • Confirm a dedicated policy enforces MFA for device registration.
  • Confirm SMTP AUTH is disabled tenant-wide (Set-TransportConfig -SmtpClientAuthenticationDisabled $true) and the Block legacy authentication CA template is active. Other Exchange basic-auth protocols were retired in 2022, but SMTP AUTH stays on by default until end of December 2026 (Microsoft timeline).
  • Confirm grants combine with AND, not OR, for MFA + compliant device / trusted network combinations.
  • Check break-glass account count, exclusion scope, MFA method, and password vaulting.
  • Check whether device code flow is blocked or scoped to specific user groups.
  • Run Maester for an automated baseline against well-known CA best practices.
  • Cross-reference the customer's first-party app inventory with entrascopes.com to spot apps with pre-consented scopes on the always-excluded resources above.

References ​