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 individual policies in this baseline have their own how-to pages: block legacy authentication, require MFA for all users, require compliant devices, and create the break-glass accounts that every policy excludes. The supporting mechanisms — named locations, authentication contexts, Continuous Access Evaluation, and token protection — are covered separately.

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.

A worked example: baseline policy set

A pragmatic baseline for a mid-market tenant on Microsoft 365 E3 + Entra ID P2, applied in report-only for two weeks before enforcement:

1. Block legacy authentication — all users, all apps, all clients that authenticate via legacy protocols. Non-negotiable.
2. Require MFA for all users — excluding the two named break-glass accounts and the on-premises Entra Connect sync account; those live outside CA.
3. Require compliant device for admins — targeted at the Entra role groups (Global admin, User admin, Security admin, Exchange admin, SharePoint admin, Intune admin, Compliance admin, Conditional Access admin) — device compliance managed in Intune.
4. Require phishing-resistant MFA for privileged roles — same admin scope; enforces FIDO2 keys or Windows Hello for Business, no push OTP.
5. Session controls for guests — sign-in frequency 8 hours, no persistent browser session.
6. Block sign-ins from anonymising IP or unfamiliar sign-in properties (high risk) — Identity Protection–driven; requires P2.
7. Require password change for high user risk — Identity Protection user-risk driven; requires P2.
8. Block or grant with terms of use for external users accessing sensitive apps (SharePoint, Purview, Defender portal).
9. Application enforced restrictions for SharePoint/OneDrive on unmanaged devices (web-only, no download).
10. Country/region block for the countries the organisation demonstrably does not do business in (short list — geo-block lists get stale fast).

Every policy above starts life in report-only and moves to on only after the impacted user report matches expectation. This is the difference between a working CA design and a live lock-out incident.

Decision matrix: which control to reach for

| Concern | Reach for | | --- | --- | | Legacy protocols | Block legacy authentication CA policy | | Weak MFA methods | Authentication strengths (phishing-resistant) | | Untrusted device | Require compliant device or hybrid-joined | | Untrusted network | Named location + Trusted Locations or Global Secure Access | | Compromised session | Sign-in risk (Identity Protection) | | Compromised account | User risk + password change | | Excessive session lifetime | Sign-in frequency + persistent browser controls | | Untrusted client app | Approved client apps or app protection policies | | High-value app on personal device | App-enforced restrictions (web-only) or Global Secure Access | | Change from unexpected geography | Country/region block or MFA on risk |

When Conditional Access is the wrong tool

• You have no break-glass path. Do not deploy CA without two documented break-glass accounts (excluded from every policy, FIDO2 keys in a physical safe, monitored via sign-in log alerts). CA lockouts have taken tenants offline for days; this is preventable.
• You have no MFA registration campaign. Enforcing MFA before users have registered a method is how you generate a Level-1 support wave. Run a registration campaign for 30 days first.
• Your app is federated to ADFS with claims rules doing the same work. Migrate the app to Entra ID authentication first, then let CA govern it. Two policy engines for the same app is unsustainable.
• You need per-transaction authorisation inside an app. That's app-side authorisation logic, not CA. CA is coarse-grained (allow session or don't).
• You're trying to block a specific user. Disable the account. CA is a policy engine, not a per-user firewall.

MSP checklist

• Baseline template per client tier. SMB tier ships policies 1–5 above; mid-market adds 6–10; regulated adds Identity Protection-based enforcement plus custom named locations.
• Report-only lifecycle. Every new policy in every tenant starts in report-only for at least seven days. Diff the What-If report against the actual sign-in log before flipping.
• Break-glass audit. Weekly report of break-glass account sign-ins. Any use that wasn't a documented drill is a P1 incident.
• Cross-tenant baselines via Lighthouse. For MSPs with 20+ tenants, Microsoft 365 Lighthouse surfaces baseline compliance drift across the estate faster than clicking through each portal.
• Change control. CA changes go through a documented review path — not "the on-call engineer edited a policy at 2 am". The audit log records who and what; a change ticket records why.