Most organisations breached "despite MFA" had MFA; they also had a weak factor, a coverage gap or a recovery process that let the attacker walk around it. Attackers rarely break the cryptography. They bombard users with push prompts, call the help desk, use a protocol that never asks for a second factor, or steal the session after sign-in. This list covers the ten deployment mistakes we see most often, why each matters, an incident where it played a part, and the fix. It is for identity, security operations and IT teams who already run MFA and want to know where it will fail.
The Top 10 at a glance
- SMS and voice as the default factor
- Push approval without number matching
- Gaps on legacy protocols and secondary entry points
- Weak recovery and help desk resets
- No phishing-resistant MFA for administrators
- MFA only at the front door
- Exclusions in Conditional Access
- Trusting MFA claims from federated IdPs
- No monitoring of MFA registration changes
- Ignoring NHIs that cannot do MFA
| # | Mistake | How attackers use it | First fix |
|---|---|---|---|
| 1 | SMS and voice as the default factor | SIM swap, SS7 interception, codes typed into phishing pages | App-based or phishing-resistant default; SMS as last resort |
| 2 | Push approval without number matching | MFA fatigue (push bombing) | Number matching, prompt limits, investigate denials |
| 3 | Gaps on legacy protocols and secondary entry points | Password spray against basic auth, VPN, remote access, SaaS | Block legacy authentication; inventory every sign-in path |
| 4 | Weak recovery and help desk resets | Social engineering the help desk to reset MFA | Recovery as strong as enrolment |
| 5 | No phishing-resistant MFA for administrators | Adversary-in-the-middle relay of codes and pushes | FIDO2 or certificate-based MFA for privileged roles |
| 6 | MFA only at the front door | Session cookie and token theft | Token binding, short privileged sessions, step-up |
| 7 | Exclusions in Conditional Access | Excluded users and groups become the bypass | Owned, expiring, monitored exclusions |
| 8 | Trusting MFA claims from federated IdPs | Forged or weakly issued assertions satisfy MFA policy | Decide explicitly whether to accept federated MFA |
| 9 | No monitoring of MFA registration changes | Attacker registers their own authenticator | Protect registration; alert on new methods |
| 10 | Ignoring NHIs that cannot do MFA | Static service account secrets used with no second factor | Workload identity and short-lived credentials |
1. SMS and voice as the default factor
The mistake: SMS or voice codes remain the default, or the fallback for every other method, long after the rollout that needed them.
Why it matters: CISA ranks SMS and voice as the weakest MFA and says it "should only be used as a last resort MFA option", citing SIM swap and SS7 interception. NIST SP 800-63B-4 makes the telephone network its only "restricted" authenticator and treats a phone number change as binding a new authenticator. Typed codes can also be phished: the 0ktapus campaign behind the Twilio breach began with SMS messages to employees.
The fix: default to an authenticator app with number matching or a phishing-resistant method; keep telephony only for users with no alternative, and treat number changes as new enrolments. See the Authenticator Apps and OTP Guide.
2. Push approval without number matching
The mistake: a single "Approve" tap, with no code to match and no limit on how many prompts an attacker can trigger.
Why it matters: push bombing (ATT&CK T1621, Multi-Factor Authentication Request Generation) needs only a stolen password and patience. MFA fatigue played a part in the Uber breach and the Cisco breach in 2022.
The fix: enable number matching (for example Microsoft Authenticator number matching or Duo Verified Push) and cap prompts per time window. CISA calls number matching "one of the best interim" mitigations, "not as strong as phishing-resistant MFA", and says every denied push should be investigated because it "could mean the user's password is compromised". See the MFA Fatigue and Bypass Guide.
3. Gaps on legacy protocols and secondary entry points
The mistake: MFA guards the SSO portal while IMAP, POP, SMTP AUTH, Exchange ActiveSync, older VPNs, remote access gateways and directly accessed SaaS tenants accept a password alone.
Why it matters: Microsoft's analysis found that more than 97 percent of credential stuffing and more than 99 percent of password spray attacks use legacy authentication; the NCSC lists "bypass by legacy protocols" as an anti-pattern. The Change Healthcare breach began with a remote access login without MFA, and in the Snowflake breach infostealer credentials worked on customer accounts without MFA.
The fix: in Entra ID, block the "Exchange ActiveSync clients" and "Other clients" conditions, starting in report-only mode. Put every VPN, gateway, bastion and SaaS admin console behind the IdP, or record it as an owned exception; CISA advises escalating systems that cannot support MFA to senior leadership. See the Remote Access Identity Guide.
4. Weak recovery and help desk resets
The mistake: a caller who knows an employee's name, ID and manager can get MFA reset or a new device registered.
Why it matters: the weakest path sets the real strength. CISA advisory AA23-320A describes Scattered Spider posing as IT staff "to convince IT help desk personnel to reset passwords and/or MFA tokens". A help desk call preceded Okta admin access in the MGM Resorts breach, and help desk social engineering featured in the Co-op attack.
The fix: recovery must not bypass MFA and must prove identity to enrolment level (OWASP ASVS 5.0 6.4.3 and 6.4.4): video checks, callback to an HR-held number, manager approval for privileged users, and a time-limited Temporary Access Pass instead of a reset to SMS. Encourage two registered authenticators, as NIST SP 800-63B-4 recommends. See the Account Recovery and Help Desk Security Guide.
5. No phishing-resistant MFA for administrators
The mistake: administrators, cloud owners and help desk staff use the same push or OTP methods as everyone else.
Why it matters: adversary-in-the-middle kits relay passwords, codes and push approvals in real time. NIST SP 800-63B-4 says manual entry of an authenticator output is not phishing-resistant and requires phishing resistance at AAL3. One hijacked admin can do enormous damage: in the Stryker attack a single admin account used Intune to wipe devices.
The fix: start where CISA suggests, with "help desk and IT system administrators". In Entra ID, apply the built-in "Phishing-resistant MFA" authentication strength (FIDO2 security key, Windows Hello for Business or platform credential, multifactor certificate-based authentication) through the "Require authentication strength" grant to privileged roles. See the Hardware Security Keys Guide, the Passwordless and Passkeys Guide and the AiTM Phishing Guide.
6. MFA only at the front door
The mistake: MFA is checked once, then the session cookie or refresh token is trusted for days, from any device.
Why it matters: a stolen session skips authentication. Session tokens taken from vulnerable appliances bypassed MFA in CitrixBleed, and a stolen SSO session opened the CircleCI breach.
The fix: bind tokens to devices where supported (Entra Token Protection accepts only device-bound sign-in session tokens for supported apps; pilot in report-only mode), keep privileged sessions short, and require fresh phishing-resistant authentication for sensitive actions. NIST SP 800-63B-4 caps AAL3 sessions at 12 hours with a 15-minute inactivity timeout. Avoid blanket frequent prompts, which the NCSC warns "desensitise" users. See the Token and Session Security Guide.
7. Exclusions in Conditional Access
The mistake: MFA policies exclude executives who complained, an old migration group, integration accounts or a whole "VIP" group.
Why it matters: ATT&CK T1556.006 (Modify Authentication Process: Multi-Factor Authentication) lists "excluding users from Azure AD Conditional Access Policies" as an attacker technique. The NCSC calls this "backdoor by excluded accounts", allowing only "heavily monitored emergency 'break glass' accounts".
The fix: give each exclusion an owner, reason and expiry, review monthly, and alert on every policy change. Protect break-glass accounts with FIDO2 keys and alert on each use. See the Conditional Access Guide and the Break-Glass Account Guide.
8. Trusting MFA claims from federated IdPs
The mistake: a cloud tenant accepts a federated identity provider's claim that MFA was done, and nobody decided whether it deserves that trust.
Why it matters: in Entra ID, if neither federatedIdpMfaBehavior nor the older SupportsMfa is set, the default is acceptIfMfaDoneByFederatedIdp. A compromised federation server or stolen token-signing key lets an attacker write any claim: forged SAML tokens were central to the SolarWinds compromise.
The fix: set federatedIdpMfaBehavior deliberately, using rejectMfaByFederatedIdp if the cloud IdP should always perform MFA. If you accept federated MFA, protect signing keys as tier 0 assets and retire on-premises federation you no longer need. See the Identity Provider and SSO Security Guide.
9. No monitoring of MFA registration changes
The mistake: anyone with a valid password can register a new authenticator, and nobody reviews registration events.
Why it matters: once an attacker's device is registered, every later check passes. CISA reports that Scattered Spider actors "register their own MFA tokens". OWASP ASVS 5.0 requirement 6.3.7 (L3) requires users to be notified after changes to authentication details.
The fix: require MFA or a Temporary Access Pass to register methods (a Conditional Access policy on the "Register security information" user action), notify users of every change, and alert when a new method ("User registered security info" in the Entra audit log) is followed by sign-ins from a new device or country. See the ITDR Guide.
10. Ignoring NHIs that cannot do MFA
The mistake: MFA coverage is reported as "100%" of users while service accounts, API keys and app registrations authenticate with static secrets.
Why it matters: Microsoft states that workload identities "can't perform multifactor authentication"; Conditional Access for them can only block by location or risk, covers single-tenant service principals but not managed identities, and needs a separate licence. People using service accounts to dodge MFA is OWASP NHI10 (Human Use of NHI). In the Okta support system breach a service account saved in a personal Google profile exposed data on 134 customers, and in the Dropbox Sign breach a back-end service account exposed MFA secrets.
The fix: move to managed identities, workload identity federation and short-lived tokens; block interactive sign-in for service accounts; apply location policies to service principals; give every NHI an owner. See the Service Account Security Guide and the NHI Authentication Guide.
Mapping to OWASP
| Mistake | OWASP ASVS 5.0 (V6) | OWASP Top 10:2025 | OWASP NHI Top 10 (2025) |
|---|---|---|---|
| 1. SMS and voice as default | 6.6.1 | A07 Authentication Failures | Not applicable |
| 2. Push without number matching | 6.6.4 | A07 | Not applicable |
| 3. Legacy protocols and entry points | 6.1.3, 6.3.4 | A07 (CWE-308) | NHI4 Insecure Authentication |
| 4. Weak recovery | 6.4.3, 6.4.4 | A07 (CWE-640) | Not applicable |
| 5. No phishing-resistant MFA for admins | 6.3.3 (L3 hardware factor) | A07 | Not applicable |
| 6. MFA only at the front door | Not mapped | A07 (session identifiers) | Not applicable |
| 7. Conditional Access exclusions | 6.1.3 | A07 | Not applicable |
| 8. Trusting federated MFA claims | 6.3.4 | A07 | Not applicable |
| 9. Unmonitored registration | 6.3.7 | A07 | Not applicable |
| 10. NHIs without MFA | Not mapped | A07 (weak fallbacks) | NHI4, NHI7, NHI10 |
For detection content, the matching ATT&CK techniques are T1621 (mistake 2) and T1556.006 (mistakes 7 and 9).
Where to start
If you can do only three things this quarter: enforce phishing-resistant MFA for administrators and help desk staff (mistake 5), harden help desk recovery (mistake 4), and block legacy authentication while listing every other entry point (mistake 3). Track five numbers monthly: privileged accounts on phishing-resistant methods (target 100%), active MFA exclusions, legacy authentication sign-ins (target zero), users whose only method is SMS or voice, and the share of denied pushes and new registrations investigated.
Primary sources: CISA fact sheets on phishing-resistant MFA and number matching, NIST SP 800-63B-4, CISA advisory AA23-320A, NCSC MFA anti-patterns, OWASP ASVS 5.0 V6, and Microsoft Learn on legacy authentication, authentication strengths, Token Protection, federatedIdpMfaBehavior and workload identities.
Related NHI Mgmt Group resources: MFA Guide · Account Takeover Prevention Guide · Vishing and Smishing Guide · Workforce Identity Security Guide