Turn on MFA for Microsoft 365 before the next phish

If your Microsoft 365 tenant still allows password-only sign-ins, you are one convincing phish away from a bad week. Multifactor authentication (MFA) will not stop every attack, but it stops the boring, common ones that still succeed against SMBs every day.

This tutorial is the “get it done safely” version, not a tour of every Conditional Access nuance.

1. Decide who goes first

Do not flip MFA on for the whole company in one click if nobody has enrolled a second factor yet.

Start with:

• Global admins and anyone with mailbox / SharePoint admin roles
• Finance and ownership accounts
• Then a friendly pilot group (IT-curious staff)
• Everyone else after you have a help-desk script

Write down who is in each wave and when you will move them.

2. Pick a default second factor

For most SMBs, the Microsoft Authenticator app is a workable starting default. SMS can work as a recovery method during a transition, but do not confuse either one with phishing-resistant authentication. Microsoft’s authentication-strength table reserves that stronger category for Windows Hello for Business or platform credentials, FIDO2 security keys, and certificate-based authentication.

Tell people ahead of time:

• Install Authenticator on their phone before the enforcement date
• Keep a backup method registered if they travel without that phone
• Who to call if they get locked out

3. Use Conditional Access (or Security Defaults) on purpose

If you are on a plan that supports Conditional Access, create a policy that requires MFA for all users, with only documented emergency-access exclusions.

If you are still on Security Defaults, turn them on and accept the lack of customization, then plan the move to Conditional Access when licensing and requirements justify it. Microsoft’s Microsoft 365 MFA setup guidance says Security Defaults is available with Entra ID Free, while Conditional Access requires Entra ID P1 or P2. Do not use legacy per-user MFA alongside Conditional Access.

Do not stop at one forgotten break-glass password. Microsoft’s current emergency-access guidance calls for at least two cloud-only accounts, phishing-resistant methods distinct from normal admin authentication, secure credential storage, monitoring, and a sign-in test at least every 90 days. Exclude the emergency group from Conditional Access policies that could block it.

4. Enforce in waves

1. Target admins first, while keeping the emergency accounts separate
2. For Conditional Access, begin in Report-only and inspect the sign-in results
3. Turn enforcement on for a friendly pilot group
4. Announce a hard date, then expand to everyone else
5. Clean up users who never registered and document recovery

Microsoft’s report-only documentation explains that the policy is evaluated without enforcement and records the result in the sign-in logs. Security Defaults is tenant-wide rather than group-targeted, so schedule that change with communications and live support instead of pretending it offers the same rollout controls.

Give people a real deadline. Soft “please enroll someday” requests are how password-only accounts survive into next year.

5. Validate before you celebrate

• Confirm a normal user can sign in with MFA on desktop and phone mail
• Confirm a blocked legacy protocol is actually blocked (or modernized)
• Confirm both emergency-access accounts still work and generate the expected monitoring signal
• Update your offboarding checklist so MFA methods get removed with the account

Bottom line

MFA is not optional hygiene anymore. Roll it out in waves, communicate clearly, protect and test emergency-access accounts, and verify real sign-ins, then keep an eye on the logs when someone new joins.