MFA Fatigue and Bypass Guide: Push Bombing, SIM Swap and Downgrade Attacks

Most MFA bypasses do not break the cryptography; they exploit the weakest method, channel or process an account will still accept. An attacker with a valid password can flood a user with push prompts, persuade a mobile carrier to move the victim's number to a new SIM, pick a legacy protocol that never asks for a second factor, or register their own authenticator before the real user does. This guide covers MFA fatigue (push bombing), SIM swap and port-out fraud, SS7 and SMS interception, downgrade and fallback abuse, and enrolment hijack, mapped to MITRE ATT&CK and to the controls that stop each one. It is written for identity engineers, security architects and SOC teams who run workforce or customer MFA. Adversary-in-the-middle phishing and session token theft are covered only where they overlap; the descriptions here stay at technique level and are meant for defenders.

Key takeaways

• Attackers choose the weakest accepted path. An account protected by a FIDO2 key but still allowed to use SMS, legacy protocols or a help-desk reset is only as strong as SMS, legacy protocols or the help desk.
• Number matching is an interim fix, not the destination. CISA describes number matching as a compensating control against push bombing and still recommends phishing-resistant MFA (FIDO/WebAuthn or PKI) as the target state.
• The phone network is a restricted channel. NIST SP 800-63B-4 lists out-of-band authentication over the PSTN as its only restricted authenticator and asks verifiers to check signals such as SIM change and number porting before sending a code.
• Enrolment and recovery are part of authentication. ATT&CK T1098.005 and T1556.006 describe attackers registering their own MFA device or a weaker factor; protect registration with the same strength you require at sign-in.
• Denied prompts are an alert, not noise. A rejected push means someone already has the password; treat it as a credential compromise signal and reset, not as a user error.

How MFA bypass attacks map to ATT&CK

Using ATT&CK IDs in detections, threat models and incident reports keeps teams talking about the same thing.

ATT&CK lists LAPSUS$, Scattered Spider and APT29 as procedure examples for T1621, and LAPSUS$ and Scattered Spider for T1451.

Push bombing and MFA fatigue

T1621 describes adversaries repeating sign-in attempts so the user receives a stream of push notifications, texts or calls until one is accepted. Users approve to stop the noise, by mistake, or because a caller posing as IT support tells them to. ATT&CK also notes that self-service password reset can be abused to generate prompts.

Controls that work

• Number matching: the sign-in page shows a number the user must type into the authenticator app, so a prompt cannot be approved blindly. Microsoft Authenticator now applies number matching to all push notifications, including SSPR and combined registration. Okta Verify exposes the setting "Push notification (number challenge)" with the options Never, Only for high risk sign-in attempts and All push challenges; choose All push challenges. CISA's fact sheet also names Duo Verified Push.
• Check the integrations that fall back: the Microsoft Entra NPS extension does not support number matching. From version 1.2.2216.1 it prompts for a TOTP code if the user has one registered, and the registry value OVERRIDE_NUMBER_MATCHING_WITH_OTP under HKLM\SOFTWARE\Microsoft\AzureMfa controls this. Setting it to FALSE falls back to plain Approve/Deny, which reintroduces fatigue risk on VPN and RD Gateway. Check every RADIUS, VPN and on-premises adapter for the same gap.
• Rate limits on prompts: NIST SP 800-63B-4 says out-of-band verifiers that send push notifications SHOULD implement a reasonable limit on the rate or total number of push notifications since the last successful authentication, and that generating a new secret SHALL NOT reset the failed-attempt count.
• Bind the approval to the session: SP 800-63B-4 (Sec. 3.1.3) now requires approval-based authenticators to accept a transfer of a secret from the primary channel, and states that simply comparing secrets and approving on the secondary channel "is no longer considered acceptable". Number matching meets the transfer pattern; a bare Approve button does not.
• A report button that does something: Microsoft Entra's "Report suspicious activity" sets the user to high user risk and logs a risk detection of type userReportedSuspiciousActivity. It replaced the legacy fraud alert feature in March 2025 and is disabled when left as Microsoft managed, so enable it explicitly and attach a risk-based policy that forces a password reset.

