MS Authenticator: Hardening Your MFA Setup in 2026
How to harden Microsoft Authenticator and your MFA posture in 2026: number matching, Authentication Methods Policy, FIDO2, passkeys and break-glass.
TL;DR
Default MFA in Microsoft 365 is no longer good enough. Push-fatigue attacks, AiTM phishing kits like Evilginx, and SIM-swap on SMS-OTP all walk past basic Authenticator setups. This article covers the right Authenticator configuration in 2026: number matching enforced for everyone, location and app context shown in the prompt, the Authentication Methods Policy migrated off legacy settings, FIDO2 and passkeys for the admin tier, Conditional Access authentication strength policies, and a break-glass design that actually works.
What’s wrong with default MFA setups?
Three attack patterns dominate the post-mortems.
Push-fatigue attacks. The attacker has the password (from a credential dump, infostealer, or prior breach) and then spams the user’s Authenticator with push prompts at 11pm until the user taps Approve to make the buzzing stop. Lapsus$ used this against Microsoft, Okta, Uber and Cisco in 2022. It still works against any tenant where push-only approval is on.
Adversary-in-the-middle phishing. Evilginx and its cousins proxy a real Microsoft sign-in page through attacker infrastructure, capture the username, password and session cookie in flight, then replay the cookie. The user approves a legitimate-looking push prompt. The attacker inherits the session. Number matching hurts this but doesn’t stop it. Phishing-resistant MFA does.
SIM-swap on SMS-OTP. SMS as a second factor is still permitted on a depressing number of tenants, often as “a fallback for when the app isn’t working.” A SIM swap at any South African MNO takes a determined social engineer about an afternoon. SMS is not MFA in 2026. NIST deprecated it years ago.
There’s a fourth pattern, subtler than the rest: weak fallbacks undermine strong primary factors. The shiny Conditional Access policy requires phishing-resistant MFA, then a sub-policy lets users self-service-register a phone number when the security key is unavailable. The fallback is the attack surface.
What MS Authenticator gives you when set up properly
Number matching, on by default since May 2023. When the user gets a push, Authenticator shows a two-digit number they must type from the sign-in screen. The attacker who triggered the prompt has no way of knowing the number. Push-fatigue dies here because Approve now requires reading a number from a screen the attacker can’t see.
Application name and location context in the prompt. The push shows which app requested the sign-in and the geographic location it came from. A user who sees “Outlook, Lagos, Nigeria” at 2am while sitting in Cape Town has everything they need to know something’s wrong. This is configured in the Authentication Methods Policy, not somewhere obvious. It defaults on for new tenants but is often missing on older ones configured before the GA flip.
Passkey support inside the Authenticator app. As of mid-2024, Authenticator can hold device-bound passkeys for Entra ID. This is the path most tenants will take from push-with-number-matching to phishing-resistant MFA without buying hardware keys for every user.
The right Authenticator configuration
In Entra admin centre → Protection → Authentication methods → Policies, the Microsoft Authenticator method should be:
- Enable: Yes, Target: All users (break-glass excluded)
- Authentication mode: Any (push and passwordless), or Passwordless if you’ve finished the rollout
- Allow use of Microsoft Authenticator OTP: No (it’s a weaker mode, susceptible to phishing)
- Show application name in push and passwordless notifications: Enabled
- Show geographic location in push and passwordless notifications: Enabled
- Number matching for push notifications: Microsoft managed (which means on)
- Report suspicious activity: Enabled, target All users
Then kill the fallbacks you don’t want:
- SMS as an authentication method: Disabled for sign-in
- Voice call: Disabled
- Email OTP: Disabled
- Security questions: Disabled (they are a credential, not a factor, and should never come back)
We export the Authentication Methods Policy as JSON, diff it on every change, and commit it to the client’s tenant config repo. Clicking through the portal without version control is how drift happens.
What about phishing-resistant MFA?
Number-matched push is good. It is not phishing-resistant. An AiTM attack that proxies the real Microsoft sign-in can still walk a user through the number-matching dance, because the user is interacting with the real flow (proxied). The number is correct. The attacker still gets the session cookie.
Phishing-resistant MFA means the authenticator is bound to the legitimate origin and won’t release credentials to an attacker-controlled domain. Two options do this properly in 2026, with a third for specific environments.
FIDO2 security keys. YubiKeys, Token2 keys, Feitian keys. The WebAuthn flow signs a challenge that includes the origin. If the origin is login.microsoftonline.com, the key signs. If it’s login-microsoftonllne.com, it refuses. This is the strongest factor available and the right answer for the admin tier. Two keys per admin: one on the keyring, one in a sealed envelope in the safe. Around R450–R1200 per key depending on model.
Passkeys via the Microsoft Authenticator app. Same WebAuthn underneath, but the private key lives in the phone’s secure enclave. Cheaper to roll out: no hardware to ship and most users already have Authenticator installed. Slightly weaker than a hardware key because the phone’s overall attack surface is larger, but well above push-with-number-matching. This is the right answer for general users.
Certificate-based authentication. Useful in tightly controlled environments where users already have smart cards. Most South African SMEs don’t go here unless there’s a specific compliance driver.
The deployment pattern:
- Admin tier (global admins, exchange admins, SharePoint admins, conditional access admins, security admins): two FIDO2 keys each, no exceptions.
- Knowledge workers: passkeys via Authenticator. Number-matched push permitted as a transition state.
- Frontline and shared accounts: a separate problem. Don’t try to bolt phishing-resistant MFA onto shared accounts; fix the shared account structure first.
How to roll this out without breaking everything
Migrate off the legacy MFA settings page first. The old per-user MFA state (the deprecated page at account.activedirectory.windowsazure.com/UserManagement/MfaSettings.aspx) still controls authentication for tenants that haven’t migrated. The GA migration tool inside the Authentication Methods Policy moves all legacy state into the new model with a single button. Run it once. Confirm everything is now controlled by the new policy.
Phase the rollout. We have broken too many tenants by flipping authentication controls at the tenant level on a Friday.
- Pilot first. Pick five users across IT, finance, exec PA. Enrol them in passkeys, switch their CA policy to require phishing-resistant MFA. Run for a week. Document every breakage.
- Admin tier next. Every directory-role-holding account onto FIDO2 keys. CA authentication strength policy enforced. Break-glass tested before this lands.
- General users in waves. 25 at a time, starting with the most technical groups. Ship a one-page passkey enrolment guide. Have helpdesk on standby.
- Legacy fallbacks off, last. Once new methods are live and registered for everyone, disable SMS and voice. Run the registration report (Entra → Authentication methods → User registration details) before you flip. Anyone still on SMS-only gets a personal call.
Use Entra registration campaigns to nudge users to enrol stronger methods on next sign-in without locking them out. The alternative is a week of helpdesk tickets.
Conditional Access policies that pair with this
Authentication Methods Policy says what a user is allowed to register. Conditional Access says what they must use to access a resource. Both layers matter.
The CA policies we run alongside the Authenticator hardening:
- Phishing-resistant MFA for directory roles. Any privileged role: global admin, exchange admin, SharePoint admin, conditional access admin, security admin, billing admin, helpdesk admin. Grant: authentication strength → Phishing-resistant MFA. No exceptions other than break-glass.
- MFA strength for sensitive apps. Azure portal, M365 admin centre, Graph PowerShell, financial systems federated through Entra. Grant: authentication strength → MFA (number-matched push minimum).
- Block Legacy Authentication, tenant-wide. Still the highest-impact policy in most tenants. Legacy auth bypasses MFA entirely. If you haven’t blocked it, none of the rest matters.
- Session lifetime reduction for admin portals. Default is rolling refresh. For admin portals we drop session lifetime to 4 hours. Some friction is the point.
The full Conditional Access design is covered in our Microsoft 365 hardening guide.
Break-glass accounts
If you’ve enforced phishing-resistant MFA for directory roles and don’t have a tested break-glass path, you are one bad CA change away from being locked out of your own tenant.
The break-glass setup:
- Two cloud-only emergency-access global admin accounts. Long random passwords (30+ characters), generated once, never typed into a password manager.
- Excluded from every CA policy. Not by accident, not by drift. Documented.
- MFA via FIDO2 hardware keys. Two per account: one in the office safe, one off-site. Not the Authenticator app on someone’s phone.
- Sign-ins monitored. Any break-glass sign-in fires an alert to a named distribution list with an expectation of investigation.
- Tested every 90 days. If you haven’t tested in six months, you don’t have break-glass; you have a story you tell yourself.
The full break-glass guide is at Most Break-Glass Accounts Won’t Work When They’re Actually Needed.
Where this fits in the wider M365 picture
MFA is one layer. The full hardening picture covers Conditional Access, Defender for Business, Intune compliance, Sensitivity Labels and email authentication. The overview is at Microsoft 365.
If you’ve inherited a tenant where MFA is “on” but you’ve never audited which methods are permitted, whether the Authentication Methods Policy has been migrated, or whether your admin tier has hardware keys, that’s where the gap usually is.
Get a 60-minute MFA hardening review
We log into your tenant read-only, audit your Authentication Methods Policy posture, admin-tier coverage, Conditional Access authentication strength policies and break-glass setup. You get a written report with the three changes that close the biggest gaps, yours to keep whether you engage us further or not.
Email support@osh.co.za or use the contact form. We respond with a calendar link the same business day.
