Watch for repeated phishing success, MFA fatigue attacks, and weak factor choices such as SMS or email codes. If users still rely on passwords as the first factor, attackers can target the weakest step in the chain. Rising password reset volume, account lockouts, and pressure on helpdesk support also suggest the current model is creating friction without enough security gain.
When MFA stops matching the threat model
The clearest sign is not that MFA is absent, but that attackers can repeatedly move around it. If phishing kits, push fatigue, or adversary-in-the-middle tooling keep working, the deployment is protecting the login screen while leaving the session, factor choice, or recovery path exposed. The question is whether the control still meaningfully changes attacker effort, not whether it exists on paper.
Weak factor choices are a second signal. SMS and email codes are still better than passwords alone, but they are easier to intercept, redirect, or socially engineer than phishing-resistant authenticators. Where passwords remain the first factor, MFA may be acting as a speed bump rather than a durable control, especially against high-volume credential stuffing and targeted takeover attempts.
Modern guidance increasingly treats phishing-resistant authentication as the baseline for high-value accounts. NIST SP 800-63 Digital Identity Guidelines is a useful reference point for what stronger assurance looks like, including authenticator strength and resistance to phishing. Where your current MFA stack cannot distinguish a real user challenge from an attacker-controlled relay, it is already falling behind current threat methods.
Operational symptoms that the control is creating friction, not assurance
Rising password reset volume, repeated account lockouts, and growing helpdesk pressure are practical indicators that users are struggling with the current design. That does not automatically mean the control is weak, but it does mean the workflow may be expensive, confusing, or brittle enough that users start working around it. A control that drives bypass behaviour is usually weaker than its policy text suggests.
Look closely at where the failures happen. If most incidents cluster around onboarding, recovery, or exception handling, the problem may not be the second factor itself but the surrounding process. If users can recover access through identity proofing that is easier to socially engineer than the MFA challenge, the attacker will simply target the softest path into the account.
Repeated MFA prompts can also signal poor session handling or over-broad reauthentication rules. When the system asks too often, users become conditioned to approve prompts without thinking. At that point, friction starts to erode attention, and the human response becomes part of the attack surface rather than a defense.
What a weakening MFA posture usually looks like in practice
A deployment is usually no longer strong enough when at least one of these is true: attackers can phish the factor, flood users with prompts, reuse stolen session material, exploit weak recovery, or bypass MFA through support workflows. That is the point where the control has to be re-scoped, not merely documented.
- Factor quality is inconsistent across user groups, with privileged users still on weaker methods than the risk warrants.
- Recovery and reset paths are easier to abuse than the normal login path.
- Users are approving challenges without context because prompt volume is too high.
- Security teams see takeover attempts even when MFA is nominally enabled.
Attackers also adapt to the control mix. Reports of fatigue attacks, token theft, and relay-style phishing show that the weak point is often the path from authentication to session issuance, not the presence of a second prompt. For a recent adversary view of how phishing-resistant controls are being bypassed in practice, see the CISA cyber threat advisories.
Risk and Threat Considerations
When MFA no longer withstands current attacker methods, the exposure shifts from login friction to account takeover, privilege abuse, and downstream access to sensitive systems. The main risk is not just that one account is compromised, but that the compromise can now happen through predictable human and process weaknesses.
Failure mechanism: Attackers succeed by phasing around the strongest step, using phishing, push fatigue, weak recovery, or token/session theft to convert a nominal MFA check into unauthorized access.
Impact: The organisation loses the assurance it thought it had, and the account becomes easier to abuse for data access, internal tooling, lateral movement, or persistent re-entry.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack and risk surface, while NIST SP 800-63, NIST SP 800-53 Rev 5 and OWASP ASVS set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-63 | Digital Identity Guidelines | Phishing-resistant authentication and authenticator strength are central to MFA adequacy. |
| Recommendation — Adopt phishing-resistant authenticators for high-risk users and verify assurance level matches account risk. | ||
| MITRE ATT&CK | T1110 — Brute Force | Credential abuse and repeated login attempts help explain when MFA is being stressed or bypassed. |
| Recommendation — Map takeover attempts to credential-access techniques and harden detection around repeated auth failures. | ||
| NIST SP 800-53 Rev 5 | IA-2 — Identification and Authentication (Organizational Users) | User authentication strength and factor choice determine whether MFA still provides adequate assurance. |
| IA-5 — Authenticator Management | Factor lifecycle, reset, and recovery weaknesses often reveal why MFA no longer holds up. | |
| Recommendation — Require stronger authenticators for sensitive users and validate authentication flows against real attacker methods. Tighten authenticator issuance, rotation, recovery, and revocation to reduce bypass opportunities. | ||
| OWASP ASVS | V6 — Authentication | Authentication assurance, factor choice, and recovery behavior are core to whether MFA remains strong enough. |
| Recommendation — Test authentication and recovery flows for phishing resistance, factor strength, and replay exposure. | ||
Practitioner Guidance
What to verify: Separate “MFA enabled” from “MFA effective.” Test whether your highest-risk accounts use phishing-resistant factors, whether recovery paths are stronger than the login path, and whether helpdesk-assisted resets require equal or stronger assurance than the original authentication flow.
Decision rule: If an attacker can get a valid session through phishing, prompt abuse, or recovery abuse, treat the deployment as insufficient for that population even if the policy says MFA is present. At that point the control problem is factor strength, recovery design, and session protection, not user compliance alone.
Practitioner takeaway: Strong MFA is defined by the weakest path an attacker can still use, not by the strongest factor you have deployed somewhere in the stack.
Related resources from NHI Mgmt Group
- What are the signs that legacy MFA is no longer strong enough against modern phishing attacks?
- What are the signs that DLP rules are no longer accurate enough for current data flows?
- What happens when encrypted password data is stolen but the master password is strong enough?
- How can organisations tell whether their MFA programme is actually strong enough?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 25, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
