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 · When would you actually use this? · Best practices · References


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
  1. Microsoft Entra ID P1 or P2 (formerly branded Azure AD Premium), or a Microsoft 365 license that includes it — E3/E5, or Business Premium.
  2. Conditional Access Administrator or Global Administrator permissions to create and enforce policies.
  3. End-user devices that can actually receive the verification (smartphone for push notifications, or a hardware token).
  4. 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.


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

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


App Catalog Authentication Automation Backup Compliance Content Type CSS Flows Google Javascript Limitations List Metadata MFA Microsoft Node NodeJs O365 OneDrive Permissions PnP PnPJS Policy PowerApps Power Automate PowerAutomate PowerPlatform PowerShell React ReactJs Rest API Rest Endpoint Security Send an HTTP Request to SharePoint SharePoint SharePoint List SharePoint Modern SharePoint Online SPFX SPO Sync Tags Teams Termstore Versioning

Leave a Comment

Your email address will not be published. Required fields are marked *