Requiring MFA for all users is one of the most impactful things you can do to protect your Microsoft 365 environment. But that’s just a starting point. The real work starts when you need to handle the scenarios that every organization eventually runs into – legacy applications that cannot handle MFA, users signing in from different locations, administrators who need stricter controls, and the ever-present risk of locking yourself out of your own tenant.

This post and video cover three high-impact Conditional Access policies that every Microsoft Entra ID environment should have in place, along with the guardrails you need before things get more complex. If you are new to Conditional Access, this post is part of a multi-part series. The first part covers why passwords fail and how to enable Security Defaults. The second part walks through building your first Conditional Access policy from scratch. Please be sure to check out the previous parts if you are getting started with Entra ID Conditional Access.

The First Rule of Conditional Access – Never Lock Yourself Out

Before building any new policies, there is one thing every admin needs to set up first: a break-glass account. This is an emergency access account that is excluded from all Conditional Access policies and exists for one reason – getting back into your tenant when something goes wrong.

Think about this scenario. You create a policy that accidentally locks out all Global Administrators. You try to sign in to fix it, but you cannot because you are caught by the very policy you just created. Microsoft support can help in that situation, but the process may be slow and not something you want to rely on in an emergency. A properly configured break-glass account means that situation never happens.

It is not just bad policies you need to worry about either. Phones break. People leave organizaitons. Devices get lost. SIM swapping happens. Mobile carriers have outages. If your only admin access depends on an MFA method that relies on any of those things, you have risk. A break-glass account gives you a way back in regardless of what is happening with your MFA infrastructure.

How to Configure a Break-Glass Account Correctly

There are four rules for break-glass accounts that you need to follow to make them effective.

First, it should be a cloud-only account using the onmicrosoft.com domain. Do not tie it to a specific user and do not sync it from on-premises Active Directory. If your AD sync breaks or your on-premises environment goes down, a cloud-only account is still accessible. Also make sure the credentials do not expire.

Second, use a very long, complex password and store it securely offline. Not in a password manager tied to Microsoft MFA. If there is a problem with MFA, you may not be able to get into that vault to retrieve the password. A printed copy in a physical safe or secured with a trusted individual is the right approach. Microsoft also recommends using a FIDO2 passkey or certificate-based authentication on the break-glass account where possible, since Microsoft now enforces mandatory MFA for admin portals like the Entra ID and Azure portal.

Third, the account must be excluded from every Conditional Access policy in your tenant. Every single one. The “All users” assignment includes break-glass accounts, so you need to explicitly exclude it each time in every policy. One policy that catches the break-glass account defeats its entire purpose.

Fourth, monitor it. Set up an alert in Microsoft Sentinel, Entra ID Identity Protection, or another security tool so that any sign-in on the break-glass account triggers an immediate notification. If that account is being used, something has already gone wrong and you need to know immediately.

Microsoft recommends having at least two break-glass accounts in every tenant. Test the account after creating it to confirm it works correctly before you actually need it.

Policy 1 – Block Legacy Authentication

The highest-impact Conditional Access policy you can add after requiring MFA is blocking legacy authentication. This is not optional. If you leave legacy authentication enabled, attackers can bypass MFA entirely using older protocols that were built before MFA existed.

The fix is a Conditional Access policy that targets all users and all cloud apps, sets the client apps condition to legacy authentication clients, and blocks access completely. Before switching this policy from Report-Only to On, review the sign-in logs carefully. Some older line-of-business applications or shared mailboxes may still use legacy protocols and will need to be migrated before you enforce the block.

Policy 2 – Restrict Access by Named Location

Named locations let you define trusted networks in Entra ID and use them as a condition in Conditional Access policies. A common use case is requiring MFA only when users sign in from outside the corporate network, reducing friction for users already behind trusted infrastructure while enforcing MFA for everyone else.

To set this up you need the public IP address of your trusted network. You can get this by visiting a “what is my IP” website from inside your office network. Organizations with multiple office locations or dynamic IP ranges need to add all trusted addresses before enforcing the policy.