Why number matching is not the end state

Number matching stops blind approval, but not a user talked into reading the number to a caller, nor a real-time phishing proxy that relays the genuine number. NIST SP 800-63B-4 states that authenticators involving manual entry of an output are not phishing-resistant, and the NCSC describes app push as giving only partial phishing resistance because of prompt fatigue. Treat it as the floor for accounts on push, and plan the move to FIDO2 or certificate-based authentication. See the Passwordless and Passkeys Guide.

SIM swap, port-out fraud and SS7 interception

ATT&CK T1451 describes SIM swap as an attacker using phished, socially engineered or breached personal data to impersonate the victim to a mobile carrier and have the number moved to a SIM or device they control. Port-out fraud achieves the same result by moving the number to another carrier. The attacker then receives every SMS code and call. CISA's phishing-resistant MFA fact sheet separately warns that attackers can "exploit SS7 protocol vulnerabilities in communications infrastructure to obtain MFA codes" sent by SMS or voice, without touching the victim's handset at all.

What the standards now say

• NIST SP 800-63B-4 Sec. 3.2.9: PSTN out-of-band authentication is the one restricted authenticator. Services that use it must offer at least one non-restricted alternative and give meaningful notice of the risks.
• NIST SP 800-63B-4 Sec. 3.1.3.3: verifiers SHOULD consider risk indicators such as device swap, SIM change and number porting before using the PSTN to deliver a secret, and changing the registered phone number counts as binding a new authenticator.
• FCC 23-95 (WC Docket No. 21-341): US wireless providers must use secure authentication before SIM changes and port-outs (readily available biographical, account, recent payment and call detail information do not qualify), notify customers immediately before completing a request, and offer a free account lock against SIM changes and port-outs. The rules took effect on 8 January 2024, with some recordkeeping provisions delayed.

Detecting SIM swap before you send a code

1. Use carrier signals where available: if your messaging provider can return a recent SIM-change or porting indicator for a number, check it before sending an OTP or a recovery link, and step up or block when the change is recent.
2. Treat a phone number change as a new authenticator: require an existing strong factor to change it and send a notice to every other registered channel, as SP 800-63B-4 implies.
3. Remove SMS from recovery for privileged and high-value accounts: SMS-based recovery lets a SIM swap reset every other factor on the account. See the Account Recovery and Help Desk Security Guide.
4. Ask staff to enable carrier protections: T1451's mitigation M1011 recommends a carrier PIN or password for account changes; under the FCC rules US carriers must also offer an account lock. MDM or EMM can report SIM changes on corporate devices (M1012).

Downgrade and fallback abuse

A downgrade attack pushes authentication onto a weaker method the account still allows. It rarely needs a protocol exploit.

• Legacy protocols: Microsoft states that more than 97% of credential stuffing attacks and more than 99% of password spray attacks use legacy authentication, which cannot carry an MFA challenge. Block it with a Conditional Access policy targeting the Client apps conditions "Exchange ActiveSync clients" and "Other clients". The NCSC lists bypass by legacy protocols as its first MFA anti-pattern.
• Method choice at sign-in: when a user has both a passkey and SMS registered, an attacker who controls the SMS channel selects SMS. Microsoft Entra's system-preferred authentication prompts for the strongest registered method (passkeys and certificate-based authentication rank above push, TOTP and telephony) but does not enforce it. Enforcement comes from a Conditional Access policy using "Require authentication strength", with the built-in Phishing-resistant MFA strength (FIDO2 security key, Windows Hello for Business or platform credential, multifactor certificate-based authentication) for administrators.
• Recovery and help-desk fallbacks: a reset that accepts knowledge questions or a phone call is a downgrade path to every factor on the account. In the MGM Resorts breach, a help-desk phone call led to Okta admin access.
• Excluded accounts: the NCSC's "backdoor by excluded accounts" anti-pattern covers users exempted because MFA was inconvenient, and legacy service accounts used to automate mailbox or calendar access. Its only accepted exception is a heavily monitored break-glass account.
• Fail-open configurations: T1556.006 notes that when an MFA service is unreachable, a fail-open policy may let sign-ins through without the second factor. ATT&CK mitigation M1032 recommends configuring MFA to fail closed where possible.

