A defensible Conditional Access baseline

Most Microsoft 365 tenants we review have MFA turned on and a false sense of security because of it. MFA is necessary, but on its own it leaves real gaps. Attackers know the gaps, and they target the seams between policies rather than the policies themselves. Conditional Access is where you close those seams, and a handful of policies handle most of the risk.

What follows is the baseline we deploy early on a tenant, with the reasoning for each. Treat it as a starting point you adapt to your environment, not a script to paste in blind. Conditional Access can lock you out of your own tenant if you are careless, so every change below assumes you have a break-glass account excluded from the policies and stored safely. Set that up first.

Require MFA for everyone, then close the loopholes

The headline policy requires multi-factor authentication for all users accessing all cloud apps. That part most tenants have. The part they miss is that "MFA is on" usually means MFA is on for interactive sign-ins through the normal path, while legacy authentication protocols quietly bypass it entirely.

Legacy authentication is the protocols that predate modern auth and cannot do MFA. Attackers love them because hitting a legacy endpoint with a valid password skips the second factor completely. Block legacy authentication in its own policy. Before you do, check your sign-in logs for anything still using it, because the occasional old printer or line-of-business app will break, and you want to find those on your schedule rather than in a help-desk storm.

Make the second factor phishing-resistant where you can

Not all MFA is equal. Push notifications and one-time codes stop password spraying, but they do not stop a determined phishing attack that relays the code in real time or wears the user down with repeated prompts until they approve one to make it stop. We have investigated breaches that walked straight through app-based push.

Push the highest-value accounts, especially administrators, toward phishing-resistant methods. Passkeys and FIDO2 security keys cannot be relayed or fatigued. You may not get the whole organization there immediately, but your admins should be there quickly, because an admin account is the one an attacker most wants.

Treat admin roles as a separate, stricter world

Privileged accounts deserve their own policy with tighter conditions. Require phishing-resistant MFA for anyone holding an administrative role. Consider requiring that admin actions come from a managed, compliant device rather than any laptop that happens to have the password.

The principle is that the blast radius of a compromised admin is the entire tenant, so the controls protecting that account should be noticeably stronger than the ones protecting a standard user. If your global admins sign in the same way your interns do, you have flattened your most important security boundary.

Use device compliance, not just identity

Identity tells you who is signing in. It does not tell you whether the device they are on is trustworthy. A policy that requires a managed or compliant device for sensitive access raises the bar significantly, because now an attacker needs not just credentials and a second factor but a device your organization actually trusts.

This is more involved to roll out, since it depends on device management being in place, and it is worth sequencing carefully. But for access to the most sensitive applications, device compliance is one of the strongest conditions you can add.

Think about location, carefully

Location-based conditions are useful and easy to overrate. Blocking sign-ins from countries where you have no users or business cuts off a chunk of automated attack traffic for almost no effort. That is a reasonable, low-risk policy.

What location cannot do is be your primary control, because attackers route through infrastructure inside your allowed regions trivially. Use geographic blocking to reduce noise, not as a wall. And be careful with policies that trust your office network too much, because "inside the office" is a weaker signal than it used to be in a world of remote work and compromised internal devices.

Roll out in report-only first

Every policy above can be deployed in report-only mode, where Conditional Access evaluates the policy and logs what would have happened without actually enforcing it. Use this. Run new policies in report-only for a week, watch the sign-in logs for what they would have blocked, and fix the surprises before you flip to enforcement.

This single habit prevents the most common Conditional Access disaster, which is a well-intentioned policy that locks out a department on a Monday morning. Report-only turns a potential outage into a quiet log entry you can investigate calmly.

Where this leaves you

These policies, deployed thoughtfully and tested in report-only, close the gaps that catch most tenants. They are not the finish line. Identity protection, app governance, and tuning for your specific risks come next. But a tenant with these in place is dramatically harder to break into than the MFA-only configuration that most organizations mistake for done.