CloudekMicrosoft Entra
Azure Multi-Factor Authentication (Microsoft Entra MFA): Methods and Setup
Azure MFA is now Microsoft Entra multifactor authentication. See how it works, which verification methods exist, how to enable it, and what to avoid.
Azure Multi-Factor Authentication (Microsoft Entra MFA): Methods and Setup
Originally published 4 October 2020 · Reviewed 5 November 2026
"Azure MFA" is now Microsoft Entra multifactor authentication. It adds a second check after the password, so a stolen or guessed password alone does not let someone in. This guide explains how it works, which methods exist, how to turn it on, and how to choose methods in 2026. Older tutorials use the Azure AD name and older portals, so treat their screens as a guide to the idea, not the clicks.
How it works
Strong authentication combines two or more kinds of proof: something you know (a password or PIN), something you have (a phone, a hardware key or a device with a stored credential), and something you are (a fingerprint or face). MFA asks for more than one kind, so an attacker who has only the password still fails.
Applications do not have to be changed. The challenge is part of the Microsoft Entra sign-in, which asks for MFA when policy requires it and passes the result back to the application. Whether a particular user is prompted depends on how you configured it, and it can depend on factors such as the application, the location, the device and the sign-in risk.
Methods and what they are for
Microsoft documents which methods can be used as the first factor, as a second factor for MFA, and for self-service password reset. In summary:
| Method | Typical use | Phishing-resistant? |
|---|---|---|
| Windows Hello for Business | Sign-in to Windows devices | Yes |
| Passkeys (FIDO2) and security keys | First factor and MFA | Yes |
| Passkey in Microsoft Authenticator | First factor and MFA | Yes |
| Certificate-based authentication | First factor and MFA | Yes |
| Microsoft Authenticator push approval | MFA and password reset | No |
| Software or hardware OATH codes | MFA | No |
| SMS and voice call | MFA and password reset | No |
| Temporary Access Pass | Short-lived sign-in and registration | Time-limited, not a permanent method |
Microsoft recommends the phishing-resistant methods because attackers now use real-time phishing proxies that capture a password and a one-time code together. SMS, voice and one-time codes are better than no MFA but are the first methods to retire when you can.
Ways to switch it on
Security defaults. The free tier includes security defaults, a Microsoft-managed baseline that requires MFA registration and prompts for MFA when needed. It is the right starting point for a small tenant that has nothing more specific.
Conditional Access. With Microsoft Entra ID P1, which is included in Microsoft 365 Business Premium and E3, you create policies such as "require multifactor authentication for administrators" or "for all users on all cloud apps with sensible exclusions". This is the approach to use once you need exceptions, named locations or device conditions. You cannot use security defaults and Conditional Access policies together, so switch security defaults off only when your policies are ready.
Per-user MFA. The older per-user enablement still exists, but Microsoft's guidance favours Conditional Access or security defaults, because they are easier to reason about and audit.
Registration and administration
Users register methods in the combined security information experience, where they can add the Authenticator app, a security key or a phone number. Administrators decide which methods are allowed in the Authentication methods policy, and can target methods to groups. Microsoft has been migrating the older, separate MFA and password reset policies into that single policy, so check the current Microsoft documentation if your tenant still shows legacy settings.
For people who lose a device, plan recovery before you need it: a Temporary Access Pass issued by a verified administrator, or a second registered method.
Approval prompts and number matching
Push approvals in Microsoft Authenticator are convenient, but a user can approve a prompt they did not start. Microsoft has made number matching the default for these approvals, so the user must type the number shown on the sign-in screen rather than tap approve. That helps against accidental approvals, but it does not make push approval phishing-resistant, so keep moving high-risk users towards passkeys or security keys.
Common mistakes
- Excluding too many accounts. A break-glass account needs protection too, usually a phishing-resistant method held offline.
- Allowing only SMS. Easy to deploy, but it is the weakest option and invites SIM-swap and phishing attacks.
- Forgetting service accounts and legacy protocols. MFA cannot be applied to protocols that do not support it. Block legacy authentication with Conditional Access instead.
- No registration plan. Switching on a requirement without telling users produces a day of help desk tickets. Announce it and offer a registration window.
- Treating MFA as finished. Review sign-in logs for MFA fatigue patterns, and move administrators to phishing-resistant methods first.
A sensible rollout
Start with administrators and break-glass accounts, then all staff, then guests. Use report-only mode for new Conditional Access policies first, read the sign-in logs for what would have been blocked, and enforce when the list of exceptions is short and documented. For each group, pick the strongest method that the devices can support, and set a date for retiring SMS and voice.
Microsoft references
- Microsoft Entra authentication methods, reviewed 5 November 2026.
- How Microsoft Entra multifactor authentication works, reviewed 5 November 2026.
- Microsoft Entra licensing, reviewed 5 November 2026.
This article was first published on 4 October 2020. It was rewritten on 5 November 2026 with current product names, methods and recommendations. Microsoft's live documentation takes precedence if it has changed.