Entra ID Conditional Access design

Conditional Access (CA) is the Entra ID engine that decides what happens to every sign-in based on signals: who, where, what device, what app, what risk. Designed well, it's the single most effective control in Microsoft 365. Designed badly, it locks people out at midnight.

This guide is the pattern I use for greenfield CA designs and for cleaning up estates that grew organically. It's opinionated. There is more than one reasonable design, but there are many unreasonable ones, and most estates I inherit sit in the unreasonable zone — too many overlapping policies, no break-glass discipline, no report-only stage.

The principles

Five that hold every time.

Default to deny. Assume no implicit access. Every grant is explicit. This is the practical shape of Zero Trust — nothing about who signed in, from where, or with what device is trusted until CA has evaluated it.

Layer. Many small, single-purpose policies are easier to reason about than a few large ones. A single policy that scopes to "all users except contractors, all apps except line-of-business, all locations except HQ" is almost impossible to debug when a sign-in fails. Two or three narrower policies with clean conditions and clean grant controls are worth the extra rows in the policy list.

Always allow break-glass. A small set of emergency accounts — two, minimum — excluded from every enforcement policy, with very strong credentials (long random passwords stored physically in two locations, ideally paired with FIDO2 keys), unmonitored MFA (a phone tied to an admin's personal number defeats the purpose), and sign-in alerts wired to a channel someone actually watches. If the identity provider or an over-eager CA policy locks the tenant, break-glass is the only way back in.

Test in report-only first. Every policy supports a Report-only mode that logs what would have happened without enforcing anything. Use it. A week in report-only surfaces the sign-ins your policy would have broken — the on-call rotation account, the service-principal-that-actually-a-user, the CEO's iPad — before your Monday-morning stand-up is entirely about failed logins.

Document why. Each policy needs a clear purpose captured somewhere the future admin will find it. The policy name is the first place ("CA002 - Block legacy auth - baseline"); an internal wiki page with the policy list, the assignment rationale, and the review date is the second. Naked policies without written intent are the ones nobody dares touch.

A baseline policy set

A reasonable starting baseline, applied in this order:

1. Block legacy authentication. POP, IMAP, SMTP basic auth, Exchange ActiveSync basic auth. These bypass MFA entirely. Block them with no exceptions and disable basic auth in Exchange Online for good measure — CA blocks the connection, Exchange disable stops even the attempt.
2. Require MFA for all users. Every user, every cloud app, with the named break-glass accounts excluded. This is the single most impactful policy in the estate; if you deploy nothing else, deploy this.
3. Require MFA for admins. Even tighter — every admin role, every location, no location exception. Pair with Privileged Identity Management (PIM) so admin roles are activated on demand with justification, not standing.
4. Require compliant or hybrid-joined device for Office 365. Adds Intune-based device posture: only devices Intune has enrolled and marked compliant get the productivity apps. Exempt web-only sign-ins from unmanaged devices if you then bind them under an app-enforced session control (below).
5. Block access from high-risk countries. Or, less blunt, require step-up authentication (MFA + terms of use) from them. A blocklist is easier to justify than a broad "block everything except EU" for a Sweden-only workforce, and both patterns are common.
6. Block high-risk users and sign-ins. Uses Entra ID Identity Protection signals — user risk (leaked credentials, atypical behaviour) and sign-in risk (unfamiliar location, anonymous IP, malware-linked IP). Requires P2 licensing.
7. Require terms of use for external users. B2B guests accept the acceptable-use terms once per version; this is the mechanism where you can say "yes we have you sign an AUP even though you don't work here".
8. Session controls. Restrict downloads on unmanaged devices via app-enforced controls, restrict copy/paste and print in mobile apps via Intune App Protection, restrict access outside of business hours if the workload demands it.

The eight above are a full baseline for most SMB and mid-market estates. Add narrower policies from there — a "require phishing-resistant MFA for finance role" policy, a "allow SharePoint from managed device only" policy — as the risk model demands.

What signals you can use

CA lets you condition on:

• User: individual user, group, directory role, internal / guest, external tenant.
• Cloud app: every Microsoft 365 app plus third-party apps that use Entra ID for SSO. "All cloud apps" is a common scope but explicit apps let you shape narrower policies.
• Device: compliance state (from Intune), hybrid-join state, ownership (corporate vs personal), operating system, browser vs client app.
• Location: named IP ranges, countries, trusted / untrusted. Country signals come from Entra's geo lookup on the sign-in IP; treat them as approximate.
• Sign-in risk: real-time evaluation by Entra ID's risk engine — anonymous IP, unfamiliar sign-in properties, atypical travel, malware-linked IP, leaked-credential detection.
• User risk: cumulative risk score for the account — leaked credentials, suspicious sign-in patterns, admin-flagged risk.
• Client app: modern authentication, legacy authentication, Exchange ActiveSync — how the sign-in is arriving.

The grant controls (what happens once the conditions match) are: block, require MFA, require compliant device, require hybrid-joined device, require approved client app, require app protection policy, require password change, terms of use, custom authentication strength (e.g. phishing-resistant only).

Session controls layer on top of a grant: app-enforced restrictions in SharePoint / Exchange, sign-in frequency, persistent browser session, Defender for Cloud Apps in-session controls (block download, block copy, watermark).

Rolling out

Deploy in four stages. Never skip stages under time pressure — the cost of a botched rollout is measurable in help-desk hours and executive frustration.

Stage 1: report-only. Every new policy starts here. Watch the Sign-in Logs (filtered on the report-only policy) for at least a week — longer if a monthly close or a quarterly board pack sits inside the window. Look for sign-ins that would have been blocked and are legitimate; those are your exceptions.

Stage 2: pilot enforce. Enable enforcement for a small group (IT team + a friendly business unit). Two weeks minimum. This is where you find the friction that report-only masks — the MFA prompt frequency that annoys the sales team, the compliant-device requirement that breaks the shared kiosk.

Stage 3: broad enforce. Roll out to the rest of the tenant. Watch the sign-in-failure dashboard daily for the first two weeks. Announce the change to end users in advance and give them a channel to report false positives.

Stage 4: hard-close. After a month, tighten any remaining exclusions and archive the exception list. If a group was excluded temporarily, remove it. Untouched temporary exclusions become permanent bypasses; policy debt compounds.

Common mistakes

Excluding too few accounts from break-glass policies — a single account is one lost phone away from lockout. Two minimum, three is sensible.

Overlapping policies whose combined effect is hard to predict. Every policy has to be evaluated against every sign-in; the interaction matrix grows quickly. Keep the policy count manageable.

Forgetting to scope policies to all cloud apps — partial scopes leak. Every new app added to the tenant should be covered by the baseline. Use "All cloud apps" and explicit exclusions where a specific app must be treated differently, not a positive-list of apps that omits new ones by accident.

Skipping report-only mode. This is the number-one cause of Monday-morning rollback.

Ignoring guests. Guest sign-ins go through CA too, and the design decisions differ — you may not want to require Intune compliance for a guest, but you almost certainly want MFA.

Standing admin roles instead of PIM-activated ones. A permanent Global Admin is a permanent target; a Global Admin who has to activate for one hour with justification is much narrower.

Operating the estate

CA is not a one-time project. Treat the policy set as living configuration, reviewed quarterly against new threats and new apps.

Every quarter: walk the policy list with one person from Security and one from IT Ops. Read every policy aloud. Reconfirm the intent. Reconcile against the wiki. Retire anything that is no longer needed and rename anything whose name no longer matches its behaviour.

Every incident that touches identity: check the CA log first — the policy evaluation for the incident's sign-in tells you which policy blocked or allowed, and often points at a mis-design.

Conditional Access Templates in the Entra portal are Microsoft's starting-point set — worth cloning as a reference, but treat them as a checklist, not a drop-in configuration.

Backup the policy set. The Microsoft365DSC PowerShell module can export the whole CA configuration as code; commit it to a Git repository, review changes through pull requests, and reapply from source in a disaster. Enterprise CA estates without policy-as-code are a step behind.

Licensing

Conditional Access requires Entra ID P1, included with Microsoft 365 Business Premium, E3, E5, F3, and as a standalone licence. Identity Protection (sign-in risk, user risk) requires P2. Session controls that depend on Defender for Cloud Apps require the Defender for Cloud Apps licence.

For most estates, Microsoft 365 E3 with Entra ID P2 as an add-on (or E5, which bundles P2) is the working baseline for a full CA + Identity Protection deployment.