Conditional Access (CA) is the single highest-impact security control in Microsoft 365. Configured well, it closes the vast majority of common attack paths — credential stuffing, password spray, legacy protocol abuse, impossible-travel sign-ins, lost-device compromise. Configured poorly (or not at all), Defender for Business is doing damage control on attacks that should never have got past the front door.
Here are five Conditional Access policies every M365 tenant should have. Specific settings, no fluff. Test them in report-only mode before enforcement — every one of these can lock people out if applied carelessly.
Prerequisites
You need Microsoft 365 Business Premium (or any tier including Entra ID P1) to use Conditional Access. Business Basic and Standard don’t include it.
Two things to set up before the policies:
- A break-glass account. A dedicated Global Administrator account that’s excluded from every CA policy. Used only when normal admin access is locked out. Password stored offline (printed, in a fireproof safe). Reviewed quarterly. Never used for normal work.
- An “Excluded users” group. Service accounts, vendor accounts, the break-glass account. Excluded from policies that would interactively challenge them (since they can’t satisfy MFA prompts).
Both these prerequisites are non-negotiable. Without them, an enforcement mistake locks out everyone.
Policy 1: Require MFA for all users
Settings:
- Users: All users
- Excluded users: Break-glass + excluded service accounts group
- Cloud apps: All cloud apps
- Conditions: None
- Grant: Require multifactor authentication
Why: Compromised passwords without MFA are the #1 entry point into M365 tenants. MFA stops the vast majority of credential-based attacks at the door. This is the floor.
Implementation note: Microsoft offers “Security Defaults” which apply something similar. They’re sufficient for very small tenants but inflexible. Custom Conditional Access gives you the control to add geo-restriction, device compliance, and risk-based policies layered on top.
Policy 2: Block legacy authentication
Settings:
- Users: All users (including break-glass — legacy auth doesn’t support MFA so it’s a known attack vector even from break-glass)
- Cloud apps: All cloud apps
- Conditions: Client apps → check “Exchange ActiveSync clients” and “Other clients”
- Grant: Block access
Why: Legacy authentication protocols (basic auth on POP/IMAP/SMTP, older Exchange ActiveSync, MAPI/RPC) don’t support MFA. An attacker with stolen credentials can bypass MFA entirely by signing in via legacy protocols. Most tenants don’t actually use these protocols anymore — but the attack surface is still wide open until you explicitly close it.
Implementation note: Run this in report-only mode for at least 7 days first. The report tells you who’s still using legacy auth — typically older mail clients, scanner-to-email devices, or specific third-party applications. Update those before enforcing.
Policy 3: Block sign-ins from outside Australia
Settings:
- Users: All users
- Excluded users: Break-glass + users with documented overseas travel exemptions
- Cloud apps: All cloud apps
- Conditions: Locations → Include “All locations”; Exclude “Australia” (custom named location)
- Grant: Block access
Why: Most AU SMBs have no legitimate sign-in traffic from outside Australia. Blocking everything else closes off the entire foreign-IP attack surface (where most credential-stuffing attacks originate). It’s not bulletproof — attackers can route through Australian VPN endpoints — but it removes 80%+ of the noise.
Implementation note: Create a custom named location for “Australia” first in Entra ID > Identity > Conditional Access > Named locations. Use the country list (Australia) rather than IP ranges. If staff travel internationally, either grant time-limited exemption via a separate ad-hoc policy or rely on the policy below (risk-based MFA) to handle legitimate travel cases.
Policy 4: Require compliant device for admin role members
Settings:
- Users: Directory roles → Global Administrator, Privileged Role Administrator, Conditional Access Administrator, Application Administrator, Cloud Application Administrator
- Cloud apps: All cloud apps
- Conditions: None
- Grant: Require device to be marked as compliant (Intune)
Why: Privileged admin accounts are the keys to the kingdom. If an admin signs in from a personal phone in a café, an attacker who steals that session can do tenant-level damage. Requiring a managed, compliant device for admin sign-in raises the bar significantly.
Implementation note: You need Intune (included in M365 Business Premium) and at least one device enrolled and marked as compliant for each admin user before enforcing this. Otherwise enforcement instantly locks out the admin. Microsoft’s “compliant device” policy is straightforward — enable it via Intune > Devices > Compliance policies, set the baseline (encryption required, OS version minimums, password requirements), and verify your admin device shows as compliant before applying.
Policy 5: Risk-based MFA prompt or block
Settings:
- Users: All users
- Excluded users: Break-glass
- Cloud apps: All cloud apps
- Conditions: User risk → Medium and High; Sign-in risk → Medium and High
- Grant: Require multifactor authentication (for medium risk); Block access (for high risk)
Why: Microsoft’s risk-based signal engine flags sign-ins that look anomalous — impossible travel, sign-in from a known-malicious IP, sign-in from an anonymising service (Tor), credentials seen in a breach corpus. High-risk sign-ins get blocked entirely; medium-risk get re-prompted for MFA. This catches attacks that pass the other policies (e.g. an attacker signing in via an Australian VPN with stolen + breached credentials).
Implementation note: Risk-based policies require Entra ID P2 (which is included in Microsoft 365 E5 or available as a standalone licence). M365 Business Premium includes Entra ID P1 only — which still gives you risk-based signal awareness in reports but not the policy enforcement. For Premium-tier OIT clients we recommend the P2 upgrade for the policy enforcement; for Standard tier clients we’ll usually layer Huntress ITDR on top of P1 to get equivalent identity-threat coverage.
The order of operations
Apply in this order, each in Report-only mode first for 7 days, review the report, then enforce:
- Block legacy authentication (Policy 2) — close the easy attack path first
- Require MFA for all users (Policy 1) — the floor
- Geo-block outside AU (Policy 3) — narrows the attack surface
- Compliant device for admins (Policy 4) — protect the keys
- Risk-based MFA/block (Policy 5) — catches what slips through
Don’t apply five policies to enforcement on the same day. Spread them across 2-3 weeks; users adapt; you have time to react if one breaks something.
What this gets you
Five policies, sensibly configured, close:
- All credential-only attacks (no MFA = no entry)
- All legacy-protocol attacks (legacy auth is blocked)
- ~80% of foreign-IP attacks (geo-block)
- Admin-from-personal-device attacks (compliant device required for admins)
- ~95% of breached-credential attacks (risk-based block on high risk)
What it doesn’t get you: zero-day attacks against M365 itself, social engineering of legitimate users to authorise OAuth apps, supply-chain compromise of vendors with delegated access. Those need Defender for O365, third-party email security, and process discipline. But the five CA policies above are the cheapest, highest-impact start.
Outlaw IT baseline
For every Outlaw IT client tenant on Essentials tier or above, we apply these five policies as part of onboarding (with the OIT-specific tuning for your business — e.g. travel patterns, after-hours admin requirements, specific service accounts). The full baseline is documented in our internal CIPP Standards library — applied across all client tenants on the 12-hour drift-check cycle.
If you’re an M365 admin reading this and don’t have these policies in place, the next 30 minutes is the most productive security work you’ll do this quarter.
If you’d rather have someone else implement this for you, book a discovery call.