Enrolment hijack and MFA registration abuse

ATT&CK T1098.005 notes that some MFA self-enrolment flows need only a username and password. An attacker with a password for an account that has not yet registered MFA, or a dormant account, simply registers their own device. ATT&CK records APT29 enrolling a device in MFA after password guessing against a dormant account, and Scattered Spider registering its own MFA tokens after compromise (T1556.006).

• Protect the registration action: in Microsoft Entra, a Conditional Access policy on the user action "Register security information" can require an authentication strength outside trusted locations and block guest registration from untrusted networks. Equivalent policies exist in other identity providers as enrolment or authenticator policies.
• Issue a temporary access pass for first enrolment: ATT&CK's M1032 guidance lists temporary access passes as an initial method, so a new user's first factor is bound with a credential the help desk issued after identity verification, not with a password alone.
• Block enrolment on inactive accounts: disable or reverify accounts that have not registered MFA within a set period.
• Notify on every new factor: alert existing channels and the SOC when a factor is added, especially a weaker one such as SMS (ATT&CK DET0190).

Choosing defences: which methods resist which attacks

Decision guidance

• Administrators, help-desk staff and finance approvers: phishing-resistant only, with SMS and push removed from the account entirely. CISA recommends starting phishing-resistant MFA with high-value users such as administrators and help-desk staff.
• General workforce on push: number matching everywhere now, including VPN and RADIUS paths, then migrate to passkeys or platform authenticators over a defined timeline.
• Customers: SMS may be unavoidable for reach. Offer passkeys, run SIM-change and number-change risk checks before sending codes, and keep SMS out of recovery for high-value accounts. See the Customer IAM (CIAM) Guide.
• Small organisations: CISA notes that app-based MFA with number matching is a practical step for small and medium businesses that cannot adopt phishing-resistant MFA immediately. Start with the email and SSO platform and buy security keys for the few admin accounts.
• Large organisations: the hard part is the long tail: RADIUS, VPN concentrators, on-premises adapters, legacy mail clients and third-party apps that cannot use the main IdP's policies. Inventory these first, because each is a downgrade path.

Where identity fits beyond the user

Excluded accounts are often non-human: service accounts used by scripts, mail connectors or legacy integrations, exempted from MFA because they cannot answer a prompt. Once users are protected, they are the password-only path an attacker looks for. Microsoft notes that user-scoped Conditional Access policies do not block service principal calls and recommends workload identity policies and managed identities. Replace exempted service accounts with workload identities or certificate-based credentials rather than adding them to exclusion groups. See the Service Account Security Guide.

How to implement: a phased rollout

1. Inventory methods and paths (weeks 1-2): export registered methods per user, list every application and protocol that authenticates against the directory, and flag SMS, voice and approve/deny push, accounts without MFA, and exclusion groups.
2. Close the free bypasses first: create the legacy authentication block policy in report-only mode, review sign-in logs filtered by client app (including non-interactive sign-ins) for two to four weeks, migrate or exempt named exceptions, then enforce.
3. Enforce number matching on every push path: confirm AD FS adapters are patched, NPS and RADIUS integrations use TOTP rather than Approve/Deny, and wearable approval is not the only option for any user.
4. Protect registration and recovery: deploy the security-info registration policy in report-only, issue temporary access passes for onboarding, require an existing strong factor or verified identity for any phone number or factor change, and harden help-desk reset scripts.
5. Pilot phishing-resistant MFA with administrators: issue FIDO2 keys or enable platform credentials, apply a Conditional Access policy requiring the Phishing-resistant MFA authentication strength to a pilot ring, then all privileged roles. Keep two keys per admin to avoid recovery calls.
6. Remove weaker methods: once coverage for a group passes your threshold, disable SMS and voice for that group in the authentication methods policy, and give the remaining stragglers a dated deadline and a temporary access pass rather than a standing exception.
7. Roll back safely: every new policy starts in report-only, excludes the break-glass accounts, and is enabled per group. If an enforced policy locks users out, switch that policy back to report-only rather than deleting it, issue temporary access passes to affected users, and fix the cause before re-enabling. See the Break-Glass Account Guide.

