Because MFA is not a single control, it is a control design. If the factor relies on push approval, secret sharing, or user attention under pressure, an attacker can still manipulate the process after stealing credentials. Organisations remain exposed when MFA is treated as a checkbox instead of a trust model with risk-based enforcement.
Why This Matters for Security Teams
MFA reduces the value of stolen passwords, but it does not automatically stop account takeover when the attacker can exploit the second factor, the enrolment flow, or the recovery path. That is why security teams still see compromise after “MFA rollout” when the deployment is built around convenience rather than adversary resistance. The issue becomes sharper as identities expand beyond people: NHI Mgmt Group notes that 80% of identity breaches involved compromised non-human identities such as service accounts and API keys in its Ultimate Guide to NHIs.
The same pattern appears in human identity attacks. A thief can trigger push fatigue, intercept SMS, abuse session tokens, or hijack a help-desk reset process. Guidance from the CISA phishing-resistant MFA guidance makes the key point: not all MFA is equal, and some factors are materially easier to defeat than others. In practice, many security teams only discover this after a user or privileged account has already been reused to move laterally.
How It Works in Practice
Modern MFA should be treated as one layer in a broader trust model, not as a binary gate. The strongest deployments pair phishing-resistant factors with conditional access, device posture checks, session controls, and step-up verification for sensitive actions. That means the system evaluates who is authenticating, from where, on what device, and what they are trying to do before allowing access. The NIST SP 800-63B guidance is clear that authenticators differ in assurance and that higher-risk use cases need stronger factor choices.
For operational teams, the practical order is usually:
- Replace push-based or SMS-based approval with phishing-resistant methods where possible.
- Bind MFA to device trust, session risk, and geo-anomaly signals.
- Require step-up checks for privilege elevation, payments, secret access, and admin changes.
- Shorten session lifetime so a stolen token cannot remain useful for long.
- Review recovery and support processes, because those are often the weakest bypass path.
This matters because identity compromise is often driven by credential and token abuse, not just password guessing. NHI Mgmt Group’s 52 NHI Breaches Analysis shows how frequently identity failures cascade into broader access issues, especially where secrets and session material are not tightly governed. Current guidance suggests that MFA without phishing resistance, session binding, and recovery hardening is a control with gaps, not a complete defence.
These controls tend to break down in environments with legacy protocols, shared admin accounts, or high-volume service desk resets because the process around MFA becomes easier to attack than the factor itself.
Common Variations and Edge Cases
Tighter MFA often increases friction for users and support teams, so organisations must balance stronger assurance against operational overhead. That tradeoff is real, especially where contractors, third parties, or legacy applications cannot support modern authenticators.
There is also no universal standard for every environment yet. Best practice is evolving toward phishing-resistant MFA for privileged users, but some workloads still rely on fallback methods that are weaker by design. In those cases, policy should explicitly mark the exception, limit what the account can reach, and add compensating controls such as PAM, just-in-time elevation, and short-lived sessions. The Anthropic report on AI-orchestrated cyber espionage is a reminder that attackers increasingly automate reconnaissance and abuse at scale, which makes weak MFA workflows faster to find and easier to exploit.
The hardest cases are service accounts, automation credentials, and delegated access chains. MFA does not solve those directly, because those identities need lifecycle governance, secret rotation, and workload authentication rather than human challenge flows. In those environments, organisations should not assume MFA creates trust by itself.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10 address the attack and risk surface, while NIST CSF 2.0 and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | A2 | Covers auth bypass and insecure access flows, relevant to MFA weakness patterns. |
| NIST CSF 2.0 | PR.AC-7 | Addresses authentication and access enforcement across users and systems. |
| NIST AI RMF | Useful for risk-based controls and contextual decisioning at runtime. |
Harden authentication flows, recovery paths, and session handling against bypass and manipulation.
