Conditional Access in Microsoft Entra ID, explained
Conditional Access is the policy engine of Microsoft Entra ID (formerly Azure AD). After the first factor, Entra collects the signals of a sign-in (who, which app, which device, from where, how risky) and checks them against every Conditional Access policy in the tenant. This free Conditional Access policy simulator rebuilds that evaluation in your browser, so you can design and test policies, import the policies of your own tenant and find gaps before you change anything in production.
How Conditional Access evaluates a sign-in
- Every policy counts. There is no order or priority. All enabled policies whose assignments match the sign-in apply.
- Conditions are combined with AND. A policy applies only when the user, the target resource and every configured condition match. A condition that is not configured matches everything.
- Exclusions win. A user who is both included and excluded (directly, through a group or a role) is excluded.
- Block wins. If one applying policy blocks access, the sign-in is blocked, whatever the other policies grant.
- Grant controls add up. The user must satisfy the grant controls of every applying policy. Inside one policy you choose require all the selected controls or require one of the selected controls.
- No policy, no extra check. When nothing applies, the first factor is enough. That is the gap the simulator's red cells show.
Report-only mode
A policy in report-only mode is evaluated at every sign-in and its result is written to the sign-in logs, but it is never enforced. Microsoft's templates suggest starting in report-only mode. In the simulator, report-only policies appear in purple with the result they would have, so you can see the impact before you switch a policy on.
Users, roles, guests and emergency access accounts
Policies target all users, specific users and groups, directory roles such as Global Administrator, or guest and external user types (B2B collaboration guests and members, B2B direct connect users, local guests, service provider users and other external users). Microsoft recommends at least two cloud-only emergency access (break-glass) accounts, excluded from every policy, so a mistake can never lock every administrator out. Mark them in the Directory tab: the Health check then warns about every policy that would still apply to them.
Target resources, user actions and authentication context
A policy targets All resources (formerly All cloud apps), selected apps such as the Office 365 app group (Exchange Online, SharePoint, Teams and related services), the Microsoft Admin Portals group or the Windows Azure Service Management API (Azure portal, Azure PowerShell and CLI). Instead of apps, a policy can target a user action (Register security information or Register or join devices) or an authentication context such as c1, which apps like SharePoint request for sensitive content.
Policies that target All resources but exclude some apps used to be skipped for sign-ins that request only basic OpenID Connect or a few limited directory scopes. From June 2026 Microsoft rolls out enforcement of those policies for such sign-ins as well (message center MC1223829). The Health check marks every policy with resource exclusions so you can check custom apps.
Network, device platforms and client apps
The network condition (shown as Locations in older screenshots) works with named locations: IPv4 or IPv6 ranges that you can mark as trusted, and country lists. Countries can't be marked as trusted. Type an IP address and a country in the What If form and the simulator shows every named location that matches. Device platforms are Android, iOS, Windows, macOS, Linux and Windows Phone; a policy that includes any device and excludes the known platforms catches unknown or spoofed user agents. Client apps are browser, mobile apps and desktop clients, Exchange ActiveSync and other clients. The last two are legacy authentication (POP, IMAP, SMTP AUTH, older Office clients): they can't do MFA, which is why blocking them is one of Microsoft's base policies.
Filter for devices: rule syntax
A device filter includes or excludes devices with a rule like device.trustType -ne "ServerAD" -and device.isCompliant -ne "True". The simulator parses the same syntax, both -eq and == forms, with parentheses, -and and -or.
| Property | Values | Operators |
|---|
| trustType | AzureAD (joined), ServerAD (hybrid joined), Workplace (registered) | -eq, -ne |
| isCompliant | "True", "False" | -eq, -ne |
| deviceOwnership | Company, Personal | -eq, -ne |
| operatingSystem, operatingSystemVersion, model, manufacturer, displayName, extensionAttribute1–15 | any string | -eq, -ne, -startsWith, -endsWith, -contains, -in and their -not forms |
An unregistered device has no properties: every value is null. Positive operators (-eq, -startsWith, -in…) then never match and negative operators (-ne, -notIn…) always match. That is why Microsoft recommends negative operators to target unmanaged devices. A rule can be at most 3,072 characters long.
Grant controls and authentication strengths
A policy blocks access or grants it with controls: require MFA, an authentication strength, a compliant device, a Microsoft Entra hybrid joined device, an app protection policy, a password change, risk remediation or terms of use. Require approved client app was retired in 2026; policies that still contain it no longer enforce it, and the simulator shows that. The three built-in authentication strengths accept these methods:
| Method | MFA | Passwordless MFA | Phishing-resistant MFA |
|---|
| FIDO2 security key / passkey | ✓ | ✓ | ✓ |
| Windows Hello for Business or platform credential | ✓ | ✓ | ✓ |
| Certificate-based authentication (multifactor) | ✓ | ✓ | ✓ |
| Microsoft Authenticator phone sign-in | ✓ | ✓ | |
| Temporary Access Pass | ✓ | | |
| Password + push, SMS, voice or OATH code | ✓ | | |
Give each user the methods they really registered in the Directory tab. An admin with only Authenticator push then shows as blocked by a phishing-resistant policy, and Windows Hello only counts on Windows.
Device-based controls in the browser
For require compliant device and hybrid joined device, Entra must see the device. Apps and Edge with a signed-in work profile pass the device identity; Chrome on Windows needs the Microsoft Single Sign On extension or the built-in Windows accounts setting, and some other browsers don't pass it at all. Untick browser passes the device identity in the What If form to see what a user on such a browser gets: the device looks unregistered, so the policy can't be satisfied.
Session controls
Session controls shape the session after access is granted: sign-in frequency (hours, days or every time), persistent browser session (only with All resources), app enforced restrictions for SharePoint and Exchange, Conditional Access App Control through Microsoft Defender for Cloud Apps, and disabling resilience defaults. When several applying policies set a sign-in frequency, the simulator shows the shortest one.
Import the policies of your own tenant
Read your policies with an account that can read Conditional Access (for example Security Reader or Global Reader) and paste the JSON into Import:
Connect-MgGraph -Scopes Policy.Read.All
(Invoke-MgGraphRequest -Uri 'v1.0/identity/conditionalAccess/policies' -OutputType Json) | Set-Content ca-policies.json
(Invoke-MgGraphRequest -Uri 'v1.0/identity/conditionalAccess/namedLocations' -OutputType Json) | Set-Content ca-locations.json
User, group, role, app and location IDs that the simulator doesn't know become placeholders in the Directory tab: give them a name and set group membership, roles and methods for your test users. The JSON stays in your browser's local storage until you load the sample again. A share link puts the policies in the link itself, so only share it with people who may see them.
This simulator or the What If tool in Entra?
The What If tool in the Entra admin center evaluates the real policies against real users and needs access to the tenant. This simulator is for the step before: designing policies, explaining them to colleagues, testing ideas without permissions and finding gaps across hundreds of combinations at once. Use both: design and test here, then confirm in Entra with What If and report-only mode.
More free tools