Azure MFA: Methods, Policies and Safer Sign-In

Azure MFA in brief

For a Microsoft 365 MFA setup, choose security defaults or Conditional Access first. Security defaults provide a baseline with Microsoft Entra ID Free; Conditional Access policies require Microsoft Entra ID P1 or P2 (or a plan that includes the required entitlement). P2 is needed for risk-based policies through Entra ID Protection, not for every MFA deployment. Choose the policy approach, allowed authentication methods and recovery process as separate decisions. Microsoft recommends security defaults or Conditional Access over legacy per-user MFA.

This guide explains those choices, then looks more closely at phishing-resistant MFA and why stronger sign-in methods still need safe fallback and account recovery.

You enabled MFA. An employee approved a sign-in. Someone else still got into the account. How?

That is a frightening helpdesk ticket, but it does not mean multifactor authentication is pointless. It means the type of MFA, the sign-in journey, and the session that follows all matter.

For an everyday IT engineer, the useful question is simple: are we checking the person only, or also the website they are signing into?

The fake reception desk problem

Imagine a visitor arriving at a fake reception desk. The receptionist quietly passes the visitor's details to the real office, relays its questions, and receives the entry pass. The visitor sees familiar questions and assumes everything is normal.

A fake sign-in intermediary can create a similar problem. Some attacks relay a real sign-in and obtain the resulting session cookie: the browser's temporary proof that authentication already happened. Microsoft has documented this adversary-in-the-middle phishing pattern.

Picture the risky path: Employee → fake sign-in intermediary → real service. The employee completes a phishable challenge; the intermediary may capture the session. This is a conceptual diagram, not a claim that every suspicious page behaves this way.

Keep MFA. Upgrade the question

MFA still adds valuable protection. CISA recommends using it and explains why organizations should move toward phishing-resistant authentication.

An SMS code, a copied one-time code, an approval notification, and a FIDO2 passkey are not interchangeable. Number matching can improve push approval, but it does not make that method phishing-resistant.

Do not respond to this risk by turning MFA off. Ask which methods people can actually use, including recovery and fallback routes. A strong default with an easy weaker alternative deserves a closer look.

Azure MFA now means Microsoft Entra MFA

Microsoft renamed Azure Active Directory to Microsoft Entra ID. The sign-in capability is now described as Microsoft Entra multifactor authentication (MFA). The underlying decisions are still practical: which verification methods are allowed, which users and applications are covered, what a policy requires, and how someone safely recovers access.

Microsoft lists methods including Microsoft Authenticator, passkeys and FIDO2 security keys, Windows Hello for Business, OATH tokens, SMS and voice calls. Availability depends on the method policy, licensing, device support and tenant configuration. A user registering a method does not by itself mean every sign-in requires that method. Check both the methods users can register and the control that enforces MFA.

Choose the MFA policy path before changing settings

Microsoft documents three broad options for Microsoft 365: security defaults, Conditional Access, and legacy per-user MFA. Security defaults are available with Microsoft Entra ID Free and provide a baseline with limited customization. Conditional Access is available with Microsoft Entra ID P1 or a plan that includes it; it lets administrators define more specific user, app and sign-in conditions. Microsoft describes per-user MFA as a legacy option and recommends security defaults or Conditional Access instead.

Microsoft Entra ID P2 is not required simply to ask users for MFA or to use ordinary Conditional Access. P2 adds capabilities such as risk-based policies through Microsoft Entra ID Protection and Privileged Identity Management. Verify the exact SKU and entitlement before relying on any feature; plans and bundles change over time.

Before switching from security defaults to Conditional Access, inventory current settings and plan replacement policies. Microsoft documents security defaults and Conditional Access as alternative approaches. Do not disable security defaults unless you are ready to switch to Conditional Access; prepare replacement policies, exclusions and recovery paths first, then test them before broad enforcement.

A safer rollout checklist

1. Record the tenant's current MFA approach, licensed plans, enabled methods and policy owners.
2. Identify emergency-access accounts and test their recovery process without exposing credentials in notes or tickets.
3. Review who and what each policy covers, including exclusions, report-only policies and legacy authentication dependencies.
4. Pilot the intended methods with representative users, devices and support scenarios before broad enforcement.
5. Check sign-in results and support issues, document exceptions with an owner, and only then decide whether to expand.

Phishing resistance is one part of the choice. It does not remove the need to manage fallback methods, recovery, compromised devices or active sessions.

Why a passkey changes the picture

A passkey uses cryptographic credentials rather than asking you to type a reusable secret into a page. Supported passkeys can live on devices or FIDO2 security keys; the appropriate choice depends on your organization's requirements.

The important idea is origin binding. A credential created for the real service is not simply handed to a lookalike website. The browser and authentication system check the website context. Microsoft's passkey explanation describes this origin-bound design and the role of a device PIN or biometric unlock.

Think of it as an entry badge that checks the building, too. That addresses a particular phishing weakness; it is not a promise that an account can never be compromised. A compromised device, unsafe recovery process, or stolen session needs separate attention.

Your next team meeting: five useful questions

• Which administrators still rely on SMS, codes, or ordinary push approvals?
• Can those accounts use an approved passkey or FIDO2 security key?
• Do policies require the stronger method, or merely allow it?
• How do we verify someone before replacing a lost device or registering a new method?
• Who owns sign-in alerts and the response to suspected session theft?

Start with a small, authorized pilot. Include someone who travels, someone using a shared workstation, and a helpdesk colleague. Test normal sign-in, a lost device, and recovery before broad rollout.

The sentence worth sharing

“MFA enabled” is a starting point. “Which method, which fallback, and which recovery process?” is the better review.

If someone already approved a suspicious sign-in, report it through your incident process promptly. Give the responder the time and the service involved. Do not assume changing a password alone resolves an active session incident.

You do not need to become a cryptographer to improve this. Make the sign-in method visible, make recovery deliberate, and give your team a clear next step.

Sources

Checked 5 November 2026. Licensing, product names and supported methods can change; confirm current Microsoft documentation for the tenant and plans in scope.

• Set up multifactor authentication for users in Microsoft 365
• Microsoft Entra multifactor authentication overview
• Microsoft Entra licensing
• Microsoft Entra ID Protection