How to set up multifactor authentication in Microsoft 365: A complete guide for IT admins

Microsoft has been making MFA mandatory across its admin tools since 2024. The Azure portal went first, then the Microsoft 365 admin center, then Azure CLI and PowerShell. Tenants without MFA on privileged accounts now face access blocks.

This guide walks through every method available in Microsoft 365: what each one does, how to configure it, who it suits, and how to deploy it without locking yourself out of your own tenant. The last section covers what to plan for once MFA is in place.

The four ways to configure MFA in Microsoft 365

Microsoft 365 supports four MFA configuration methods: Security defaults, Conditional Access Policies, Microsoft Entra ID Protection, and legacy per-user MFA. License tier and the level of control required determine which one fits.

Three rules apply before picking one:

• Security defaults and Conditional Access Policies are mutually exclusive. A tenant runs one or the other, never both.

• Legacy per-user MFA overrides modern methods. If a user has MFA enabled via the legacy portal, that setting takes precedence. Security defaults and Conditional Access will show as “Disabled” for that user. This is expected behavior.

• Conditional Access is the path forward for any tenant on E3 or higher. Security defaults work for everyone else. Legacy per-user MFA is on Microsoft's deprecation list, and Entra ID Protection only makes sense on E5 with risk-based signals already in use.

How to enable Security defaults in Microsoft 365

Security defaults are the fastest way to enforce MFA across a Microsoft 365 tenant. They apply organization-wide, require no per-user setup, and are available on every plan.

With Security defaults enabled:

• All users register for MFA using either the Microsoft Authenticator app or a physical FIDO2 security key.

• Legacy authentication protocols are blocked across the tenant.

• Admin accounts require MFA on every sign-in.

Before you enable

Two checks first:

• No admin accounts are using legacy authentication. These get blocked the moment Security defaults turns on, which can cut admin access to scripts and older clients.

• Modern authentication is enabled in Exchange Online. Tenants created before 2017 have it disabled by default. Enabling Security defaults without it causes a login loop.

If any users rely on desktop apps that require legacy authentication, set up app passwords for them in advance.

Enable Security defaults

The account performing this needs the Security Administrator role or higher.

1. Sign in to the Microsoft Entra Admin Center.

2. Go to Overview > Properties.

3. Under Security defaults, click Manage security defaults.

4. Select Enabled from the dropdown.

5. Click Save.

MFA is now enforced. Users will be prompted to configure it on their next sign-in.

Force re-authentication across the tenant

If MFA adoption is slow, revoke existing sign-in tokens to force every user to re-authenticate. Run this in PowerShell after enabling Security defaults:

Connect-MgGraph -Scopes 'User.ReadWrite.All' $users = Get-MgUser -All | Select-Object -Property Id foreach ($user in $users) {Revoke-MgUserSignInSession -UserId $user.Id}

The script signs every user out of every Microsoft 365 service. Their next sign-in triggers MFA setup.

How to set up MFA with Conditional Access Policies

Conditional Access Policies are rules that evaluate every sign-in and decide whether to allow, block, or require additional authentication based on user, device, location, or app. They offer the most granular MFA control available in Microsoft 365.

Conditional Access runs after first-factor authentication completes. It's available on Microsoft 365 E3, E5, F1, F3, F5, A3, and A5. The admin configuring it needs the Conditional Access Administrator, Security Administrator, or Global Administrator role.

There are two ways to create an MFA-focused Conditional Access Policy: from scratch, or from one of Microsoft's pre-built templates.

How to create a Conditional Access Policy from scratch

In the Microsoft Entra admin center, go to Protection > Conditional Access > Create new policy. The minimum setup for an MFA policy includes:

1. Name. Give the policy a clear, descriptive name.
   
   

2. Users. Define who the policy applies to. Include all users, or scope to specific groups, directory roles, or guest accounts. Exclude break-glass admin accounts here to avoid locking yourself out.
   
   

3. Target resources. Choose All cloud apps to cover everything or Select apps to scope the policy to specific Microsoft 365 and third-party apps.
   
   

4. Grant. Click Grant access, select Require multifactor authentication, then Select.
   
   

5. Enable policy. Set this to Report-only first. The policy runs but doesn't enforce, so you can see its effect before turning it on.

Monitor the policy through Protection > Conditional Access > Sign-in logs. Once confident, switch Enable policy to On.

Add conditions for more granular control

Four conditions worth knowing for MFA policies:

