Notifications
Clear all
Topic starter
02/09/2026 1:29 pm
TL;DR: Phishing-resistant MFA closes push fatigue and adversary-in-the-middle session theft, but Trusona argues the reset desk remains the bypass that defeats many deployments because recovery sits outside the authentication stack. The real governance gap is identity proofing for human-driven resets, not stronger factors alone, and that gap now determines whether MFA is actually resilient.
NHIMG editorial — based on content published by Trusona: MFA fatigue, MFA bypass, and the reset desk: three ways MFA actually fails
By the numbers:
- Mandiant found voice phishing involved in 11% of all intrusions and 23% of cloud intrusions, where it ranked first.
Questions worth separating out
Q: What breaks when phishing-resistant MFA is deployed but reset workflows stay unchanged?
A: The control fails at the recovery boundary.
Q: Why do reset-desk attacks still work when strong MFA is already in place?
A: Because the attacker stops attacking the factor and starts attacking the person who can reset it.
Q: How can security teams measure whether MFA is resisting abuse?
A: Teams should watch for repeated prompts, unusual registration changes, help-desk impersonation reports, and successful approvals outside normal user behaviour.
Practitioner guidance
- Instrument MFA prompt volume and approval behaviour Track repeated prompts per account, per hour, and alert when a single user receives a burst of notifications followed by one approval.
- Prioritise origin-bound authentication for high-risk applications Move administrative and high-value user populations to passkeys or FIDO2 security keys so the credential is bound to the real origin and cannot be relayed through an attacker-controlled proxy.
- Govern help-desk resets as privileged actions Require identity proofing before a factor is deleted or re-enrolled, correlate ticketing events with authenticator changes, and revoke active sessions when a reset follows suspicion of compromise.
What's in the full article
Trusona's full blog covers the operational detail this post intentionally leaves for the source:
- The help-desk reset workflow and where the identity decision sits in each platform.
- Trusona's examples of anti-replay and man-in-the-middle detection in reset verification.
- The per-platform procedures for clearing, transferring, and re-enrolling MFA factors.
- The ATO Protect reset flow and how it verifies identity before enrolment changes.
👉 Read Trusona's analysis of MFA fatigue, session theft, and reset-desk bypasses →
MFA fatigue, session theft, and reset-desk bypasses: what fails now?
Explore further
02/09/2026 1:30 pm
MFA is not one control, it is three governance surfaces. The article correctly separates prompt fatigue, session theft, and reset-desk abuse because each lives at a different control boundary. That distinction matters for IAM programme design: success at the credential layer can coexist with failure at the recovery layer. Practitioners should stop reporting MFA as a single coverage metric and model the full authentication lifecycle.
A few things that frame the scale:
- Mandiant found voice phishing involved in 11% of all intrusions and 23% of cloud intrusions, where it ranked first, according to The State of Secrets in AppSec.
- The average estimated time to remediate a leaked secret is 27 days, despite 75% of organisations expressing strong confidence in their secrets management capabilities.
A question worth separating out:
Q: Why does help desk identity verification belong in IAM governance?
A: Because support staff can become an attack path when recovery and reset workflows rely on weak proofing. If an attacker can socially engineer the help desk, they can often bypass stronger sign-in controls indirectly. IAM teams should govern support workflows as privileged identity processes, with the same scrutiny used for elevated access.
👉 Read our full editorial: MFA still fails at the reset desk, even with phishing-resistant controls
