Every Microsoft 365 tenant I have been handed as a new IT admin had one of two security postures: Security Defaults enabled and nothing else, or Security Defaults disabled with a sprawl of ad-hoc exceptions someone added "temporarily" years ago. Neither is a real security posture. The fix is Conditional Access (CA), Microsoft's policy engine in Entra ID for controlling who signs in, from where, on what device, and with what level of authentication. Here is where I start, every time, in every tenant.
Before Any Policy: Create Your Break-Glass Accounts
This step is not optional and is the one most teams skip. Before you create a single Conditional Access policy, you need two emergency access accounts, often called break-glass accounts. These are the accounts that can still sign in even if every CA policy fires at once and locks everyone else out.
Why two? Because if one credential is lost or compromised, the second gives you recovery. Microsoft's own guidance recommends two, and I have never found a reason to argue with that.
How to set them up:
- Create two new user accounts in Entra ID with Global Administrator role
- Use long, randomly generated passwords (store them offline, not in a password manager that requires a Microsoft login to access)
- Make these accounts cloud-only, not synced from an on-premises Active Directory
- Do not require MFA on these accounts. The whole point is they work when everything else fails.
- Exclude both accounts from every CA policy you ever create. Name them clearly so future admins know not to delete them.
- Set up a sign-in alert for these accounts. They should never be used in normal operation. An alert means something has gone badly wrong.
Once you have break-glass accounts in place, you can create CA policies with confidence. If you lock yourself out, you have a recovery path.
Policy 1: Require MFA for All Users
This is the foundation. Every cloud identity in your tenant should prove they control a second factor before accessing anything in Microsoft 365.
In the Entra admin center, go to Protection, then Conditional Access, and create a new policy. Set it to apply to all users, exclude your two break-glass accounts, apply to all cloud apps, and set the grant control to require multi-factor authentication. That is it for the basic version.
Before you enable it live, set the policy to Report-only mode. Report-only does not block anything. It records what would have happened in your sign-in logs. Run it for 7 to 14 days and review the logs to find anything that would break. Then enable the policy for real.
What counts as MFA here: Microsoft Authenticator push notifications, a TOTP authenticator app, FIDO2 security keys, or Windows Hello for Business. SMS-based verification is technically a second factor but is the weakest option. I push teams toward Authenticator or a hardware key whenever possible.
The most common thing that breaks this policy: service accounts used for application integrations or email alerts that authenticate interactively with a username and password. The fix is to convert those to app registrations with client credentials, which do not require user MFA. Find these in your report-only logs before you go live.
Policy 2: Block Legacy Authentication
Legacy authentication covers the old protocols that cannot perform modern MFA: SMTP Auth (used by some printers, scanners, and line-of-business apps), IMAP, POP3, and older Outlook clients that rely on basic authentication. These protocols pass credentials directly to Microsoft's servers with no way to present a second factor. If an attacker has stolen or guessed a password, legacy auth is their easiest path in.
Microsoft has published analysis showing that the large majority of password-spray and credential-stuffing attacks target legacy auth endpoints specifically. Blocking it removes that surface area for every account in your tenant at once.
Create a new CA policy. Apply it to all users, exclude your break-glass accounts, cover all cloud apps, and under Client apps conditions, check both "Exchange ActiveSync clients" and "Other clients." Set the grant control to Block access.
Again, run it in Report-only mode first and check your logs carefully. Look for anything using legacy auth. In almost every tenant I have worked on, there are two or three surprises: a network printer, a shared scanner, or an old CRM integration sending mail via SMTP Auth with basic credentials. Fix those devices before you enable the policy by migrating them to OAuth or app passwords for devices that genuinely cannot support modern authentication. Then enable the block.
The week you spend in Report-only mode will save you a very unhappy weekend. Blocking legacy auth is the highest-impact policy in this list, and the one most likely to surface a device you forgot existed.
Policy 3: Extra Controls for Admin Roles
Admin accounts are the highest-value targets in any Microsoft 365 tenant. A compromised global admin account lets an attacker create new accounts, exfiltrate mail, disable security policies, and access every file in SharePoint and OneDrive. Even with Policy 1 already requiring MFA for everyone, admin roles deserve a tighter set of controls.
Create a third CA policy scoped to directory roles: Global Administrator, Exchange Administrator, SharePoint Administrator, Security Administrator, and any other admin roles active in your tenant. Under session controls, set two things:
- Sign-in frequency: 1 hour. This means an admin session token expires after an hour of inactivity, rather than lasting days or weeks as a cached browser session.
- Persistent browser session: disabled. This forces admins to re-authenticate every time they open a new browser session, rather than staying signed in across restarts.
If your organization uses Microsoft Intune for device management, you can add a grant control requiring a compliant device for admin sign-ins. This ensures that even a stolen admin credential cannot be used from an unmanaged machine. If you are not yet on Intune, the session controls above are still a meaningful upgrade on their own.
The Rollout Order That Does Not Break Production
Communicate with your users before Policy 1 goes live. People who have never been prompted for MFA will be surprised when it starts happening. A short heads-up email, a note in your IT newsletter, or a Slack message a few days before the switch turns a confusion-driven help desk spike into a non-event. I always send two messages: one a week out saying MFA is coming, and one the morning of the change with a link to setup instructions.
What This Looked Like at Scale
When I ran this rollout at a large international NGO covering 300 staff across 31 counties, the environment had been running on Security Defaults with a handful of informal exceptions for two years. The report-only phase surfaced three surprises: two network scanners using SMTP Auth with basic credentials, and a third-party HR system that was pulling calendar data via an old IMAP connection. All three had fixes: the scanners moved to app passwords, the HR system vendor updated their integration to use OAuth within a week of being told it was required.
After going live, unexpected sign-in attempts from locations outside our operational footprint dropped to near zero within 60 days. In the six months before the rollout, we had two confirmed account compromises. In the six months after, zero. The entire rollout from creating break-glass accounts to having all three policies live took three weeks, most of which was the report-only observation period.
One Important Note: Security Defaults vs. Conditional Access
Security Defaults and Conditional Access cannot run together. If Security Defaults are enabled, CA policies are disabled. Before you create your first policy, go to Entra ID Properties, find Security Defaults, and turn them off. This surprises a lot of new Entra admins who assume you can layer the two. You cannot. The moment you move to CA, you own the full baseline, which is exactly why these three policies matter.
Start Here
If you are managing an M365 tenant on Security Defaults or no CA policies at all, these three close the biggest gaps with the least disruption. Run everything in report-only first, fix what the logs surface, then go live. If you want to talk through the right approach for your licensing tier or device setup, reach out.
Comments