Repeated prompt approvals, rising help desk complaints about login fatigue, unexpected approvals from unusual locations, and successful phishing relays all indicate that the control is being treated as a ritual rather than a safeguard. If users approve challenges reflexively, the system is already under behavioural attack, even if the factor itself has not technically broken.
Why This Matters for Security Teams
MFA failure rarely shows up as a clean outage. More often, it appears as a slow loss of friction: users approve prompts without reading them, help desks see repeated lockouts, and attackers begin to exploit the gap between a valid challenge and a meaningful security decision. NIST SP 800-53 Rev 5 Security and Privacy Controls is useful here because it frames authentication as a control that must actually reduce risk, not just generate a login event.
When MFA becomes routine, it stops distinguishing legitimate access from manipulation. That is why repeated push approvals, token fatigue, and consent abuse matter: they show the control is being absorbed into user habit. In a recent NHIMG study, the average time to remediate a leaked secret was 27 days even though 75% of organisations expressed strong confidence in their secrets management capabilities, which is a reminder that confidence and control effectiveness are not the same thing. The same gap appears with MFA when teams measure enrollment coverage but not challenge quality.
In practice, many security teams discover MFA weakness only after users have already been trained to approve first and think later.
How It Works in Practice
Healthy MFA should create a meaningful checkpoint. If the challenge no longer changes behaviour, the control is degrading. Security teams should look for a pattern, not a single event: approval volume rising without a corresponding increase in legitimate login volume, repeated prompts from the same accounts, and reports that users are seeing prompts they do not recognise. These are signs that attackers may be using push bombing, phishing relays, or session theft to turn MFA into a rubber stamp.
Operationally, the question is whether the second factor still adds trust. If the system accepts approvals from unusual geographies, devices with weak posture, or sessions that were not re-validated after risk changed, the control is too permissive. Stronger implementations tie MFA to context, such as device health, location, transaction sensitivity, and re-authentication at critical actions. Best practice is evolving toward risk-based authentication, but there is no universal standard for this yet. Current guidance suggests that MFA should be paired with detection for impossible travel, anomalous approval bursts, and help desk reset abuse.
- Track prompt-to-login ratios and approval frequency by user, device, and location.
- Alert on repeated prompts in short windows, especially after failed phishing attempts.
- Require step-up verification for privileged actions, not just initial sign-in.
- Review whether help desk flows can be used to bypass the second factor.
NHIMG research on DeepSeek breach and Microsoft Midnight Blizzard breach shows how access control breakdowns become material once attackers can move from one valid touchpoint to another. These controls tend to break down when phishing is paired with session replay or when users are conditioned to approve repeated prompts because the process has become part of daily work.
Common Variations and Edge Cases
Tighter MFA often increases user friction and support load, requiring organisations to balance stronger verification against login fatigue and business interruption. That tradeoff is real, especially in high-frequency workflows where users may authenticate many times per day.
Some environments need exceptions. Shared workstations, call centres, and emergency operations may rely on different challenge patterns because a normal push-based experience can be too slow or too easy to condition. In those settings, current guidance suggests moving away from repeated generic prompts and toward stronger device binding, phishing-resistant methods, or transaction-level verification. The important point is that MFA should not be treated as one control with one success metric.
There are also edge cases where the problem is not the factor itself but the surrounding process. If account recovery is weak, attackers may bypass MFA by targeting resets. If the organisation lacks risk telemetry, it may miss unusual approvals that indicate compromise. And if privileged users receive the same challenge as low-risk users, the control may be under-calibrated for the accounts that matter most. The practical test is simple: if a user can approve a prompt without understanding why it appeared, the organisation has already lost signal.
Where MFA is layered over legacy apps, VPNs, or brittle federation flows, the control often fails silently because exceptions accumulate faster than policy can be enforced.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0, NIST SP 800-63, NIST Zero Trust (SP 800-207) and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AA-2 | Authentication outcomes should be monitored for weak or bypassed MFA behaviour. |
| NIST SP 800-63 | AAL2 | Assurance level helps judge when MFA is strong enough for the access being protected. |
| NIST Zero Trust (SP 800-207) | Verify explicitly | Zero Trust requires continuous verification, not one-time login trust. |
| OWASP Non-Human Identity Top 10 | NHI-05 | Weak authentication workflows can enable account takeover and misuse of privileged identities. |
| NIST AI RMF | The govern and manage functions support continuous control effectiveness review. |
Instrument MFA telemetry and review it for approval fatigue, anomalies, and bypass patterns.
