Microsoft Entra multifactor authentication is the method to deploy now, built around Microsoft Authenticator as the primary method, a backup method registered alongside it, and enforcement through Conditional Access where licensing allows, or security defaults for smaller tenants. Organisations still running legacy per-user MFA should treat migration to the unified Authentication methods policy as the next administrative task, since it governs registration and reduces long-term friction for users and IT teams alike.
TL;DR:
- Entra ID supports multiple MFA options, but organizations should prioritize Authenticator, FIDO2 keys, or Windows Hello for high security, avoiding SMS whenever possible.
- Transitioning to the unified authentication policy improves management and user experience, especially when migrating from legacy per-user MFA settings.
- Security defaults provide a quick, tenant-wide setup to block nearly all identity attacks, suitable for small organizations without complex policies, while Conditional Access offers more granular control.
- A phased rollout with small pilot groups, clear communication, and backup methods like Temporary Access Pass minimizes helpdesk workload and avoids user lockouts.
- Post-deployment issues mostly relate to registration, lost devices, or sign-in prompts, with logs helping troubleshoot and guide adjustments for ongoing security and usability.
Table of Contents
- Which authentication methods does Microsoft 365 support?
- Security defaults or Conditional Access: which fits your organisation?
- Authentication methods policy and migration checklist
- Designing a rollout that doesn’t overwhelm your helpdesk
- Troubleshooting MFA issues after go-live
- How we approach MFA deployments as a managed IT partner
- Get help rolling out MFA across your organisation
- Sources
- FAQ
Which authentication methods does Microsoft 365 support?
Microsoft Entra ID supports a range of methods, and they are not equally strong. Some resist phishing by design, others add a genuine second factor, and a couple exist mainly as fallbacks that should never carry the full weight of your security posture.
A deployment guide from Microsoft sets out the supported options and recommends enabling more than one per user so nobody gets locked out when a phone is lost or a token runs flat.
- Microsoft Authenticator: push approvals, OATH codes and passwordless sign-in, meeting NIST AAL2 and covering most day-to-day needs.
- FIDO2 security keys: physical hardware keys that resist phishing because the credential never leaves the device.
- Windows Hello for Business: biometric or PIN sign-in built into Windows, phishing-resistant and well suited to managed devices.
- OATH hardware tokens: time-based codes useful where a smartphone is not practical, such as shared workstations.
- SMS and voice calls: the weakest options, vulnerable to SIM-swap and interception, best reserved as a last-resort fallback rather than a primary method.
Passwordless sign-in through Authenticator or a FIDO2 key removes the password from the equation entirely, which is why Microsoft and most security teams now treat it as the preferred direction of travel rather than a second-factor add-on. For organisations weighing which methods to enable by default, the practical answer is Authenticator for the majority, FIDO2 or Windows Hello for high-privilege accounts, and SMS switched off wherever an alternative exists.
Security defaults or Conditional Access: which fits your organisation?
Security defaults switch on tenant-wide protection in a few clicks: every user registers for MFA, administrators face stricter requirements, and legacy authentication protocols are blocked. Microsoft reports that MFA blocks over 99.2% of identity-based attacks, and the same guidance confirms that newly created tenants no longer get a grace period before registration is enforced, a change Microsoft made deliberately to close the window attackers were exploiting.
Conditional Access does more, but it demands more too. Rather than a single on/off switch, it lets you build policies that respond to signal: block sign-ins from unfamiliar countries, require a compliant device for finance staff, or step up authentication only when Entra ID Protection flags a session as risky.
- Security defaults suit small tenants with no dedicated IT policy team and a need for fast, baseline protection.
- Conditional Access suits organisations that need different rules for different roles, devices or locations.
- Entra ID Protection adds risk-based sign-in evaluation but requires Microsoft Entra ID P2.
Licensing shapes the choice. Conditional Access itself requires Microsoft Entra ID P1 or Microsoft 365 Business Premium, while risk-based policies need P2. As a rule of thumb, start with security defaults if you are under fifty seats with no compliance obligation forcing granularity, and move to Conditional Access as soon as you need to treat an admin account differently from a front-desk login.
Pro Tip: If your organisation lacks a dedicated policy team, Microsoft’s managed Conditional Access templates replicate common protections without requiring you to write policies from scratch.
Authentication methods policy and migration checklist
Legacy per-user MFA and the old SSPR method settings are being retired in favour of a single Authentication methods policy, found under Entra ID > Authentication methods in the Microsoft Entra admin centre. According to Microsoft’s deployment guidance, consolidating methods here improves administration and cuts the friction users feel when registration rules live in two separate places.
- Audit existing settings: document who is enrolled in legacy per-user MFA and which SSPR methods are active before touching anything.
- Map legacy methods to the new policy: identify which groups need Authenticator, FIDO2, or OATH tokens enabled by default.
- Run the migration wizard: Microsoft’s migration guide walks through moving settings across in a process that stays reversible until you finalise it.
- Pilot with a small group: test sign-in, registration and recovery flows before wider exposure.
- Adjust exclusions and group scoping: limit weaker methods such as SMS to a small, named group rather than the whole tenant.
- Complete the migration and retire legacy policies: once the pilot confirms stability, switch off the old per-user MFA settings entirely.
Verify that Microsoft Authenticator, OATH tokens, FIDO2 and Temporary Access Pass are each configured correctly before you close out the migration, since a gap in any one of them is what tends to generate helpdesk calls in week one.
Designing a rollout that doesn’t overwhelm your helpdesk
A rollout succeeds or fails on pacing, not on policy wording. Start with a pilot group that represents your real population: a mix of office-based staff, remote workers and at least one person on an older device, so you find the awkward cases before everyone else does.
- Size each wave to your support capacity: a helpdesk that handles ten tickets a day should not register five hundred users on day one.
- Use registration policies or interactive prompts to guide people through setup rather than relying on an email nobody reads.
- Issue a Temporary Access Pass for users who cannot register immediately, so a delayed onboarding never turns into an account lockout.
- Require a backup method at registration, not as an afterthought, since a single-method user is one lost phone away from being unable to sign in.
Communication matters as much as configuration. A short guide with screenshots, a named contact for registration problems and a clear recovery process will cut support tickets more than any policy tweak.
Pro Tip: Schedule registration waves for mid-morning rather than Monday first thing, when the helpdesk is already absorbing the week’s backlog.
Troubleshooting MFA issues after go-live
Most post-deployment problems fall into a handful of patterns, and the sign-in logs in the Microsoft Entra admin centre are the first place to look. They show which Conditional Access policy applied, which method was attempted and why a sign-in was blocked or challenged.
- Registration failures: usually a browser or time-sync issue, resolved by re-running setup on a different device.
- Lost or stolen device: revoke the user’s sessions, reset their registered methods and issue a Temporary Access Pass to re-register.
- MFA fatigue from repeated prompts: review Conditional Access session controls and sign-in frequency settings rather than disabling MFA.
- Legacy on-premises or RADIUS applications: the NPS extension bridges RADIUS to Microsoft Entra MFA, though migrating the application to a modern protocol such as SAML or OpenID Connect is the better long-term fix, as Microsoft’s guidance notes.
How we approach MFA deployments as a managed IT partner
MFA policy design is rarely the hard part. Getting a pilot group through registration without flooding the helpdesk, keeping backup methods consistent across departments and migrating legacy settings without a gap in coverage is where most of the real work sits. A managed IT partner typically handles that end of a deployment directly: scoping the policy, running the pilot, and staying available while waves roll out. If your organisation would rather hand the migration and rollout to a team that has done it before, that is exactly the kind of project we take on.
— Carl
Get help rolling out MFA across your organisation
Planning a migration, piloting a rollout and keeping a helpdesk ready for registration week take time most internal IT teams do not have spare. Our managed services plans cover ongoing monitoring and support once MFA is live, and our Microsoft 365 migration team can scope and run the deployment itself.
Get in touch for a scoping call and we will map out a pilot sized to your organisation before anyone registers a single device.
FAQ
Is MFA required for Microsoft 365?
Microsoft does not force every existing tenant to enable MFA, but security defaults require registration automatically on new tenants, and Microsoft strongly recommends it for every organisation given that MFA blocks over 99.2% of identity-based attacks. Most administrators enforce it through security defaults or Conditional Access rather than leaving it optional.
How do I set up MFA in Office 365?
Enable it through the Microsoft Entra admin centre under Entra ID > Authentication methods, where you configure which methods such as Microsoft Authenticator or FIDO2 are available, then enforce registration with security defaults or a Conditional Access policy. Users then register their chosen method and a backup method the next time they sign in.
How do I know if MFA is enabled in Office 365?
Check the Authentication methods policy and Conditional Access policies in the Microsoft Entra admin centre to see which methods and enforcement rules are active. The sign-in logs also show whether MFA was required and which method a user completed for each sign-in attempt.
How do I set up two-factor authentication for my Microsoft 365 account?
Sign in to your account and follow the prompt to register a method, typically installing Microsoft Authenticator on your phone and scanning a QR code. Registering a second method, such as an OATH token or a phone number as backup, avoids being locked out if your primary device is unavailable.