A surprising number of the tenants I review have no Conditional Access at all, or only a half-hearted version of it. Maybe there's a token MFA policy or two, but the actual security foundation usually isn't there. That's despite Conditional Access having been part of Microsoft Entra ID for years (and yes, Azure AD was renamed in July 2023, so sticking to old habits doesn't hold up anymore). Smaller or freshly migrated environments in particular tend to skip the basics, and that leaves real gaps in cloud security.

Every admin account needs MFA before anything else

The most important step is to enforce multi-factor authentication for all privileged accounts. It sounds obvious. Still, in real tenants I keep finding it overlooked or only partly done. Administrators sometimes rely on outdated methods like SMS or phone call authentication and skip modern, phishing-resistant options such as the Authenticator app, FIDO2 keys or passwordless sign-in. My recommendation is always a dedicated policy that targets every user with any admin role and requires a strong second factor. It shrinks the attack surface considerably, and from what I've seen, you can't do without it.

Legacy authentication gets blocked with no exceptions

Legacy authentication is a problem I run into all the time. These old protocols (IMAP, POP, SMTP Basic, etc.) don't support modern authentication, and they give attackers an easy way in. Microsoft's own documentation has recommended blocking legacy auth for years (see the guidance here). Even so, I still come across tenants with legacy protocols switched on, usually because of an old scanner or someone who won't upgrade their mail client.

Practical tip: Run any legacy auth block policy in report-only mode first and keep a close eye on your logs. That way you find the users and devices still depending on legacy protocols before you cut them off, and you spare yourself a lot of support tickets.

MFA has to cover every user, not only the admins

Once the privileged accounts are protected, MFA should go out to everyone else. Any identity can be a target, and I honestly can't think of a good argument against making MFA the default. Passwordless options like Windows Hello for Business or the Authenticator app make the rollout easier in my experience. People push back less, and MFA gets in the way much less during the working day.

Risk-based policies make sense once you have P2

If your organization has Entra ID Premium P2 licenses, you should be using risk-based sign-in policies. They react to suspicious activity as it happens and can require extra authentication, block access or force a password reset depending on the real-time risk. Large, distributed organizations get a lot out of this additional layer. Microsoft's official documentation on Conditional Access policies gives a good overview. I've had good results leaving risk-based policies in report-only mode for a few weeks before enforcing them across the whole tenant.

Report-only mode lets you test without breaking things

For me, report-only mode is one of the most useful features in Conditional Access. Any policy can run as a kind of dry run that shows which users and apps would be affected, while nothing is actually enforced yet. You catch unintended side effects early, which matters most with disruptive policies like a legacy auth block or MFA for everyone. I don't roll out a new policy until I've watched it in report-only mode for at least a week.

Break-glass accounts are your last line of defense

Break-glass accounts get overlooked a lot. These are emergency admin accounts that Conditional Access policies don't apply to, so if an overly strict policy locks you out, you still have a way back in. Good practice for break-glass accounts includes:

  • Setting a very strong, complex password
  • Keeping MFA to a minimum or excluding it (or using methods that always work)
  • Using them only in emergencies
  • Testing and reviewing them regularly
  • Setting up monitoring and alerts

Document these accounts, test them from time to time and don't let them slide. They look like a small detail, but they've kept more than one organization from being locked out completely.

The What-If tool simulates sign-ins before you commit

Conditional Access policies get complicated quickly, and how several policies interact isn't always obvious. The What-If tool in the Entra ID portal simulates sign-ins with different parameters (user, app, location, device) and shows you right away which policies would apply. This is a simplified view of the process:

flowchart TD
    Request["Sign-in request"] --> User["Choose user"]
    User --> App["Choose app"]
    App --> Location["Select location"]
    Location --> Device["Device status"]
    Device --> CA["Simulate CA policies"]
    CA --> Result["Policy result"]

Figure: How a Conditional Access simulation runs in the What-If tool in Entra ID.

Once several policies and exclusions come into play, this tool has saved me more troubleshooting hours than I can count.

I start simple and iterate deliberately

A mistake I see often is overengineering Conditional Access right away, or trying clever setups before the basics are in place. What works in practice is going in phases. First come admin MFA, the legacy auth block, MFA for all users and the break-glass accounts. Only then do I add risk-based and other policies, and I always use report-only mode and the What-If simulation to spot problems early. Above all, CA policies need ongoing care as part of your security posture. Review and adjust them regularly, because no tenant stays the same for long, and every new app, user or location gives attackers another opening.