AuthQuake shows why MFA implementation details still decide risk

At a glance

What this is: This is an analysis of the AuthQuake MFA bypass flaw and its key finding: small implementation mistakes in TOTP validation can turn MFA into a materially weaker control.

Why it matters: It matters because IAM teams cannot treat all MFA methods as equivalent, and control design choices directly affect human identity assurance, account takeover resistance, and the migration path to passkeys.

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.

👉 Read Descope’s analysis of the AuthQuake MFA bypass and passkey implications

Context

MFA is only as strong as the way it is implemented, not the acronym itself. In this case, the governance gap sits in human identity assurance: if one-time codes stay valid too long and retry controls are weak, the second factor stops behaving like a meaningful barrier.

That matters for IAM programmes because many organisations still evaluate MFA at the policy level rather than the protocol and session-control level. The article shows how a familiar control can fail through timing and rate-limit design, which is exactly where identity teams need to look when they compare TOTP, push, and passkey options.

Key questions

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. Long acceptance windows give attackers more time to test codes, while weak retry limits let them keep trying by resetting sessions or running parallel attempts. The result is a bypass path that can succeed without user prompts, which is exactly why implementation details matter more than the label MFA.

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. OTP still depends on a code that travels through a vulnerable channel, while passkeys prove possession of a private key without revealing it. That removes the easiest path for credential replay and code theft.

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. Pair that with risk-based step-up, strong offboarding, and continuous review of fallback access. The goal is to make takeover harder without turning authentication into a usability failure.

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.

Technical breakdown

How TOTP validity windows create a bypass surface

Time-based one-time password systems depend on short-lived code validity and synchronized verification. When a code remains valid for minutes instead of seconds, the attack window expands enough for repeated attempts to become practical. The issue is not the mathematical design of TOTP itself but the implementation layer that determines how long the server accepts a code and how it handles repeated validation requests. In AuthQuake, the longer validity window turned a narrow authentication control into a usable bypass path.

Practical implication: review TOTP server-side acceptance windows, not just user-facing enrolment guidance.

Why parallel login attempts defeat weak failure handling

Rate limiting is supposed to slow repeated guessing, but it only works when the limit applies to the right object and survives session regeneration. If an attacker can create fresh temporary sessions and send many attempts in parallel, the control becomes fragmented. That is what made AuthQuake effective: the failure threshold existed, but it did not constrain the overall authentication sequence tightly enough. The result was a bypass path that needed patience rather than sophistication.

Practical implication: enforce rate limits at the identity and device boundary, not just the temporary session object.

Why passkeys remove the timing attack class entirely

Passkeys use public-private key cryptography rather than shared codes, so there is no reusable secret to extend, replay, or brute force within a time window. The private key stays on the device, and the server verifies a cryptographic signature instead of comparing a numeric code. That changes the authentication model from time-dependent verification to proof-of-possession. For identity teams, the key point is that some MFA risks are not fixable by tuning a TOTP policy because the mechanism itself is the problem.

Practical implication: treat passkeys as a control-class change, not just another MFA option.

NHI Mgmt Group analysis

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.

TOTP is a policy-dependent control, passkeys are a mechanism shift. TOTP can remain acceptable in some environments, but only when its lifetime, session binding, and failure handling are engineered tightly. Passkeys remove the time-window dependency altogether, which means they address a different class of assurance problem. That distinction matters for migration planning because many organisations still compare them as if they were interchangeable. They are not.

Human identity assurance now depends on control design at the edge of authentication, not on brand-name factors. Users will still experience MFA as one more login step, but attackers experience it as a sequence of validation rules to test. That mismatch is where bypasses happen. Security architects should therefore assess factor choice together with rate limiting, notification behaviour, and session lifecycle, because those are the conditions that determine whether the factor actually holds.

AuthQuake sharpens a named concept: MFA implementation debt. The debt accumulates when identity teams assume that a standard control remains effective even after local implementation decisions weaken it. Extended windows, weak throttling, and temporary session reuse all add hidden risk that is not visible from policy documents alone. The practical conclusion is that control assurance must be tested where the authentication transaction actually runs.

From our research:

• 98% of companies plan to deploy even more AI agents within the next 12 months, despite documented rogue behaviour in 80% of current deployments, according to AI Agents: The New Attack Surface report.
• Only 52% of companies can track and audit the data their AI agents access, leaving 48% with a complete blind spot for compliance and breach investigation.
• For a broader governance baseline, see Ultimate Guide to NHIs for lifecycle, visibility, and access control patterns that apply across identity types.

What this signals

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.

Passkeys should now be treated as a roadmap item for high-risk populations, especially where phishing resistance and account takeover resistance are board-level concerns. As identity estates mature, the useful comparison is no longer old MFA versus new MFA, but shared-secret authentication versus cryptographic proof of possession.

For a broader governance baseline, the Ultimate Guide to NHIs remains useful for teams that need to align authentication controls with lifecycle and access-review discipline across humans, service accounts, and other non-human identities.

For practitioners

• Audit TOTP acceptance windows Check server-side code validity periods, retry thresholds, and whether the same session state can be regenerated during repeated attempts. Treat any code lifetime materially longer than the standard 30-second window as a control weakness, not a configuration preference.
• Move rate limiting to the identity transaction layer Apply throttling so it survives session regeneration and cannot be reset by creating parallel authentication objects. Make the limit bind to the account, device, and risk event rather than only to a temporary session record.
• Prioritise passkey migration for high-risk populations Target privileged users, administrators, and externally exposed workforces first. Passkeys remove the shared-secret and time-window dependence that made AuthQuake viable, so they reduce both phishing exposure and timing-based bypass paths.
• Test MFA controls under parallel attack conditions Include rapid-fire requests, distributed attempts, and session reset behaviour in validation testing. If the control only works against sequential failures, it is not resilient enough for real adversary behaviour.

Key takeaways

• AuthQuake shows that MFA can fail through implementation details even when the underlying control family is sound.
• The practical risk came from extended code lifetimes, weak throttling, and the ability to keep trying without user visibility.
• Security teams should treat passkeys and tighter server-side enforcement as structural responses, not cosmetic upgrades.

Key terms

• One-Time Password: A one-time password is a short-lived authentication code used once, then discarded. It usually supplements a primary password as a second factor, but its security depends heavily on how the code is generated, delivered, and recovered if the user loses access.
• Passkey: A passkey is a passwordless credential based on public key cryptography. A private key stays on the user’s device, while a public key is stored by the service. During login, the device signs a challenge after local unlock, which reduces phishing and eliminates shared secret reuse.
• Authentication Assurance: The degree of confidence that an identity has been verified to the intended standard before access is granted. For MFA, assurance depends on the whole enforcement chain, including session handling, retry policy, and telemetry, not merely the presence of a code prompt.

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.

👉 Descope’s full post covers the exploit mechanics, login success rate, and why passkeys change the authentication model.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or identity lifecycle management, it is worth exploring.