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.

What MFA configuration methods are available in Microsoft 365?

Quick Answer: 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.

Security defaults vs Conditional Access: Which should I choose?

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

Quick Answer: Security defaults is the fastest way to enforce MFA across a Microsoft 365 tenant. It takes under five minutes and requires no per-user configuration.

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.

Prerequisites

Before enabling Security defaults, verify the following:

• Admin role: You have the Security Administrator role or higher

• No legacy authentication on admin accounts: Admin accounts are not using legacy authentication protocols

• Modern authentication enabled: Modern authentication is enabled in Exchange Online (tenants created before 2017 may have it disabled)

• App passwords configured: If any users rely on desktop apps requiring legacy authentication, app passwords are set up in advance

Enable Security defaults

Path: Microsoft Entra Admin Center → Identity → Overview → Properties → Manage security defaults

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 do I set up MFA using Conditional Access Policies in Microsoft 365?

Quick Answer: Conditional Access Policies provide the most granular MFA control in Microsoft 365, allowing rules based on user, device, location, or app—available on E3 and higher plans.

Conditional Access runs after first-factor authentication completes. It's available on Microsoft 365 E3, E5, F1, F3, F5, A3, and A5.

Prerequisites

Before creating Conditional Access Policies, verify the following:

• License: Microsoft 365 E3, E5, F1, F3, F5, A3, or A5

• Admin role: Conditional Access Administrator, Security Administrator, or Global Administrator

• Break-glass accounts: Dedicated emergency admin accounts identified for exclusion

• Security defaults disabled: Security defaults must be off (the two methods are mutually exclusive)

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

How do I create a Conditional Access Policy for MFA from scratch?

Path: Microsoft Entra Admin Center → Protection → Conditional Access → Create new policy

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.

Path for monitoring: Microsoft Entra Admin Center → 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 do I create an MFA Conditional Access Policy from a Microsoft template?

Path: Microsoft Entra Admin Center → Protection → Conditional Access → Create new policy from templates

Microsoft provides pre-built templates that cover the most common MFA scenarios. Search for "multifactor" to find relevant templates.

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.

What is legacy per-user MFA and how does it differ from Entra ID Protection?

Quick Answer: Legacy per-user MFA is deprecated and only useful for app passwords; Entra ID Protection adds risk-based MFA triggers on E5 plans and works best alongside Conditional Access.

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.

Path: Microsoft 365 Admin Center → Users → Active users → Multi-factor authentication

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.

Path: Microsoft Entra Admin Center → Protection → Identity Protection → Multifactor authentication registration policy

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.

Common errors and solutions

What should IT admins configure in Microsoft 365 after enabling MFA?

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.

How does centralized email signature management fit into Microsoft 365 governance?

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.

What are the next Microsoft 365 governance steps after enabling MFA?

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. Start a free trial today.