bbabafemi
All posts
Security

Conditional Access policies every Entra ID tenant should have

A baseline set of Conditional Access policies that block 80% of identity attacks — without becoming a productivity drag for your users.

September 9, 2025 3 min readby Babafemi Bulugbe

Conditional Access is the single highest-leverage security control in Microsoft Entra ID. It's also the place where most tenants either do too little (no policies) or too much (policies so strict that users find workarounds).

Here's the baseline I deploy on every new tenant. Six policies — none of them clever, all of them effective.

1. Block legacy authentication

What: Block any authentication that uses legacy protocols — POP, IMAP, MAPI, SMTP AUTH, ActiveSync basic auth.

Why: Legacy auth doesn't support MFA, so attackers love it. If you don't actively need it, kill it.

Users:    All users
Apps:     All cloud apps
Conditions: Client apps → Other clients (legacy auth)
Grant:    Block access

Run a "report-only" pass for two weeks first to identify any legacy auth in use. There are almost always 1–2 surprise integrations.

2. Require MFA for all users

What: Force MFA for every interactive sign-in, with a sensible exclusion list (break-glass accounts only).

Why: This single policy stops the majority of password-spray and credential-stuffing attacks.

Users:    All users (exclude: 2 break-glass accounts)
Apps:     All cloud apps
Grant:    Require MFA

If you're worried about user friction, layer it with policy #4 below.

3. Require MFA for admins (and require it on every sign-in)

What: A stricter version of #2 specifically for privileged roles.

Why: Admin sessions deserve a higher bar. This also kicks in if MFA was somehow skipped earlier.

Users:    Directory roles → all 14 highly privileged roles
Apps:     All cloud apps
Grant:    Require MFA
Session:  Sign-in frequency → 4 hours

Combine with PIM so privileged access is just-in-time, not standing.

4. Sign-in frequency for trusted users

What: Don't ask trusted, low-risk users to MFA every single day. Set a sensible session lifetime.

Why: MFA fatigue is real — and it's how attackers got into Uber. Reducing prompt frequency for low-risk users increases security because users stop reflexively approving every prompt.

Users:    All users (excluding admins)
Apps:     All cloud apps
Conditions: Sign-in risk → Low/None
Grant:    Require MFA
Session:  Sign-in frequency → 30 days, persistent browser

5. Block sign-ins from countries you don't operate in

What: Use a Named Location of "permitted countries" and block everything else.

Why: This is crude but devastatingly effective. Most attackers don't bother to use residential proxies in your country — they spray from cheap regions.

Users:    All users (excluding break-glass)
Apps:     All cloud apps
Conditions: Locations → Exclude permitted countries
Grant:    Block access

Be honest about which countries your users actually travel from — and add a process for temporary exceptions.

6. Require compliant or hybrid-joined device for sensitive apps

What: For your most sensitive apps (admin portal, finance system, HR), require the user to come from a managed device.

Why: This is the policy that defeats real attackers who get past MFA. A token replay from an attacker's machine still fails because that machine isn't enrolled in Intune.

Users:    Users with access to the sensitive app
Apps:     The sensitive app
Grant:    Require compliant device OR hybrid-joined device

If you're not on Intune yet, prioritize this — it's the single biggest jump in identity security available right now.


Two non-policy practices that matter as much

  1. Always keep break-glass accounts. Two cloud-only Global Admin accounts, excluded from every Conditional Access policy, with very long passwords stored in two separate vaults. If your CA policies break, these get you back in.

  2. Use report-only mode for new policies. Deploy as report-only, monitor sign-in logs for a week, then flip to enforcement. This will save you from a Friday-evening lockout.

What I deliberately don't include in the baseline

  • Risk-based policies (require P2 licensing — worth it, but separate post).
  • App-specific policies for SaaS apps you don't have yet.
  • BYOD-specific app protection — important, but Intune-shaped.

This baseline gets a tenant to a defensible position in an afternoon. Layer the more advanced stuff on top once it's stable.