Detection and measurement

What to monitor

• Prompt floods: several MFA challenges for one user within minutes, especially with denials or timeouts, and from an unfamiliar IP or location (ATT&CK DET0160).
• Denied or reported prompts: sign-in log result "MFA denied" and risk detections of type userReportedSuspiciousActivity. CISA advises investigating every denied push as a possible password compromise.
• Approval after a flood: a successful MFA approval following a run of denials, followed by a new device registration or inbox rule, is a high-confidence fatigue pattern.
• Factor changes: new MFA method registration, a weaker method added to a strong account, phone number changes, and sign-ins that succeed without an expected MFA challenge (DET0190, DET0036).
• Legacy authentication attempts: any successful sign-in through Exchange ActiveSync or "Other clients" after the block date.
• Help-desk events: MFA resets and temporary access pass issuance joined to subsequent sign-in risk.

Metrics that show it is working

See the Identity Security Metrics Guide.

Framework mapping

Common failure patterns

• Push without number matching on one forgotten path: the main IdP enforces number matching, but a VPN or RADIUS integration still sends Approve/Deny. The Cisco breach combined a synced browser password with voice phishing and MFA fatigue to reach the corporate VPN.
• Treating a flood as a user nuisance: users are told to deny and carry on, and nobody resets the password. In the Uber breach, MFA fatigue against a contractor whose password the attacker held led to Uber's internal systems.
• Strong factor added, weak factor left on: users enrol a passkey but keep SMS as backup, so the SIM swap path remains.
• Help desk as the universal fallback: agents reset MFA on caller knowledge alone, the route seen in the MGM Resorts and Co-op Group incidents.
• Open self-enrolment: new or dormant accounts can register MFA with a password only, so whoever holds the password first owns the account (T1098.005).

Practitioner checklist

• Enforce number matching on every push integration, including AD FS, NPS, RADIUS and VPN, and confirm none fall back to Approve/Deny.
• Require the phishing-resistant authentication strength for all administrators and help-desk staff, with two registered keys each.
• Block legacy authentication through Conditional Access or equivalent, after a report-only review of sign-in logs.
• Remove SMS and voice from privileged accounts and from account recovery for high-value users.
• Protect MFA registration with an authentication strength or temporary access pass, and block enrolment on dormant accounts.
• Enable a user report button for unexpected prompts and route reports to a risk policy that forces password reset.
• Alert on prompt floods, approvals after denials, new factor registrations and phone number changes.
• Check SIM-change or porting signals before sending SMS codes or recovery links to customers.
• Reduce MFA exclusion groups to monitored break-glass accounts and move service accounts to workload identities.
• Configure MFA to fail closed and test what happens when the MFA service is unreachable.

Standards and references

• NIST: SP 800-63B-4 Authentication and Authenticator Management
• MITRE ATT&CK: T1621 Multi-Factor Authentication Request Generation
• MITRE ATT&CK: T1451 SIM Card Swap
• MITRE ATT&CK: T1098.005 Account Manipulation: Device Registration
• CISA: Implementing Phishing-Resistant MFA
• CISA: Implementing Number Matching in MFA Applications
• NCSC: Avoiding MFA Anti-Patterns
• Federal Register (FCC): Protecting Consumers From SIM-Swap and Port-Out Fraud

Related NHI Mgmt Group resources: MFA Guide · Passwordless and Passkeys Guide · Account Recovery and Help Desk Security Guide · Token and Session Security Guide · ITDR Guide