Multi-Factor Authentication (MFA) Options for Microsoft: What You Need to Know

Multi-Factor Authentication (MFA) requires two or more verification factors before granting access — something you know (password/PIN), something you have (phone, security token), and something you are (biometrics). Combining factors means a stolen password alone isn’t enough to get in.

In this post: Why it matters · Before you set it up · Not all MFA is equal: authentication strengths · When would you actually use this? · Best practices · References · Related reading

Why it matters

A stolen password alone no longer gets an attacker in — they’d also need the second factor.
It cuts the effectiveness of phishing and brute-force attacks, since there’s a second barrier beyond the password.
Many regulations (GDPR, HIPAA, ISO 27001) require it for compliance.
It protects the obvious targets — email, documents, customer data — from unauthorized access even after credentials leak.

Before you set it up

Microsoft Entra ID P1 or P2 (formerly branded Azure AD Premium), or a Microsoft 365 license that includes it — E3/E5, or Business Premium.
Conditional Access Administrator or Global Administrator permissions to create and enforce policies.
End-user devices that can actually receive the verification (smartphone for push notifications, or a hardware token).
A backup authentication method configured for each user, in case the primary one fails.

Worth flagging directly: older guides (including earlier versions of this one) show enabling MFA per-user via the MSOnline module’s Set-MsolUser -StrongAuthenticationRequirements. Both are gone now — the MSOnline module hit end-of-support in mid-2025, and Microsoft has separately deprecated the legacy per-user MFA policy itself in favor of Conditional Access, which gives far more control (which apps, which risk conditions, which user groups) than the old all-or-nothing per-user toggle ever did. The current, correct path is a Conditional Access policy via the Microsoft Graph PowerShell SDK:

Connect-MgGraph -Scopes "Policy.ReadWrite.ConditionalAccess"

$params = @{
    DisplayName = "Require MFA for all users"
    State = "enabledForReportingButNotEnforced"   # flip to "enabled" after piloting
    Conditions = @{
        Users = @{ IncludeUsers = @("All") }
        Applications = @{ IncludeApplications = @("All") }
    }
    GrantControls = @{
        Operator = "OR"
        BuiltInControls = @("mfa")
    }
}
New-MgIdentityConditionalAccessPolicy -BodyParameter $params

Starting in report-only mode and reviewing sign-in logs before flipping to enabled is the difference between catching a scoping mistake in a report and locking out your whole organization at 5pm on a Friday.

Not all MFA is equal: authentication strengths

The Conditional Access policy above treats every second factor as equally good — SMS, a phone call, a push notification, and a FIDO2 security key all satisfy BuiltInControls = @("mfa") identically. That’s a real gap: adversary-in-the-middle (AiTM) phishing kits, already referenced in the Best Practices section below for push-bombing, can also relay a one-time SMS code or a push approval in real time against a fake login page. They can’t relay a cryptographic key exchange, which is exactly why phishing-resistant methods exist as a separate, stronger tier rather than just “more MFA.”

Authentication strengths (a Conditional Access grant control, distinct from the plain “Require multifactor authentication” control used above) let you require a specific tier of method rather than any second factor at all. Microsoft ships three built-in strengths:

Multifactor authentication strength — the same set of combinations “Require multifactor authentication” already accepts, including password + SMS/voice/push.
Passwordless MFA strength — Authenticator phone sign-in, Windows Hello for Business, or a FIDO2 key. No password step at all.
Phishing-resistant MFA strength — narrowed to just three: a FIDO2 security key, Windows Hello for Business (or platform credential), and certificate-based authentication (multifactor). Each requires a direct cryptographic interaction between the credential and the exact site being signed into, which is what makes a relayed phishing page unable to satisfy it.

The practical move for most tenants isn’t switching everyone to phishing-resistant MFA overnight — it’s scoping a second Conditional Access policy with the Require authentication strength grant control (set to Phishing-resistant MFA) at Global Administrator and other privileged roles specifically, while everyone else stays on the standard MFA policy. One real limitation worth knowing before building this: Require multifactor authentication and Require authentication strength can’t be combined as two grant controls inside the same policy — they need to be separate policies scoped to different user groups or apps. Query the built-in strengths first to get the policy IDs your automation needs to reference:

Connect-MgGraph -Scopes "Policy.Read.All"

# List the built-in authentication strength policies and their IDs
Invoke-MgGraphRequest -Method GET `
    -Uri "https://graph.microsoft.com/beta/identity/conditionalAccess/authenticationStrength/policies?`$filter=policyType eq 'builtIn'"

Rolling this out to admin roles specifically is worth doing sooner rather than later — it’s become one of the most-recommended, least-adopted Entra changes tenants haven’t made yet, and it’s also showing up as a hard requirement from third-party platforms: Salesforce, for one, now requires phishing-resistant MFA specifically for privileged users connecting from Entra-federated tenants.

A stolen password alone no longer gets an attacker in — they would also need the second factor.

When would you actually use this?

You just onboarded a new admin account and want it protected from day one — privileged accounts are the highest-value target, enforce MFA there first.
You’re seeing repeated failed sign-in attempts in the audit log — MFA is the single control that neutralizes most credential-stuffing attempts.
You need guest/external accounts in SharePoint or Teams to meet the same bar as internal users — MFA extends through Azure AD B2B.
Legacy apps in your environment don’t support MFA natively — app passwords are the workaround, but they’re also a gap worth tracking (see Best Practices below).

Best practices

Use Conditional Access, not a blanket policy: require MFA for external logins or sensitive operations, not every low-risk sign-in.
Cover admin accounts first: they’re the highest-value target.
Offer more than one method: phone call, SMS, and an authenticator app, so one lost device doesn’t lock someone out.
Track app-password usage: legacy apps that can’t support MFA directly need app passwords instead — know where those exist since they’re a weaker fallback.
Watch for MFA fatigue: users who reflexively approve push notifications without checking them are a real attack vector (adversary-in-the-middle push-bombing). Train for it.

See also: Multi-Factor Authentication (MFA): What You Need to Know for the broader concept beyond just the Microsoft implementation.

References

Utilizing Identity Secure Score in M365 Admin Center — MFA coverage is one of the biggest levers on this score; worth checking after you’ve rolled MFA out.

That’s it for this one. Questions? Leave a comment and I’ll get back to you.