🔐🧑💼AMP - Authentication Methods
What this policy is about 🔐
Authentication Methods is the velvet rope at the front of every sign-in. Every CA, every password reset, every MFA prompt, every TAP issuance — they all walk past this policy and show ID. Get the bouncer list wrong and the rest of your identity stack is choreography for nobody. 🎭
If a Conditional Access rule says "require MFA", this policy decides what counts as MFA. If your CA says "require Phishing-Resistant", this is the policy that needs to have FIDO2 / Passkey enabled or the CA does nothing. ⚡
CAs lean on it. Identity Protection leans on it. Self-Service Password Reset leans on it. Get this wrong and your Conditional Access stack is a very expensive screensaver. 🖥️
Why this matters 🎭
Somewhere in 2024 Microsoft quietly retired the old "MFA service settings" page, swept whatever toggles a tenant had into the modern policy, and left. A lot of MKB tenants got auto-migrated with the lights still on, the doors still unlocked, and SMS still ticked. Microsoft calls that the default. We call it Tuesday's incident ticket. 🚨
The default state has SMS enabled. Voice call enabled. Email OTP enabled. None of those are real MFA in 2026. They're phish bait with a check mark next to "MFA". 📧🎣
The job of this policy is two-fold:
- Turn off the cheap-to-bypass methods. SMS, voice, email OTP. Done.
- Turn on the strong methods, with the right per-method settings. FIDO2 with attestation. Passkey via Authenticator. Push notifications with number matching and location context. TAP for onboarding.
Once that's in place, every Conditional Access policy can confidently say "MFA" or "Phishing-Resistant" and mean the same thing across the whole tenant.
🛠️ Configuration Settings
Configured under Entra admin center → Protection → Authentication methods → Policies. Tenant-wide.
Methods to disable
| Method | Enable for | Why disable |
|---|---|---|
| SMS | Nobody | Phishable. SIM-swap vulnerable. Not real MFA in 2026. |
| Voice call | Nobody | Same problems as SMS, slightly worse latency. |
| Email OTP | Nobody | Email is also where password reset tokens go. Circular. Phishable. |
| Hardware OATH token | Nobody | Almost nobody in MKB owns these. If a customer does, scope per-tenant. |
| Third-party software OATH (Google Authenticator, Authy) | Nobody (with caveat below) | Doesn't support number matching, doesn't support location/app context. Microsoft Authenticator is the canonical app. |
Third-party OATH caveat. Some users will resist installing Microsoft Authenticator and want to use Google Authenticator or 1Password or whatever they already have. The technically-correct answer is "no". The operationally-pragmatic answer is "fine, but it doesn't satisfy Phishing-Resistant MFA, so the CAs for admin work will not let them in." Make the user understand the trade. Then they install Authenticator anyway.
Methods to enable
| Method | Enable for | Per-method config |
|---|---|---|
| Microsoft Authenticator (Push) | All users | Allow passwordless sign-in: On. Require number matching: On. Show app name in push: On. Show geographic location: On. |
| FIDO2 Security Key | All users | Enforce attestation: On. Allow self-service set up: On. Restrict specific keys: Off (unless customer has a vendor preference; YubiKey-only is a defensible MKB choice). |
| Passkey (FIDO2) | All users | Inherits FIDO2 attestation setting. Phone-based passkey via Microsoft Authenticator. |
| Temporary Access Pass (TAP) | Help Desk + onboarding groups only | One-time use: On. Minimum lifetime: 1 hour. Maximum lifetime: 8 hours. Default lifetime: 1 hour. Scope to 🛡️Group - Help Desk Users + 🛡️Group - Onboarding Devices (or equivalent in your tenant). |
| Windows Hello for Business | All users | Managed at device level via Intune. This policy just enables the method as a valid auth. |
| Certificate-based authentication | Nobody (default) | Only enable if the customer has a managed PKI. Rare in MKB. |
Registration Campaign
| Setting | Value | Why |
|---|---|---|
| Registration Campaign | Enabled | Periodically nudges users with weaker MFA methods (e.g., still using SMS where you've allowed it for migration) toward Microsoft Authenticator. |
| Snooze duration | 7 days | User can snooze the nudge, but it comes back. |
| Include users | All users | Default. |
| Exclude users | Break-the-Glass accounts (they don't sign in often enough to register, and TAP handles their bootstrap separately) |
Caveats ⚠️
License fit. Included in Entra ID Free. Works on every M365 SKU. No tier-up.
Tenant-wide, no per-user escape hatches. Scope per-method via groups, not per-user via direct assignment. If a user "needs SMS" (they don't, but let's say Greg from sales is on his fourth Nokia of the decade), the answer is an exclusion group on the SMS method, not flipping the global toggle to keep Greg happy. Greg is not the threat model. Greg's reused 2014 password is. 📞
The legacy MFA settings page is gone. If a tenant still has stale per-user "Enable / Enforce MFA" assignments from before the 2024 migration, those are inert but visually confusing. Audit and clean up as part of the rollout.
Number matching cannot be turned off. Microsoft made number matching mandatory on Authenticator push in February 2023. The setting in this policy is for clarity, not for choice.
TAP scope matters. A TAP is a password with an expiry sticker on it. Scope TAP issuance to "All users" and you've handed every helpdesk-tier role a "skip MFA" coupon they can text to whoever calls in sounding stressed. That's not a help desk feature. That's a social engineering speed-run. 🎟️ Scope TAP issuance to the actual helpdesk group, not All.
Conditional Access still does the gating. This policy says "these methods are available." It does not enforce "you must use the strong ones for admin roles." That's the Authentication Strengths policy combined with CA. Both pieces are required.
Reversibility. Authentication Methods policy is clean-revert. Disabling a method here stops new sign-ins via that method on next sync. Already-issued tokens remain valid for their lifetime; revoke explicitly if you need an immediate cut.
💡 SuperVision tip
Baseline policy. Golden Master → Entra → Authentication → Methods. One canonical configuration per tenant, deployed identically across the MSP customer base.
Tag candidates:
- TAP-eligible groups: per-tenant. The Help Desk and Onboarding groups have different names per customer; tag the assignment, not the policy.
- Third-party OATH allowed users: per-tenant exception. Default is empty. Tag for the rare tenant where the customer insists.
Everything else (which methods are enabled, number matching, attestation, registration campaign) is fleet identity. Same across every tenant. Not a tag.
Drift detection. Watch two surfaces:
- Method enablement. If SMS or voice flips back to enabled, that's almost always a tenant admin who got phished by a vendor support call. Alert. Investigate.
- TAP scope. If TAP issuance authority widens from the helpdesk group to "All users", that's a real privilege escalation primitive. Critical alert.
Multi-tenant scaling. Identical policy across every customer. The variable is who's in the TAP-eligible groups per tenant.
Bootstrap problem. New tenant onboarding: you need someone who can issue TAPs before the helpdesk group exists. Use the 🛡️🧑💼⛓️🔓🚦Group - Break the Glass solution account paired with a FIDO2 key for the first TAP issuance, then build out from there. Document this in the tenant onboarding runbook.
👥 Assignment scope
The policy is tenant-wide, but per-method targeting is via group:
| Method | Target |
|---|---|
| Microsoft Authenticator, FIDO2, Passkey, Windows Hello | All users |
| TAP | Helpdesk group + Onboarding group only |
| SMS, Voice, Email OTP, OATH variants | Nobody (disabled) |
| Certificate-based | Nobody (unless customer has managed PKI) |
🔗 Related
- 🚦🟢👨💼CA - MFA for All Users (the CA that enforces MFA tenant-wide)
- 🛡️🧑💼⛓️🔓🚦Group - Break the Glass solution (for the TAP bootstrap problem)
- 🔐🧑💼AS - Authentication Strengths (defines named strength bundles that CAs reference)
SMS is not MFA in 2026. It's a check mark in the wrong column, sitting next to a phone number an attacker can SIM-swap on a Tuesday afternoon from a Starbucks. 📵