All posts
Microsoft 365Entra IDSecurity

Microsoft 365 Entra ID conditional access: the 5 policies we set up first

March 22, 20268 min readby Chaz Chamberlain

Conditional Access is the single highest-leverage control in Microsoft 365 security — and most tenants only have the default, which is nearly nothing. The five baseline policies we configure on day one.

If you pay for Microsoft 365 Business Premium or any Entra ID P1/P2 license, you already have access to the single highest-leverage security control Microsoft sells: Conditional Access. And about 80% of tenants we inherit have exactly one policy: the default “require MFA” baseline that Microsoft enabled for them automatically.

That’s not security. That’s a checkbox.

Here are the five Conditional Access policies we configure on day one for any client using Microsoft 365 seriously. In order.

Before you start: policy hygiene

Two rules that apply to everything below:

  • Always create a break-glass account first. One highly-privileged account excluded from every policy, with a very long password stored offline. If you lock yourself out with a Conditional Access policy that blocks all admins, this account gets you back in. Without it, you’re calling Microsoft support.
  • Build in report-only mode first. Every new policy gets deployed in report-only for at least 72 hours. You check the sign-in logs to see who would have been blocked. Then you flip it to enabled. Skipping this is how you lock out the CFO on a Tuesday morning.

Policy 1: Require MFA for all users

Yes, the default baseline covers this. The explicit policy does two things the baseline doesn’t:

  • Applies to all cloud apps, not just the ones Microsoft flags as high-risk.
  • Lets you exclude your break-glass account explicitly. Baselines don’t give you that knob.

Configuration: Users = All users, exclude break-glass account. Cloud apps = All cloud apps. Grant = Require multi-factor authentication.

Policy 2: Block legacy authentication

Legacy authentication means old protocols — IMAP/POP, SMTP AUTH, older Outlook clients, anything pre-modern-auth. These protocols can’t enforce MFA. Attackers love them because Policy 1 stops applying the moment the sign-in is over IMAP.

In 2026 there is essentially no legitimate reason for legacy auth in a modern environment. Microsoft started phasing it out years ago. Block it at the Conditional Access layer so even if it comes back, it can’t be used.

Configuration: Users = All users (exclude break-glass). Cloud apps = All. Conditions = Client apps = Exchange ActiveSync + Other clients. Grant = Block access.

Policy 3: Require compliant or hybrid-joined device for admin users

If you’re an admin, you don’t log in from an untrusted device. Period. An admin account compromised on a personal laptop is the worst-case scenario: attacker has keys to the entire tenant.

This policy forces admin sign-ins to come from a device that’s enrolled in your MDM (Intune for Microsoft, or a hybrid-joined Windows device). Work device = access. Random coffee shop Chromebook = blocked.

Configuration: Users = Directory roles (pick Global Admin, Security Admin, etc.). Cloud apps = All. Grant = Require device to be marked as compliant OR hybrid Azure AD joined. Use “require one of the selected controls.”

Policy 4: Block sign-ins from unsupported countries / regions

For most small-to-mid businesses, your team signs in from 1-5 countries. The vast majority of automated attack traffic comes from elsewhere.

Rather than playing whack-a-mole with threat feeds, we invert the list: allow sign-ins only from named locations where your team actually works, and block everything else. Requires you to maintain the location list, but that’s a 2-minute job once a quarter.

Configuration: Users = All. Cloud apps = All. Conditions = Locations = “Any location”, exclude named locations for your allowed countries. Grant = Block access.

Caveat: if your team travels internationally often, handle it with a “travel” named location you add/remove as needed, or with temporary policy exclusions. Don’t let policy friction create a shadow IT where people start using personal accounts for work.

Policy 5: Session controls for browser access to Microsoft 365

This one isn’t about logging in — it’s about what happens after. Session controls let you:

  • Disable download of sensitive files to unmanaged devices
  • Require users to re-authenticate every N hours
  • Prevent printing from the browser session
  • Force sign-in persistence to not persist on non-corporate devices

The specific controls depend on your data sensitivity. For most SMBs the minimum is: “non-persistent browser sessions on unmanaged devices.” Means if someone signs in from a personal browser, the session ends when they close the window.

Configuration: Users = All. Cloud apps = Office 365 (or specific apps). Conditions = Device state = Not compliant/hybrid. Session = Use Conditional Access App Control = Monitor only with custom policy (requires Defender for Cloud Apps for the full set).

Things we also do but aren’t in the top 5

  • Require phishing-resistant MFA for admins. SMS and notifications are fine for users but admins should be on FIDO2 keys, Windows Hello for Business, or Authenticator with number matching only.
  • Risk-based policies (requires P2 licensing). Block sign-ins when Microsoft’s risk engine flags the session as high-risk. Powerful, but not every org has P2.
  • Separate policies per app for high-risk cloud apps (e.g., stricter controls on PowerShell access than on Teams).

Why this works

These five policies don’t require advanced licensing beyond Business Premium or P1. They compound: Policy 1 keeps attackers out of simple credential stuffing. Policy 2 closes the legacy-auth escape hatch. Policy 3 limits the blast radius of a compromised admin. Policy 4 filters the bulk of automated attack traffic. Policy 5 limits data exfiltration when something does go wrong.

No one policy makes your tenant “secure.” All five together eliminate 95% of the attack paths that actually get used against SMB Microsoft 365 tenants in the wild.

If your tenant only has the default baseline today

You’re not alone. Most tenants we inherit look this way. This is fixable in an afternoon — with the report-only safety net we mentioned, so nobody gets locked out. It’s one of the highest ROI things we do on Microsoft 365 engagements.

If you’d like a second set of eyes on your current posture, a clarity call walks through your current policies and gives you a concrete list of what to change. No sales pitch — you’ll leave with a priority list either way.

Conditional Access is the best security dollar Microsoft sells and the most commonly underconfigured feature in their entire stack.

Questions like this on your own environment?

We help growing teams make these calls in plain language — no vendor push, no hourly clock. Book a clarity call and we'll walk through yours.

Book a Clarity Call