Conditional Access is the Microsoft Entra policy engine that evaluates each sign-in against assignments and conditions and then grants, blocks or restricts the session. Each part of a policy has a specific job, and many wrong answers put a control in the wrong part. Figure 1.2 shows how the parts fit together.
| Policy part | Holds | Examples |
|---|---|---|
| Users / agents | Who is in scope, with exclusions | Users, groups, directory roles, agent identities |
| Target resources (Cloud apps or actions) | Which app | All resources, Windows Azure Service Management API (formerly Microsoft Azure Management) |
| Conditions | When it applies | Device platform, locations, sign-in/user/agent risk |
| Grant controls | Block, or require controls | MFA, compliant device, approved client app, app protection policy |
| Session controls | Session lifetime and restrictions | Sign-in frequency, app-enforced restrictions |
- Sign-in frequency (e.g. 3 hours) is the session control that forces periodic reauthentication.
- Require device to be marked as compliant is a grant control; device platform is a condition.
- Windows Azure Service Management API (formerly Microsoft Azure Management) covers the Azure portal and ARM, not web services hosted in the subscription (those are separate apps). All resources covers the Azure portal and Microsoft 365.
Common trap: Configuring the compliant-device requirement under Conditions - it’s a grant control; Conditions only decide when the policy applies (device platform, location, risk).
Testing policies safely
- The What If tool evaluates policies that are On or Report-only; policies that are Off are ignored.
- Report-only evaluates a policy without enforcing it on anyone, so it’s the minimal-impact way to trial a new policy. On enforces immediately.