Notifications
Clear all
Topic starter
19/08/2026 3:38 pm
TL;DR: A Microsoft MFA flaw dubbed AuthQuake could have let attackers bypass second-factor checks in under 70 minutes with no prompts and a 50% success rate, according to Descope’s analysis of Oasis Security research. The lesson is that MFA strength depends on implementation details, and TOTP timing windows, retry limits, and passkey adoption now matter more than generic MFA claims.
NHIMG editorial — based on content published by Descope: AuthQuake Bypass Shows Not All MFA Is Equal
By the numbers:
- A critical vulnerability in Microsoft’s MFA infrastructure could have affected over 400 million users.
- The exploit could bypass the second auth factor in under 70 minutes with no user prompts.
- The researchers reported a 50% login success rate by combining extended validity windows with unlimited parallel attempts.
Questions worth separating out
Q: What breaks when TOTP MFA uses long validity windows and weak retry limits?
A: The control stops behaving like a genuine second factor and becomes a narrow delay.
Q: Why do passkeys reduce account takeover risk more effectively than OTP?
A: Passkeys reduce takeover risk because they rely on public-key cryptography rather than shared secrets that can be phished or intercepted.
Q: How should organisations reduce MFA-related account takeover risk?
A: Start by replacing the weakest factors on the highest-risk accounts, then remove recovery paths that depend on shared secrets or easily intercepted delivery channels.
Practitioner guidance
- Audit TOTP acceptance windows Check server-side code validity periods, retry thresholds, and whether the same session state can be regenerated during repeated attempts.
- Move rate limiting to the identity transaction layer Apply throttling so it survives session regeneration and cannot be reset by creating parallel authentication objects.
- Prioritise passkey migration for high-risk populations Target privileged users, administrators, and externally exposed workforces first.
What's in the full article
Descope's full article covers the implementation mechanics this post intentionally leaves for the source:
- Researcher explanation of the extended TOTP validity window and how it changed the attack surface.
- Detailed discussion of the failure threshold, session regeneration, and why parallel attempts were possible.
- Comparison with passkeys and the cryptographic properties that remove timing-based bypass paths.
- The security testing observations that showed no user prompts or notifications during the bypass.
👉 Read Descope’s analysis of the AuthQuake MFA bypass and passkey implications →
MFA bypass risk in practice: are your controls really equal?
Explore further
View Full Forum → | NHI Foundation Course → | Our Services →
19/08/2026 4:18 pm
Not all MFA is equal because implementation quality defines assurance. The AuthQuake case is not a failure of MFA as a category, but a failure of TOTP implementation discipline. When validity windows stretch and retries are not bounded correctly, the second factor becomes a delay mechanism rather than a control. For IAM teams, the right question is no longer whether MFA exists, but whether the chosen method still provides real resistance to automated abuse.
MFA assurance is increasingly a control engineering problem, not a feature-selection problem. IAM programmes that still score MFA by vendor category will miss the operational details that decide whether the factor can be bypassed under load. The right next step is to test throttling, notification behaviour, and session binding together, then fold those findings into access policy and assurance reporting.
A question worth separating out:
Q: What should IAM teams do first after finding a weak MFA implementation?
A: Reassess the exposed population, tighten server-side throttling, and accelerate migration for privileged and externally reachable users. The immediate goal is to remove the easiest bypass path while you redesign the longer-term authentication standard. In practice, that means treating the flaw as both a security incident and an identity design problem.
👉 Read our full editorial: AuthQuake shows why MFA implementation details still decide risk
