Approval-based MFA breaks when attackers can manipulate the user, intercept the code or replay the session after the factor has been accepted. The problem is not only bypass, but the false sense of assurance created by prompts that are easy to fatigue, spoof or relay. That makes the factor operationally weak even when it is technically present.
Why approval-based MFA breaks under 2026 attack patterns
Approval-based MFA only helps when the approval step is meaningfully resistant to social engineering, relay, and session theft. Once an attacker can trigger, coerce, or replay that approval, the factor stops being a reliable proof of user intent and becomes a speed bump. The control may still exist, but it no longer provides the assurance decision the organisation thinks it does.
That is why modern attacks focus on the approval workflow itself: fatigue, prompt bombing, help desk manipulation, code interception, and token replay all attack the trust assumption behind the second factor. MFA Guide and Workforce Identity Security Guide both show that the weak point is often not password verification, but the point where the user or session is tricked into approving access.
In practice, the failure is architectural as much as behavioural. Approval-based MFA was designed for a threat model where the presence of a prompt implied user participation and freshness. 2026 threats routinely separate those assumptions, so the control no longer distinguishes a legitimate session from a coerced, relayed, or stolen one. NIST SP 800-63 Digital Identity Guidelines is the useful reference point here because it pushes teams toward stronger authenticator assurance, not just a visible second step.
What attackers exploit: the approval, the channel, or the session
Attackers do not need to “break MFA” in the abstract. They only need one of three openings: make the user approve the request, intercept the one-time factor or approval flow, or steal the resulting session after approval. The result is the same, namely a valid-looking sign-in that bypasses the intended security decision.
This is why phishing-resistant methods matter more than approval-based ones for high-risk access. Passwordless and Passkeys Guide covers the shift toward FIDO2 and WebAuthn because they bind the authentication event to the origin and device, which is much harder to relay than an approval prompt. When the attacker cannot proxy the challenge cleanly, the entire relay class of attacks loses effectiveness.
Session theft is the other major break point. Even when the factor is accepted legitimately, a stolen cookie, token, or remote-access session can let an attacker continue as if they had completed a strong login. CitrixBleed exploitation 2023 is a direct example of why post-authentication session control matters as much as the factor itself.
What organisations should change before approval-based MFA becomes a liability
Approval-based MFA should be treated as a transitional control, not a 2026 endpoint for privileged or high-impact access. The practical move is to reserve it for lower-risk use cases, then replace it where the consequence of session compromise is material, especially for admin, remote access, finance, support, and recovery paths.
MFA Guide is the best starting point for deciding whether a flow is strong enough to keep, because it distinguishes phishing-resistant methods from prompt-based ones. The important question is not whether MFA exists, but whether the method can survive modern relay, fatigue, and token-theft attacks without relying on user vigilance.
Change Healthcare breach 2024 and Colonial Pipeline ransomware attack show the operational cost of treating remote access exceptions as harmless. If an approval-based factor protects a path into production systems, the organisation should verify whether the underlying session, device trust, and recovery process are actually stronger than the prompt itself.
Risk and Threat Considerations
Approval-based MFA creates a false assurance problem: defenders think they have a second factor, while attackers increasingly target the human decision, the message channel, or the authenticated session after approval. That makes the control vulnerable even when deployment is widespread, because the attacker only needs one weak approval moment or one stolen post-authentication token.
Failure mechanism: The attacker manipulates the user into approving, relays the challenge through an adversary-in-the-middle flow, or steals the session token after approval so the login can be replayed without re-prompting.
Impact: The organisation loses the intended protection boundary around authentication, which can lead to account takeover, lateral movement, privileged access abuse, and harder-to-detect persistence.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-63, NIST SP 800-53 Rev 5, OWASP ASVS, CIS Controls v8 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-63 | Digital Identity Guidelines | Sets assurance expectations for phishing-resistant authentication and authenticator strength. |
| Recommendation — Adopt phishing-resistant authenticators and align assurance level to the access risk. | ||
| NIST SP 800-53 Rev 5 | IA-2 — Identification and Authentication (Organizational Users) | Approval-based MFA is an organizational-user authentication control with assurance gaps. |
| IA-5 — Authenticator Management | Approval-based MFA fails when authenticators or approvals can be intercepted or replayed. | |
| IA-9 — Identification and Authentication (Service and Non-Organizational Users) | Session and token replay risks are central when access is mediated by service-like sessions. | |
| Recommendation — Require stronger user authentication methods for sensitive access paths. Harden authenticator lifecycle, replay resistance, and recovery paths. Bind sessions and tokens tightly enough to prevent replay after authentication. | ||
| OWASP ASVS | V10 — OAuth and OIDC | Modern approval bypass often abuses token issuance, relay, and session continuity. |
| Recommendation — Verify token issuance and session protections resist relay and replay. | ||
| CIS Controls v8 | CIS-6 — Access Control Management | Approval-based MFA affects who can access systems and how access is granted. |
| Recommendation — Remove weak access paths and enforce stronger authentication for high-risk accounts. | ||
| NIST Zero Trust (SP 800-207) | Zero Trust Architecture | The topic hinges on continuous verification rather than trusting a single approval event. |
| Recommendation — Design access decisions to re-verify trust instead of relying on one MFA prompt. | ||
Practitioner Guidance
What to prioritise: Treat approval-based MFA as insufficient for any account whose compromise would materially change business or security outcomes. Prioritise admins, help desk, finance, remote access, and recovery paths first, because those are the places where a single coerced approval or stolen session has the largest blast radius.
What to verify: Confirm whether the factor is phishing-resistant, whether the session is bound tightly enough to resist replay, and whether recovery paths are stronger than daily sign-in. If the answer to any of those is unclear, the control should not be treated as a durable protection layer.
Practitioner takeaway: The right question is not whether MFA is present, but whether the factor still proves user intent after real-world attack pressure. If it can be fatigued, relayed, or replayed, it is no longer strong enough to anchor trust in 2026.
Related resources from NHI Mgmt Group
- What breaks when organisations keep password-based remote access in place?
- What breaks when organisations keep weak recovery paths alongside strong MFA?
- What breaks when organisations rely only on access-based controls to catch insider threats?
- What breaks when organisations keep exceptions for password-based access after moving to passwordless authentication?