Enable MFA for Microsoft 365 now, using Security defaults if your tenant is small and needs baseline protection, or Conditional Access if you need granular rules and licensing supports it. Multifactor authentication makes an account more than 99.9% less likely to be compromised than a password alone. Making the switch requires Global Administrator or Conditional Access Administrator rights.
TL;DR:
- Security defaults automatically enforce MFA registration, block legacy authentication, and require admin MFA, protected by the free Entra ID free license.
- Conditional Access offers targeted, risk-based MFA rules for specific apps, device states, location, and admin roles, requiring P1 or P2 licenses.
- Transitioning from security defaults to Conditional Access demands careful planning, including license checks, emergency accounts, and staged policy deployment.
- MFA methods vary in security strength, with hardware keys and passkeys suitable for high-risk users, while SMS is least secure.
- Regular monitoring of sign-in logs and threat signals is essential to ensure MFA is properly functioning and to detect potential compromises.
Table of Contents
- Which Approach Fits Your Tenant: Security Defaults or Conditional Access?
- What Do Security Defaults Actually Enforce?
- Why Move to Conditional Access for MFA?
- How Do You Switch From Security Defaults to Conditional Access?
- Which Authentication Methods Should You Actually Use?
- What About Legacy Per-User MFA and Older Apps?
- What Does a Safe MFA Rollout Plan Look Like?
- How Does User Registration Work, and What Causes Lockouts?
- What Are the Best Practices for Configuring MFA Policies?
- How Does MFA Work With Third-Party Apps and Services?
- How Do You Monitor MFA Usage and Catch Security Incidents?
- What Happens When a User Loses Their MFA Device?
- Does MFA Work the Same Across Devices and Apps?
- The Practical Pitfalls We See Most in MFA Rollouts
- How 247Techify Helps You Roll Out MFA Without the Guesswork
- Sources
- FAQ
Which Approach Fits Your Tenant: Security Defaults or Conditional Access?
The decision usually comes down to how much control you need over who gets challenged, when, and how.
Stick with Security defaults if:
- You run a small or mid-size organization without a dedicated IT security team
- You are not licensed for Microsoft Entra ID P1 or P2
- You want baseline MFA enforcement with zero configuration overhead
Move to Conditional Access if:
- You need to target specific apps, groups, or device compliance states
- You want risk-based or location-based sign-in rules
- You need to enforce phishing-resistant methods for admins while allowing simpler methods elsewhere
Licensing draws the line here. Security defaults ship free with Microsoft Entra ID Free, included in every Microsoft 365 subscription. Conditional Access requires Entra ID P1 or P2, which comes bundled with Microsoft 365 E3 and E5 respectively, or as a standalone add-on.
What Do Security Defaults Actually Enforce?
Security defaults are Microsoft’s opinionated, no-configuration answer to “just turn on MFA.” Organizations created after October 2019 typically have them switched on automatically, which means a fair number of admins are already protected without realizing it.
Once active, Security defaults enforce three things:
- Mandatory MFA registration for every user, typically within a 14-day grace window before enforcement kicks in.
- Blocked legacy authentication protocols (like POP, IMAP, and older SMTP clients) that cannot support modern MFA challenges.
- Required MFA for all admin roles, including Global Administrator, on every sign-in.
To check or enable this setting, go to the Microsoft Entra admin center, navigate to Identity > Overview > Properties, then select Manage security defaults.
Pro Tip: If you inherited a tenant and aren’t sure what’s active, check this setting before touching anything else. A surprising number of security gaps trace back to an admin who assumed Security defaults were on when they’d been manually disabled years earlier.
Why Move to Conditional Access for MFA?
Conditional Access exists because Security defaults treat every user the same way. That works fine for a five-person shop. It breaks down fast once you have contractors, multiple offices, or a compliance auditor asking why the finance team and the intern get identical sign-in requirements.
Conditional Access lets you build rules around:
- Specific applications or resources (require MFA for Exchange Online but not a low-risk internal app)
- Device compliance state (block sign-in from unmanaged or unpatched devices)
- Location and network (challenge sign-ins from outside expected countries)
- Sign-in and user risk signals from Microsoft Entra ID Protection
The real power comes from authentication strengths, a Conditional Access feature that lets you require a specific class of verification rather than just “any MFA method.” You can mandate phishing-resistant authentication (FIDO2 keys, certificate-based auth) for administrators while permitting standard multifactor methods for general staff.
Given that MFA alone cuts compromise likelihood by more than 99.9%, layering authentication strength requirements on top for your highest-risk accounts closes the remaining gap that basic push notifications leave open.
This requires Entra ID P1 or P2. A common setup: standard MFA for general staff, phishing-resistant methods for admins, and a separate policy for external contractors accessing SharePoint but nothing else.
How Do You Switch From Security Defaults to Conditional Access?
Switching without a plan is how tenants end up locked out at 2 a.m. Follow this order.
- Confirm licensing. Verify you hold Entra ID P1/P2 for everyone who needs a Conditional Access policy applied.
- Create emergency access accounts. Set up at least two break-glass admin accounts excluded from every new policy, with credentials stored offline.
- Recreate the baseline in report-only mode. Build Conditional Access policies that mirror what Security defaults already enforced: MFA for all users, MFA for all admins, blocked legacy auth.
- Review report-only sign-in logs for a week to confirm no legitimate user gets unexpectedly blocked.
- Turn off Security defaults, then switch your new policies from report-only to on, one at a time.
Pro Tip: Never disable Security defaults before your replacement policies are enabled and tested. There should be no gap where neither system is enforcing MFA. For a deeper breakdown of policy templates, see this guide to core Conditional Access policies.
Which Authentication Methods Should You Actually Use?
Not every verification method carries the same security weight, and treating them as interchangeable is a mistake many admins make early on.
- Microsoft Authenticator app: push notifications and passwordless sign-in, solid for most staff.
- Passkeys and FIDO2 hardware keys: phishing-resistant, best reserved for admins and finance roles.
- Windows Hello for Business: biometric or PIN sign-in tied to the device, good for managed corporate laptops.
- SMS and voice calls: convenient but the weakest option, vulnerable to SIM-swapping.
- OATH hardware tokens: useful for users without smartphones or in environments where phones aren’t allowed.
MFA is a security process, not a single product. Microsoft Authenticator is one tool within that process, not a synonym for MFA itself, which matters when a user asks “do I have to install the app?” The honest answer is no, provided another registered method is available.
Pro Tip: Use authentication strengths to enforce phishing-resistant methods only for privileged roles. Forcing hardware keys on every employee creates friction that drives support tickets without a proportional security gain for low-risk accounts.
What About Legacy Per-User MFA and Older Apps?
Per-user MFA is the original, account-by-account MFA toggle in Microsoft 365, and it’s a maintenance headache at any scale. Each user sits in one of three states: Disabled, Enabled, or Enforced, and someone has to manage that per person as staff join and leave.
Microsoft’s own guidance treats it as a last resort, with Security defaults or Conditional Access as the preferred organizational controls. If Conditional Access policies are active, they generally override per-user settings anyway, making the legacy toggle redundant noise.
For old line-of-business apps that can’t handle modern auth:
- Generate app passwords as a temporary bridge
- Push vendors toward modern authentication support
- Exclude the app cautiously, and only with compensating network controls
What Does a Safe MFA Rollout Plan Look Like?
Rushing enforcement across an entire company on a Monday morning is how helpdesk queues explode by lunch. A phased plan avoids that.
Before you touch a single policy:
- Inventory every privileged account, service account, and legacy application still using basic auth.
- Confirm at least two emergency access accounts exist and are excluded from all policies.
- Choose a pilot group, usually IT staff plus one willing business unit.
Rollout sequence:
- Week 1: Communicate the change, registration deadline, and support contact to the pilot group.
- Week 2: Enable policies in report-only mode, review sign-in logs daily.
- Week 3: Switch pilot group to enforced, monitor helpdesk tickets closely.
- Weeks 4 to 6: Roll out to remaining departments in waves, largest or most complex team last.
Give users a heads-up well before the 14-day registration window starts counting down, since anyone who ignores the registration prompt risks getting locked out on the deadline.
Pro Tip: Brief your helpdesk before rollout, not during. Give them a one-page script for “I can’t sign in” tickets: verify identity, check registration status, issue a temporary access pass if needed. If device compliance factors into your policies, this BYOD control checklist is worth reviewing alongside your rollout.
How Does User Registration Work, and What Causes Lockouts?
When MFA enforcement activates, whether through Security defaults or a Conditional Access policy, unregistered users hit a registration prompt at their next sign-in. They pick a method, typically the Authenticator app, verify it, and continue to their session. Under Security defaults, that grace period runs 14 days from a user’s first sign-in after enforcement begins, giving latecomers a buffer instead of an instant block.
Most lockout tickets trace back to a handful of predictable causes. A user registers a phone number, then switches carriers and loses the SIM without updating their method. Someone registers Authenticator on a personal phone, then that phone gets replaced or wiped before they add a new device. An admin account without a break-glass alternative gets locked out because the only registered method requires that same admin to fix it, which is exactly why emergency access accounts exist as a category unto themselves.
A few troubleshooting steps solve most tickets:
- Check registration status first. In the Microsoft Entra admin center, under Users > Per-user MFA or the Authentication methods report, confirm which method the user actually has registered.
- Issue a Temporary Access Pass for users who are locked out with no working method, giving them a time-limited code to sign in and register a new method.
- Verify the account isn’t excluded from an intended policy, which sometimes explains why someone bypasses a prompt they should be seeing.
- Confirm the 14-day window hasn’t expired before assuming a technical failure. Sometimes the system is working exactly as designed.
Document every override in a change log. When an auditor eventually asks why an account was excluded from MFA for three weeks, “we forgot” is a far worse answer than a dated, reasoned entry.
What Are the Best Practices for Configuring MFA Policies?
The biggest mistake admins make with MFA policy configuration is treating every account the same. A receptionist and a Global Administrator do not carry equal risk, and policies that ignore that distinction either overprotect low-risk users into frustration or underprotect high-risk ones into disaster.
Segment policies by role. General staff get standard multifactor methods, Authenticator push or SMS as a fallback. Admins and finance approvers get authentication strengths configured for phishing-resistant methods only. External contractors get scoped Conditional Access policies limited to the specific apps they touch, nothing more.
Exclude sparingly, and never permanently. Every exclusion should have an expiration date or a scheduled review, whether it’s a legacy app awaiting a vendor update or a temporary contractor account. An exclusion with no review date has a way of outliving the reason it was created.
Test in report-only mode before enforcing anything new. This applies to policy changes months after initial rollout just as much as it did during deployment, since business needs and app inventories shift.
Balance friction against risk tolerance. Requiring re-authentication every four hours on a trusted, compliant device is often overkill; requiring it for sign-ins from unfamiliar countries is not. Sign-in frequency and persistent browser session settings inside Conditional Access let you tune that dial precisely instead of applying one blunt setting to everyone.
Finally, revisit policies quarterly. Staff turnover, new SaaS integrations, and shifting compliance requirements mean a policy set that made sense in January can have real gaps by summer.
How Does MFA Work With Third-Party Apps and Services?
Most organizations connect dozens of third-party services to Microsoft 365 through OAuth app registrations, Azure AD SSO, or SAML federation, and MFA enforcement needs to account for every one of them, not just Outlook and Teams.
When a third-party app authenticates through Microsoft Entra ID using modern authentication, it inherits whatever Conditional Access policy applies to the signed-in user for that resource. A CRM tool using SSO against Microsoft 365, for instance, can be targeted directly in a Conditional Access policy scoped to “cloud apps,” letting you require MFA for that specific integration without touching every other app in the tenant.
The friction point is older third-party tools that still rely on basic authentication or legacy protocols like IMAP and POP3. These cannot process an MFA challenge at all, they either work with a static credential or they fail outright, which is exactly why blocking legacy authentication is one of the core protections Security defaults enforces from day one.
For apps that support modern auth but weren’t built with Conditional Access in mind, check the app registration’s required permissions and confirm it’s listed under Enterprise applications in the Entra admin center. From there, you can scope policies to that specific app, exclude it temporarily while testing, or require a higher authentication strength for anyone accessing sensitive data through it.
Service accounts and API-based integrations deserve separate handling entirely. These non-interactive identities can’t complete an MFA prompt, so they typically need conditional exclusions paired with alternative controls like restricting sign-in to specific IP ranges or using certificate-based authentication instead of a password.
How Do You Monitor MFA Usage and Catch Security Incidents?
Enabling MFA is the easy part. Knowing whether it’s actually working requires watching the right reports.
The Sign-in logs in the Microsoft Entra admin center show every authentication attempt, which Conditional Access policy applied, and whether MFA was satisfied, skipped, or failed. Filter by “Conditional Access” status to spot policies that aren’t firing as expected.
The Authentication methods activity report shows registration trends across the organization, useful for tracking whether your rollout is actually landing or whether a department is quietly ignoring registration prompts.
For threat detection, Microsoft Entra ID Protection (bundled with P2 licensing) flags risky sign-ins, atypical travel, and leaked credentials, then can trigger automatic MFA challenges or block sign-in outright based on risk score. This is where Conditional Access earns its keep over Security defaults. Risk-based policies adapt in real time instead of applying a static rule to everyone equally.
Set up alerts for a few specific patterns: repeated MFA failures from a single account (a sign of an attacker probing stolen credentials), sign-ins from impossible travel locations, and any change to Conditional Access policies themselves, since a disabled policy is one of the first things an attacker tries after compromising an admin account.
What Happens When a User Loses Their MFA Device?
A lost or replaced phone is the single most common MFA support request, and having a clear procedure beats improvising one at 4 p.m. on a Friday.
The fastest fix is a Temporary Access Pass, a time-limited code an admin generates that lets the user sign in without their usual method and register a new one. This is the recommended path over disabling MFA entirely for that account, even temporarily, since a disabled account is an open door until someone remembers to re-enable it.
If a user has multiple registered methods, which is worth encouraging during onboarding, they can simply fall back to a secondary method like a backup phone number or a second Authenticator installation while sorting out the primary device.
For admin accounts specifically, this is exactly why emergency access accounts exist as a permanent fixture, not a one-time setup step. If a Global Administrator loses their device and their backup method fails, a break-glass account excluded from MFA policies is the only way in without a support call to Microsoft.
Before restoring access, verify identity through a second channel, a phone call to a known number or confirmation from a manager, especially for finance or admin roles where a convincing social engineering attempt could otherwise walk right through your helpdesk.
Does MFA Work the Same Across Devices and Apps?
MFA enforcement doesn’t look identical on every platform, and that inconsistency trips up admins who assume one test on a Windows laptop covers every scenario.
Modern desktop Office apps (Outlook, Word, Excel on current versions) handle MFA prompts natively through the Microsoft identity platform, with no special configuration needed beyond standard tenant setup. Mobile apps for iOS and Android generally behave the same way, though push notifications through Authenticator work more reliably than SMS on some carrier networks.
Older Office clients and any app still using Basic Authentication cannot process an MFA challenge, which is precisely why blocking legacy auth is one of the three protections Security defaults enforces by default. If your organization still runs Office 2013 or earlier, or legacy line-of-business software hardcoded to basic auth, budget time to migrate those clients before enforcing MFA broadly, not after.
Browser-based access to Outlook Web App or SharePoint Online respects Conditional Access session controls, including sign-in frequency settings, meaning a user might get re-prompted more often in a browser than in the desktop Outlook client depending on how your persistent browser session policy is configured.
One compatibility issue worth flagging for shared or kiosk devices: Windows Hello for Business ties to a specific device and user profile, so it’s a poor fit for shared workstations. Authenticator push or a hardware token generally works better in that scenario.
The Practical Pitfalls We See Most in MFA Rollouts
The rollouts that go sideways almost always skip the same two steps: emergency access accounts and report-only validation. Skip either one and your one policy typo away from a company-wide lockout.
Legacy apps and incomplete user registration cause most support tickets. Give registration a real deadline with reminders, and inventory every legacy client before enforcement, not after the tickets start.
For admin and finance roles, phishing-resistant methods aren’t optional. A push notification stops casual attacks. It doesn’t stop a targeted one.
**
How 247Techify Helps You Roll Out MFA Without the Guesswork
247Techify is the practical alternative to figuring this out solo. As a managed IT provider built around a cybersecurity-first approach for Canadian businesses, 247Techify handles the parts of an MFA rollout where most in-house teams get stuck: designing Conditional Access policies that match your actual risk profile, mapping authentication strengths to admin versus staff accounts, and setting up emergency access accounts correctly before anything goes live.
For organizations in healthcare, finance, or other regulated industries, that also means configuring MFA in a way that holds up under HIPAA or PCI-DSS review, not just passing a basic security checklist. With 24/7 support and a response time under 30 minutes, 247Techify catches lockout issues and policy misconfigurations before they turn into a helpdesk backlog. Explore managed IT services built around this exact approach, or reach out to get a Conditional Access rollout plan scoped to your tenant.
Sources
- How effective is multifactor authentication at deterring cyberattacks? (Microsoft Research)
- Multifactor authentication for Microsoft 365 - Microsoft 365 admin | Microsoft Learn
FAQ
How do I enable MFA for my Microsoft 365 account?
Go to the Microsoft Entra admin center, select Identity > Overview > Properties, then turn on Security defaults for baseline enforcement, or build a Conditional Access policy if you hold Entra ID P1/P2 licensing.
How do I enable multifactor authentication per user in Microsoft 365?
Navigate to Users > Per-user MFA in the Entra admin center and set the individual’s state to Enabled or Enforced, though Microsoft recommends Security defaults or Conditional Access over this legacy method for organization-wide control.
Is MFA the same as Microsoft Authenticator?
No. MFA is the broader security process of requiring a second verification factor, while Microsoft Authenticator is one recommended tool among several options, including passkeys, SMS, and hardware tokens.
What is Microsoft 365 multifactor authentication?
It’s a sign-in requirement that adds a second verification step beyond a password, and it makes an account more than 99.9% less likely to be compromised than a password alone.
Do I need a paid license to use MFA for Microsoft 365?
No. Basic MFA through Security defaults is included free with every Microsoft 365 subscription via Entra ID Free; only granular Conditional Access controls require P1 or P2 licensing.