One important thing to understand is how multiple policies interact. If you have a broad “Require MFA for all users” policy enabled at the same time as a “Require MFA outside trusted network” policy, both will apply to users inside the corporate network and the MFA requirement will still apply. That is because when multiple Conditional Access controls apply to a sign-in, they are combined rather than one overriding the other.

The solution is to disable the broad policy and rely on the location-aware policy instead, since they are functionally identical except for the trusted location exclusion. The What If tool, covered below, is the best way to catch this kind of conflict before enforcement

Policy 3 – Stricter Controls for Privileged Accounts

Global Administrators, Security Administrators, Exchange Administrators, and other privileged roles are the highest-value targets in your tenant. If one of those accounts is compromised, the attacker has broad control over your environment. These accounts need stronger controls than standard users, and those controls should apply on every single sign-in regardless of location or device.

The policy targets specific directory roles rather than individual users, which means it automatically applies to anyone assigned one of those roles in the future. Microsoft’s managed Conditional Access policy for admin MFA covers 14 roles, which is a good baseline if you are not sure where to start. The access control is straightforward: require MFA on every sign-in with no location exclusions and no device-based exceptions.

Validating Policies with the What If Tool

Before enabling any policy, use the What If tool in Conditional Access to validate how your policies apply across different users and scenarios. This is a reliable way to catch misconfigurations before they affect real users.

The What If tool lets you specify a user, a target application, a device platform, a client app type, and an IP address, then shows you which policies would apply and what controls would be enforced. It tests against all policies in their current state, including Report-Only policies, so you get an accurate picture without impacting anyone.

Run through at different scenarios with multiple accounts before enabling any policy. Test a standard user signing in from a trusted location, the same user from an untrusted location, a user using a legacy authentication client, a privileged account signing in from a trusted location, and the break-glass account. That last test is critical. Confirming that no policies apply to the break-glass account is the final check before you start enforcing anything.

Moving from Report-Only to On

Once you have tested your policies with the What If tool and reviewed the sign-in logs for any unexpected traffic, you are ready to move policies from Report-Only to On. Do this one policy at a time rather than all at once, and give each policy time to generate sign-in data before enabling the next one. That approach makes it much easier to isolate the cause if something unexpected happens after enforcement.

Take Action Today

Blocking legacy authentication, restricting access by location, and applying stricter controls to privileged accounts are not advanced configurations reserved for large enterprises. They are the baseline that every Microsoft 365 organization should have in place. If any of these are missing from your tenant, the Entra ID portal gives you everything you need to build and test them safely before a single user is affected. Start with the break-glass account, work through the policies one at a time, and validate everything with the What If tool before you enforce anything.

Links:

A Beginner’s Guide to the AZ-900
https://www.udemy.com/course/beginners-guide-az-900/?referralCode=C74C266B74E837F86969

Zero to Hero with Azure Virtual Desktop
https://www.udemy.com/course/zero-to-hero-with-windows-virtual-desktop/?referralCode=B2FE49E6FCEE7A7EA8D4

Hybrid Identity with Windows AD and Azure AD
https://www.udemy.com/course/hybrid-identity-and-azure-active-directory/?referralCode=7F62C4C6FD05C73ACCC3

Windows 365 Enterprise and Intune Management
https://www.udemy.com/course/windows-365-enterprise-and-intune-management/?referralCode=4A1ED105341D0AA20D2E

VIDEO: Passwords Alone DON’T WORK! Secure M365/Azure with Entra ID MFA!

VIDEO: Master Conditional Access in Entra ID: Assignments, Conditions, Controls!

Require multifactor authentication for admins
https://learn.microsoft.com/en-us/entra/identity/conditional-access/managed-policies#require-multifactor-authentication-for-admins

Mandatory multifactor authentication for Azure and admin portals
https://learn.microsoft.com/en-us/entra/identity/authentication/concept-mandatory-multifactor-authentication?tabs=dotnet