• Locations. Allow sign-in from specific countries or IP ranges only. Build in exclusions for business travel and VPN endpoints.

• Filter for devices. Allow sign-in only from devices matching specific DeviceID, DisplayName, EnrollmentProfileName, Manufacturer, or Model values.

• Require device to be marked as compliant. If the tenant uses Microsoft Intune compliance policies, restrict sign-in to devices that meet policy.

• Sign-in frequency. Force users to re-authenticate at a set interval, such as every 24 hours or every 14 days, instead of relying on long-lived session tokens.

How to create a Conditional Access Policy from a template

Microsoft provides pre-built templates that cover the most common MFA scenarios. From Conditional Access, select Create new policy from templates and search for “multifactor.”

Larger companies and enterprises should consider the following template-based policies:

• Require multifactor authentication for admins. Applies MFA to every directory role with admin privileges.

• Require multifactor authentication for all users. Applies MFA to every user account in the tenant.

• Block legacy authentication. Blocks legacy protocols across the tenant.

Every template-based policy excludes the admin creating it by default, as a lock-out safeguard. Once the policy is verified working, the creating admin can be added back to the user scope.

A note on legacy per-user MFA and Microsoft Entra ID Protection

Two MFA methods exist outside the main configuration paths: legacy per-user MFA and Microsoft Entra ID Protection. Most admins won't pick either as their primary method, but both come up enough to be worth a quick note.

Legacy per-user MFA is the original method, configured through the Microsoft 365 admin center under Users > Active users > Multi-factor authentication. Microsoft recommends against using it and has flagged it for deprecation. The only scenario where it's still useful is legacy desktop apps that need app passwords. If nothing in the tenant requires that, leave it alone.

Microsoft Entra ID Protection is a risk-based authentication feature on E5, F5, and A5 plans. It detects suspicious sign-ins (anonymous IPs, leaked credentials, unusual locations) and can require MFA registration when risk is detected. Configure it through Protection > Identity Protection > Multifactor authentication registration policy in the Microsoft Entra admin center. Entra ID Protection works best alongside Conditional Access Policies, not instead of them. The two are complementary: Entra ID Protection detects risk, Conditional Access acts on it.

What to harden after MFA: the rest of your Microsoft 365 governance picture

MFA secures who gets into Microsoft 365. It doesn't address what those authenticated users send out from it. Once identity is centralized, the governance gap most IT teams face next sits at the email layer: signatures, disclaimers, and brand consistency across every mailbox in the tenant.

MFA is part of a broader shift in Microsoft 365 administration. Identity controls are being centralized. Admin actions are being logged, audit trails are being standardized, and most of the governance picture is moving from end-user discretion to IT-controlled policy.

The email layer underneath that picture is mostly still manual. Exclaimer's State of Business Email 2025 report found that 83% of organizations have experienced email-related security incidents, and 48% experienced one in the past year.

In addition, 92% of business leaders agree that consistent, well-managed email signatures build trust and professionalism. But 80% still rely on manual methods, and only 18% use centralized email signature management. The IT teams now configuring MFA are often the same teams handling this email layer one signature at a time. 35% of IT teams name email signature management as one of their most time-consuming tasks.

Where centralized email signature management fits

Centralized email signature management gives IT a single platform to control email signature templates, branding, disclaimers, and audience rules across the organization, rather than relying on each user to configure their own.

Exclaimer created the first email signature software in 2001 and is now used by 80,000+ organizations worldwide. The difference it makes in a Microsoft 365 tenant where every other governance layer is already centralized is mostly about closing the last gap.

Here’s how centralized management measures up against native Microsoft 365 signature controls:

The new Outlook for Windows adds urgency. Microsoft has moved signature settings to the cloud and removed the COM add-in and Group Policy hooks that older signature deployment tools relied on. The client-side methods built around the classic Outlook stop working in the new client. For IT teams already auditing their Microsoft 365 environment for MFA, the email signature layer is the next item on the list.

The bottom line for IT teams

MFA is the front door of Microsoft 365 governance, not the whole of it. With identity controls centralized and admin actions logged, the email layer underneath is the next thing worth standardizing on the same terms.

Most of the manual work and most of the brand and compliance gaps in Microsoft 365 still sit at the email layer. For IT teams already centralizing identity, signatures are the obvious next item to bring under the same kind of control.

If you're working through Microsoft 365 governance after MFA, Exclaimer's cloud solution keeps email signatures and disclaimers consistent and on-brand, across every email client and device.