Because many implementations are still easier to intercept, fatigue, or bypass than teams assume. Attackers focus on MFA where they can exploit push approval habits, non-phishing-resistant factors, or weak recovery processes, so the control needs to be evaluated by assurance level, not by presence alone.
Why This Matters for Security Teams
Conventional MFA is often treated as a binary safeguard, but attackers target the control because many deployments still rely on user actions that can be manipulated. Push approvals, SMS codes, weak help desk recovery, and inconsistent enforcement across applications all create opportunities for social engineering and session takeover. The issue is not that MFA is obsolete, but that assurance varies widely by factor type and implementation.
Security teams also need to distinguish between authentication strength and downstream session protections. If a phished token, stolen device session, or abused recovery workflow can still grant access, the presence of MFA provides only partial resistance. That is why current guidance from NIST SP 800-53 Rev 5 Security and Privacy Controls matters: controls should be implemented with attention to verification strength, enrollment, fallback paths, and monitoring, not just policy wording.
Attackers keep coming back to MFA because it is often the easiest high-value control to exploit at scale. In practice, many security teams encounter MFA abuse only after a convincing fatigue or recovery-led compromise has already occurred, rather than through intentional control validation.
How It Works in Practice
Attackers focus on MFA by finding the weakest point in the authentication chain, not necessarily the factor itself. Common paths include push bombing, real-time phishing proxy kits, help desk impersonation, session cookie theft, and abuse of legacy protocols that bypass stronger authentication. A mature assessment looks at the full flow: initial challenge, factor binding, enrollment, recovery, and re-authentication for sensitive actions.
Operationally, the question is whether the MFA deployment is phishing-resistant and resilient to recovery abuse. FIDO2 or passkey-based authentication is materially stronger than one-time codes or approval prompts, but even strong factors can be undermined if account recovery depends on predictable knowledge checks or weak support procedures. Security teams should also validate whether MFA is consistently enforced for privileged users, remote access, admin portals, and API access where applicable.
- Prioritise phishing-resistant methods for administrators and high-risk users.
- Disable or tightly restrict legacy authentication paths that do not support strong MFA.
- Harden recovery workflows with identity proofing, approval logging, and alerting.
- Detect repeated denials, unusual device prompts, and impossible travel anomalies.
- Correlate identity events with endpoint and network signals using MITRE ATT&CK Enterprise Matrix and SOC playbooks.
Threat intelligence can help prioritise which MFA abuse patterns matter most in a given environment, especially when paired with advisories from CISA cyber threat advisories. The control becomes far more effective when MFA telemetry is fed into detection engineering, privileged access reviews, and incident response procedures. These controls tend to break down in hybrid estates with legacy identity providers and inconsistent application integration because authentication assurance becomes uneven across systems.
Common Variations and Edge Cases
Tighter MFA often increases user friction and support overhead, requiring organisations to balance stronger assurance against operational convenience. That tradeoff matters, because blanket enforcement without workflow design can push users toward insecure exceptions or shadow approvals.
There is no universal standard for every environment yet, but best practice is evolving toward phishing-resistant MFA for privileged access, step-up authentication for risky transactions, and explicit controls for recovery. In high-friction environments such as call centres, outsourced support, or geographically distributed workforces, attackers often target the help desk rather than the login screen. In those cases, identity verification for recovery becomes as important as the primary MFA factor.
This is where identity governance intersects with broader cyber defence. MFA should be treated as one layer in a chain that includes device trust, session control, anomaly detection, and privileged access management. For emerging AI-assisted campaigns, the threat picture is broadening further: the Anthropic report on AI-orchestrated cyber espionage shows how automation can amplify reconnaissance and social engineering, while MITRE ATLAS adversarial AI threat matrix helps frame the adjacent risks when AI is used to scale attacker operations. Where MFA is paired with agentic workflows or automated support tooling, current guidance suggests extra scrutiny on approvals, delegation, and recovery exceptions.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK address the attack and risk surface, while NIST CSF 2.0 and NIST SP 800-63 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AA-03 | Authenticators and assurance levels are central to why MFA gets bypassed. |
| NIST SP 800-63 | AAL2 | MFA attacks often succeed where authentication assurance is too low. |
| MITRE ATT&CK | T1110 | MFA fatigue and abuse commonly support credential and login attack paths. |
Map MFA abuse to authentication attack techniques and tune detection for repeated prompt abuse.
