Enable Office 365 MFA now: turn on security defaults for a fast baseline, or move straight to Conditional Access if you hold Entra ID P1/P2 licensing and need granular control by user, app, or risk level. Per-user MFA still exists in the admin centre, but Microsoft no longer recommends it for anything beyond a temporary fix. Whichever path you pick, start with Microsoft’s official setup documentation rather than piecing it together from forum posts.
- Fastest option: security defaults, free on every tenant, on or off with no exceptions
- Best long-term option: Conditional Access, needs Entra ID P1/P2 or Business Premium/E3/E5
- Legacy option: per-user MFA, fine for a single stopgap account, not a rollout strategy
Key Takeaways
Office 365 MFA works best when admins match the configuration method (security defaults, Conditional Access, or per-user MFA) to their licence tier and exception needs, then prioritise phishing-resistant methods over SMS.
| Point | Details |
|---|---|
| Choose the right path | Use security defaults for a fast, free baseline; use Conditional Access when you need exceptions and hold Entra ID P1/P2 licensing. |
| Never skip emergency accounts | Set up at least two break-glass accounts excluded from all policies before enforcing anything tenant-wide. |
| Test before enforcing | Run new Conditional Access policies in report-only mode first to catch misconfigurations before real users are affected. |
| Upgrade factor quality | Move default registration away from SMS toward Authenticator push with number matching or passkeys. |
| Bring in support when it’s complex | Techbug manages MFA rollouts, Conditional Access design, and staff training for businesses that want the process handled properly. |
Table of Contents
- Before you enable MFA for Microsoft 365: roles, licences, and planning
- Security defaults vs Conditional Access vs per-user MFA: which should you use?
- How do you turn on security defaults in Microsoft 365?
- How do you set up Conditional Access for MFA in Microsoft 365?
- How do you enable per-user MFA for a single Office 365 account?
- How do users register for MFA and which method should they choose?
- Which MFA methods are actually phishing resistant?
- How do you check MFA registration and fix common rollout problems?
- What does a practical MFA rollout checklist look like?
- What admins get wrong about MFA rollouts
- Get MFA rolled out without the trial and error
- Sources
Before you enable MFA for Microsoft 365: roles, licences, and planning
Getting this wrong usually means a locked-out admin at 7am, not a security breach. Sort the groundwork first.
You need a Global Administrator or Conditional Access Administrator role to build policies, and Security Administrator access is enough for monitoring and reporting once policies exist. Licensing decides how far you can go: security defaults ships free with every Microsoft 365 plan, but Conditional Access requires Entra ID P1 or P2, bundled into Microsoft 365 Business Premium and most E3/E5 plans.
- Confirm which admin roles are assigned before touching any MFA setting
- Check your tenant’s licence tier against Conditional Access requirements
- Decide now whether you’ll need exceptions for service accounts or legacy apps, because that choice determines whether security defaults is even viable
- Note the mandatory MFA enforcement timeline Microsoft has already started rolling out for admin centre access
Security defaults vs Conditional Access vs per-user MFA: which should you use?
Security defaults is a single switch. Flip it on and Microsoft enforces MFA for every user, blocks legacy authentication protocols outright, and requires admins to register a second factor immediately. Microsoft documents this as the baseline option for tenants with no existing Conditional Access setup, and for a small business with straightforward needs, it genuinely does the job.
Conditional Access is where things get interesting. Instead of one blanket rule, you write policies keyed to user groups, sign-in risk, device compliance, location, or application. Want finance staff to hit MFA on every login but let a compliant, enrolled laptop skip the prompt on the corporate network? That’s a Conditional Access policy, not something security defaults can do. The trade-off is licensing cost and setup time, and Microsoft’s own guidance is blunt about the fact that security defaults is all-or-nothing, so admins who enable it early often have to switch it off later to build proper Conditional Access rules.
Per-user MFA sits at the bottom of the list for good reason. Microsoft still lists it as one of three supported methods, but it doesn’t integrate with Conditional Access, can’t apply conditional logic, and becomes an administrative headache past a handful of users.
- Security defaults: fast, free, no exceptions, blocks legacy auth outright
- Conditional Access: granular, requires P1/P2, supports exceptions and risk-based rules
- Per-user MFA: manual, per-account, no scalability, useful only as a stopgap
Pro Tip: Decide your exception strategy before you flip any switch. If you already know a legacy line-of-business app can’t handle modern authentication, security defaults will break it on day one with zero warning.
How do you turn on security defaults in Microsoft 365?
If you want MFA live today with minimal fuss, this is the path.
- Sign in to the Microsoft Entra admin centre as a Global Administrator.
- Go to Identity > Overview > Properties.
- Select Manage security defaults at the bottom of the page.
- Toggle Enable Security Defaults to Yes and save.
That’s the entire configuration. Microsoft flips MFA on for every user in the tenant within minutes, and legacy authentication protocols (POP, IMAP, older SMTP clients) get blocked immediately.
Users will not be locked out instantly. Microsoft applies a grace period during which unregistered users can still sign in, but they get nagged to register a method at every login until they do. Expect a spike in helpdesk questions in the first 48 hours as staff work through the Authenticator app prompt for the first time. That’s normal, and it’s smaller than most admins expect if you send a heads-up email before flipping the switch rather than after.
Before you enable it, run through this checklist:
- Identify legacy apps still using basic authentication (older scanners, some accounting software, on-premises Exchange connectors) — these will break the moment security defaults blocks legacy auth.
- Check service accounts and shared mailboxes. They can’t complete an MFA prompt, so they need either exclusion via Conditional Access (not available under security defaults) or a switch to modern app passwords where the vendor supports it.
- Warn your team with a short internal notice a day or two ahead, including a link to the Microsoft registration walkthrough.
Pro Tip: Security defaults gives you zero exceptions. If even one account genuinely can’t do MFA yet, that’s your signal to skip security defaults and go straight to Conditional Access instead.
How do you set up Conditional Access for MFA in Microsoft 365?
Moving to Conditional Access means rebuilding, not just adding. Security defaults and Conditional Access can’t run side by side cleanly, so the first step is disabling security defaults, because leaving both active creates conflicting rules that are hard to audit.
- Turn off security defaults in Entra ID > Properties > Manage security defaults.
- Recreate the baseline using Microsoft’s Conditional Access templates: require MFA for all users, require MFA for administrators, and block legacy authentication. Microsoft’s own guidance stresses rebuilding this enforced baseline first before layering on custom policies, otherwise you leave gaps where the old blanket protection used to sit.
- Set up at least two emergency access accounts, excluded from every Conditional Access policy, with long random passwords stored offline. These are your break-glass accounts if a policy misfires and locks out every admin simultaneously.
- Build your custom policies for specific groups, apps, or risk conditions once the baseline is solid.
- Run everything in report-only mode first. This shows you exactly who would be blocked or prompted without actually enforcing anything, which catches misconfigurations before they lock out real users.
Pro Tip: Never skip report-only testing on a new policy, even one you’re confident about. It’s the difference between finding a mistake in a report and finding it in forty angry Teams messages.
How do you enable per-user MFA for a single Office 365 account?
Sometimes you just need one account covered today, without a full rollout. Per-user MFA still handles that, even though it’s not built for scale.
- Go to the Microsoft 365 admin centre > Active users, select the user, and choose Manage multifactor authentication.
- Tick the account and click Enable in the per-user MFA panel.
- The user will be prompted to register a method on their next sign-in.
It doesn’t sync with Conditional Access policies and offers no conditional logic, location awareness, or risk scoring. Treat it as a stopgap for a single contractor or a new hire on their first day, not a security strategy.
How do users register for MFA and which method should they choose?
Once MFA is enforced, users hit a setup prompt on their next sign-in, and the flow is largely the same whether it’s triggered by security defaults or a Conditional Access policy.
- The user signs in as normal and is redirected to More information required.
- They select Microsoft Authenticator as their method (the default recommendation) and scan a QR code shown on screen to link the app.
- Alternatives include a phone call or SMS code, a TOTP code from any compatible authenticator app, or a passkey on supported devices.
- Once registered, they confirm a test push notification or code, and setup is complete.
Users manage their registered methods anytime through My Sign-Ins > Security info at myaccount.microsoft.com, where they can add a backup method, change their default, or remove an old device. Point your helpdesk staff at this page first when someone calls about a lost phone. It’s usually faster than raising an admin ticket.
Push through Microsoft Authenticator with number matching is the method to steer people toward by default, with a passkey as the strongest option on devices that support it. SMS should sit at the bottom of the list, offered only as a fallback. Microsoft’s own security guidance points to enabling MFA as one of the single biggest defensive moves a tenant can make, blocking the vast majority of automated account compromise attempts compared with password-only sign-in.
Which MFA methods are actually phishing resistant?
Counting factors matters less than checking their quality. Two weak factors together can still fail against a well-run phishing kit; one strong factor, like a passkey bound to a specific device, resists the same attack outright. Security researchers now frame this explicitly as a factor-quality problem rather than a factor-count one, and it’s the right lens for admins choosing defaults.
Ranked roughly by phishing resistance:
- Passkeys / FIDO2 keys: cryptographically bound to the device and site, effectively immune to credential phishing
- Authenticator push with number matching: strong, blocks most automated attacks, some social-engineering risk remains
- TOTP codes: decent, but codes can be phished in real time by a sufficiently patient attacker
- SMS one-time codes: weakest option, vulnerable to SIM swapping and no longer meets NIST AAL2 guidance for high-assurance sign-in
Pro Tip: If your organisation is still defaulting new hires to SMS because it’s familiar, that’s the single easiest upgrade to make this quarter. Switch the default method to Authenticator push and reserve SMS for people without a smartphone.
For a deeper look at where single sign-on fits alongside MFA rather than replacing it, this comparison of SSO and MFA is worth a read before you finalise your identity stack.
How do you check MFA registration and fix common rollout problems?
Once policies are live, verification is an ongoing job, not a one-off task.
- Check registration status in the Entra admin centre under Identity > Monitoring & health > Authentication methods activity, which shows who has registered and who hasn’t.
- Review sign-in logs through My Sign-Ins or the admin centre’s sign-in reports to spot repeated MFA failures, which often point to a misconfigured device or an expired app registration rather than a real attack.
- Recover locked-out users through self-service password reset combined with a temporary access pass, issued by an admin, that lets them register a new method without a permanent password.
- Fall back to a break-glass account if the locked-out user is an admin and no other admin account is available.
- Handle legacy apps that can’t prompt for MFA by issuing an app password or, better, migrating the app to modern authentication where the vendor supports it.
What does a practical MFA rollout checklist look like?
A clean rollout follows a sequence, not a single big-bang switch.
- Pick a pilot group of 10 to 20 users across different roles before touching the whole tenant
- Send a short, plain-language notice explaining what will change and where to get help
- Set up emergency access accounts and confirm they work before enforcing anything
- Run new Conditional Access policies in report-only mode for at least a week
- Move from pilot to staged rollout by department, then to full enforcement
- Give helpdesk staff a simple triage script: lost device → temporary access pass; wrong method registered → guide to Security info page; repeated failures → check sign-in logs before assuming user error
- Escalate to managed IT support when legacy app compatibility or Conditional Access policy conflicts go beyond routine troubleshooting
What admins get wrong about MFA rollouts
Most guidance treats MFA as a checkbox: switch it on, tell everyone, move on. That’s how you get a flood of helpdesk tickets and a handful of furious department heads who lost access mid-meeting. The rollout sequence matters more than the technology choice. A well-planned per-user stopgap beats a rushed, tenant-wide Conditional Access policy pushed live without report-only testing.
The bigger blind spot is factor quality. Plenty of businesses treat “MFA is on” as the finish line and leave SMS as the default method because it’s what staff already know. That’s a lower bar than it looks. SMS is the weakest link in the chain, and leaving it as the default rather than the fallback undermines a lot of the protection MFA is meant to deliver in the first place.
If there’s one thing worth prioritising over everything else in this guide, it’s emergency access accounts. Skip the pilot group if you must, rush the staff communication if you have to, but never enable a tenant-wide policy without at least two break-glass accounts tested and ready. That single step is what separates a rollout with a rough morning from one with a locked-out business.
Get MFA rolled out without the trial and error
Rolling out MFA properly across a real business, with legacy apps, shared mailboxes, and staff who’ve never touched an authenticator app, takes more coordination than a single afternoon of admin-centre clicking. Techbug runs managed MFA rollouts for small and medium businesses, handling the Conditional Access policy design, the emergency access accounts, and the staff communication so nothing gets missed and nobody gets locked out on a Monday morning.
Techbug’s team builds the pilot-to-enforcement staging most businesses skip, tests legacy app compatibility before it becomes a support ticket, and trains your staff on the registration flow so your helpdesk isn’t fielding the same three questions all week. That’s the difference between an MFA rollout that sticks and one that gets rolled back after the first bad afternoon. If you’re weighing up whether to handle this in-house or bring in support, start with a chat about Techbug’s IT security services or take a look at the broader managed IT services available for Brisbane and Australian SMBs to see what a fully managed setup looks like for your team.
Sources
- Set up multifactor authentication for Microsoft 365
- MFA vs 2FA: Are They the Same Thing? (CIAM Compass)