There's a thread that keeps resurfacing in IT admin communities: "What conditional access policy baseline are you actually using across clients?" The answers range from "just MFA for all users" to elaborate 20-policy frameworks. But for most small business IT admins managing a 30- or 50-person Microsoft 365 tenant without a dedicated security team, neither extreme is helpful.
What you need is a prioritized order — the policies that stop the most attacks first, before you worry about the advanced stuff.
This guide gives you exactly that. And right now, the urgency is real.
The Threat Landscape Isn't Waiting for You to Catch Up
According to The Hacker News, attackers are actively running voice-phishing campaigns that trick Microsoft 365 users into enrolling attacker-controlled passkeys through fake Entra ID prompts. Once enrolled, the attacker has persistent, MFA-bypassing access to the account — and your basic "MFA for all users" policy does nothing to stop it because the attacker is the enrolled authenticator.
Separately, a Vidar infostealer campaign has been hammering small and medium businesses through malvertising, harvesting saved credentials from browsers and credential stores. If one of your employees has their M365 password sitting in Chrome, it's already at risk. And a Windows Defender zero-day — RoguePlanet — now has a published proof-of-concept exploit circulating publicly, meaning the endpoint you thought was protecting users may itself be compromised.
Layered together, these three threats form a complete attack chain: steal credentials, bypass MFA, and persist through a trusted authenticator. Conditional access policies are the layer that breaks this chain. Here's how to build them in the right order.
Policy 1: Block Legacy Authentication (Do This First, Today)
Legacy authentication protocols — SMTP AUTH, IMAP, POP3, older Office clients — don't support modern MFA. Attackers love them because they let credential stuffing attacks bypass your MFA policies entirely.
Set up: Create a CA policy targeting all users, all apps, with a condition filtering for legacy authentication clients. Set the grant control to Block.
This is non-negotiable. Every IT admin forum agrees on this one. Do it before anything else.
Watch for: Older printers, scanners, and shared mailboxes that use basic auth to send email. As we covered in our guide to shared credentials on printers and MFPs, these devices are a common blind spot — audit them before flipping this switch.
Policy 2: Require MFA for All Users (But Do It Right)
You probably already have this, but check the configuration. A common mistake is scoping the policy only to certain apps or excluding guest accounts.
Set up: All users, all cloud apps, grant requires multi-factor authentication. No exclusions except a single break-glass emergency account (which should be monitored for any sign-in activity).
Authentication method matters. SMS-based MFA is better than nothing but vulnerable to SIM-swapping and real-time phishing proxies. Authenticator app push notifications are stronger. Hardware keys or passkeys registered to your managed devices are strongest — but only if you control the enrollment process, which the current passkey phishing campaign specifically targets.
For a deeper breakdown of which MFA method fits your org, see our comparison of passkeys vs SMS MFA vs authenticator apps.
Policy 3: Require Compliant or Hybrid-Joined Devices for High-Risk Apps
This is where most small businesses stop — and where attackers exploit the gap. Even with MFA, a credential stolen by an infostealer can be replayed from an attacker's device. Requiring a compliant device (enrolled in Intune and meeting your compliance policy) means the session token is only valid from a device you manage.
Set up: Target Exchange Online, SharePoint, and Teams specifically. Require device to be marked compliant or hybrid Azure AD joined. Start with these three apps before expanding to all cloud apps.
Realistic note: If your org has unmanaged personal devices accessing company email, you'll need to decide: enroll them in Intune (with appropriate scope), or use an app protection policy as a middle ground. Either way, "any device, anywhere" is no longer an acceptable baseline.
Policy 4: Block or Limit Sign-Ins from High-Risk Locations
If your business operates entirely in the United States and you suddenly see a sign-in attempt from Romania at 2 AM, that's not a gray area.
Set up: Create a Named Location for your expected countries. Build a CA policy that blocks sign-ins from all other locations for standard users. For privileged accounts (Global Admin, Exchange Admin), consider requiring MFA plus a compliant device even from trusted locations.
Don't over-restrict: If you have remote workers or traveling employees, use sign-in risk policies (below) instead of hard geo-blocks to avoid legitimate lockouts.
Policy 5: Enable Sign-In Risk and User Risk Policies (Microsoft Entra ID P2)
This requires Entra ID P2 licensing, but if you're on Microsoft 365 Business Premium, you already have it. These policies use Microsoft's threat intelligence to flag anomalous sign-ins — impossible travel, leaked credentials, anonymous IP addresses — and require step-up authentication or block access automatically.
Set up: - Sign-in risk policy: Medium and above → require MFA - User risk policy: High → require password change
This is your automated response to the infostealer threat. When Vidar harvests a credential and it shows up in a breach database, Microsoft flags the user risk as High — and your policy forces a password reset before the attacker can use it.
Policy 6: Protect Privileged Accounts Separately
Your Global Admin account should never be used for day-to-day work, and it should have its own CA policy that is stricter than everyone else's.
Set up: A dedicated CA policy for admin roles requiring phishing-resistant MFA (FIDO2 key or certificate-based auth), compliant device, and blocking access from any non-trusted named location. No exceptions.
As we covered in our breakdown of Microsoft 365 breach prevention for small businesses, compromised admin accounts are the single highest-impact event in an M365 breach — one account, full tenant access.
A Note on Naming Conventions
The Reddit thread that inspired this post spent considerable time on naming. A consistent naming convention matters when you're managing multiple policies or multiple clients. A simple format that works:
[Scope]-[Target]-[Control]-[Number]
Example: ALL-Users-BlockLegacyAuth-001, PRIV-Admins-RequireFIDO-001
It's not glamorous, but when you're troubleshooting a sign-in failure at 11 PM, readable policy names save you.
The Order, Summarized
- Block legacy authentication — closes the MFA bypass door immediately
- Require MFA for all users — with a strong authentication method
- Require compliant devices for key apps — stops credential replay attacks
- Restrict sign-ins by location — eliminates obvious impossible-origin attacks
- Enable sign-in and user risk policies — automated response to credential theft
- Harden privileged accounts separately — your last line of defense
None of these require a security team. They require about four hours of focused configuration and a willingness to audit your environment for legacy dependencies first.
Take Action: Know What's Exposed Before You Configure
Conditional access policies are only as effective as your visibility into what's actually in your environment. Before you build policy #3, do you know every device accessing your M365 tenant? Before you set location restrictions, do you know where your users actually sign in from?
Proactive scanning catches the blind spots — unmanaged devices, misconfigured app registrations, exposed admin accounts — before attackers find them first.
Oscar Six Security's Radar gives you a full external vulnerability scan for $99. It's designed for small businesses and IT admins who need clear, actionable findings without enterprise-level complexity or pricing. Use it to validate your M365 posture before and after rolling out your CA policies.
Focus Forward. We've Got Your Six.