Conditional Access is the most powerful security control in Microsoft 365 and the most commonly misused. Deployed well, it's the biggest lever you can pull on account takeover risk. Deployed badly, it's the reason your CFO can't log in from Singapore at 9pm on a Sunday.
This is the policy set we deploy for Australian mid-market businesses. It's structured as an override stack — each policy does one thing, in priority order, and every policy has a break-glass account excluded.
Policy 1 — Block legacy authentication
Legacy auth (IMAP, POP, SMTP AUTH, older Exchange Web Services clients, MAPI over HTTP with basic auth) bypasses MFA entirely. Any Conditional Access program that doesn't start here is theatre.
Target: all users, all cloud apps, client apps = 'Exchange ActiveSync clients + Other clients'. Grant: block. Exclude a break-glass admin account. Run in report-only for 14 days first — you will find at least one integration you didn't know used basic auth.
Policy 2 — MFA for all users, all apps
Target: all users, all cloud apps. Grant: require MFA. Exclude break-glass, and — critically — exclude service principals / managed identities that shouldn't be doing user auth.
This is a blunt policy. Pair it with Policy 3 below so that 'MFA required' doesn't mean 'prompt every login' in practice.
Policy 3 — Sign-in frequency on managed devices vs unmanaged
On compliant, Intune-managed devices, sign-in frequency = rolling (token persists for the default 90 days). On unmanaged devices, sign-in frequency = 8 hours, and set 'persistent browser session' to 'never persistent'.
This is the policy that keeps executives happy. On their managed laptop, they sign in Monday and don't see an MFA prompt again all week. On a hotel business-centre PC, every session is time-boxed and non-persistent.
Policy 4 — Require compliant device for sensitive apps
Target: admin portals, SharePoint sites tagged as high-sensitivity, HR and finance apps. Grant: require device to be marked compliant OR require Hybrid Entra join.
This is the policy that stops the 'valid creds on a random iPad' attack. It's also the one that breaks BYOD the hardest — so scope it tightly to apps and sites that actually warrant it.
Policy 5 — Phishing-resistant MFA on admin roles
Target: users in admin directory roles (Global Admin, Privileged Role Admin, etc.). Grant: require Authentication Strength = Phishing-resistant MFA.
This forces Windows Hello for Business or FIDO2 keys for anyone in a privileged role — SMS and Authenticator push are no longer enough. Under ML2 of the Essential Eight, this is mandatory on privileged accounts.
Policy 6 — Risk-based policies via Entra ID Protection
Target: all users. Grant: on high sign-in risk, require MFA + password change. On high user risk, block or require password change.
Identity Protection is an E5 / P2 feature. For Business Premium tenants, the equivalent is the 'risky sign-ins' detections surfaced in Entra ID, acted on manually or through Defender for Identity. If you have P2, turn these policies on.
Try it
Check where CA fits in your Essential Eight posture
Run the Essential Eight tool — Conditional Access sits across MFA, restrict-admin and user application hardening strategies.
Score each of the 8 strategies
Where are you on the Essential Eight — honestly?
Eight strategies. Four levels each. Pick the statement closest to your reality today. We'll map it to the Microsoft 365 tooling that closes the gap.
What's your target Maturity Level?
Maturity Level 2 — most orgs' pragmatic target
- 01
Application control
Only approved applications can execute on workstations and servers.
- 02
Patch applications
Internet-facing apps, browsers, Office, PDF readers patched promptly.
- 03
Microsoft Office macros
Macros disabled unless from trusted locations and signed by a trusted publisher.
- 04
User application hardening
Web browsers and productivity apps hardened against the most common attacks.
- 05
Restrict administrative privileges
Admin accounts limited, separated and reviewed — the crown jewels of the tenant.
- 06
Patch operating systems
Operating system patches applied on a schedule that matches the risk.
- 07
Multi-factor authentication
MFA everywhere that matters — privileged accounts, remote access, important data.
- 08
Regular backups
Backups of important data, configuration and software — and restores you have actually tested.
The travel problem — and the fix
The classic Conditional Access failure is the 'block untrusted countries' policy that the security team applied tenant-wide. Three weeks later, the CEO is in Tokyo and can't access SharePoint.
The fix: don't block by country. Use country signals as part of risk scoring (Entra Identity Protection does this natively), and require additional assurance on anomalous sign-ins — not a hard block. The pattern 'MFA + compliant device' is stronger and more portable than 'block if not Australia'.
Break-glass hygiene
Every Conditional Access policy above excludes a break-glass account. That account has: a 32-character random password stored in two physical safes, no MFA (the account is the MFA fallback itself), no Conditional Access applied, a Global Administrator role, and an Entra alert that fires on any sign-in activity.
You will use the break-glass account once a decade, if ever. But the one time you need it — tenant-wide Conditional Access misconfiguration, MFA provider outage, compromised admin account — you really need it.
Report-only, always
Every new Conditional Access policy goes into 'Report-only' mode first for at least 14 days. The What-If tool in Entra ID lets you test specific user/app combinations, but nothing replaces 14 days of real telemetry. The report-only sign-in log will show you exactly who would have been blocked, and why.