MFA Bypass Attacks: Identity Attacks, MFA Bypass and Token Theft Explained

What are MFA bypass attacks?

MFA bypass attacks are attempts to obtain the result of authentication without defeating every factor directly.** An attacker might steal a password first, persuade a user to approve an unexpected push, proxy a sign-in through an adversary-in-the-middle page, or capture a session token after a legitimate login. The common thread is that the attacker targets the surrounding identity workflow rather than treating MFA as a single lock that can only be picked.

CISA’s comparison is useful because it separates methods by how easily they can be phished. FIDO/WebAuthn and PKI-based methods are placed above app-generated OTPs, push notifications and SMS or voice methods in its phishing-resistance ranking. This does not make lower-ranked methods useless: they can still improve security compared with password-only access. It does mean that “MFA enabled” is incomplete information when an organisation is deciding how to protect administrators, financial systems or sensitive data. (CISA, “Implementing Phishing-Resistant MFA.”)

NIST makes a similar point in its current small-business guidance. It says OTPs and SMS codes can be susceptible to phishing and identifies FIDO authenticators using W3C Web Authentication as the most common widely available phishing-resistant authenticators. NIST recommends phishing-resistant authentication for sensitive data and elevated-privilege users. The control choice should therefore follow the consequence of account compromise, not just the convenience of the first available second factor. (NIST, “Multi-Factor Authentication.”)

For readers building a broader defensive programme, this topic connects directly with [phishing-resistant MFA guidance](https://cyberoinfo.com/cybersecurity/phishing-resistant-mfa) and [cloud security controls](https://cyberoinfo.com/cybersecurity/cloud-security). The goal is to understand the attack path clearly: initial credential access, attempted approval or interception, session establishment, persistence and post-compromise activity.

How MFA bypass attacks exploit identity workflows

The most important identity attacks exploit human approval, protocol choices or trust relationships.** In adversary-in-the-middle phishing, a victim may interact with a page that relays a real sign-in flow. The attacker’s objective can be to obtain credentials or a session artefact while the user believes they are completing a normal login. CISA describes phishing as one way MFA credentials can be exposed; the lesson is to prefer an authenticator that verifies the legitimate origin as part of the protocol. (CISA, “Implementing Phishing-Resistant MFA.”)

MFA fatigue, also called push bombing, takes a different route. Repeated prompts may pressure a user into approving one that was not initiated by them, or into accepting an unexpected request simply to stop the interruptions. Microsoft’s Secure Future Initiative guidance describes social engineering, man-in-the-middle tactics and MFA bombing against SMS codes, email OTPs and push notifications. The defensive response is not to remove MFA, but to reduce approval ambiguity, use stronger methods and investigate unexpected prompts. (Microsoft, “Phishing-resistant MFA.”)

Device-code phishing is another important path. CERT-In’s advisory CIAD-2026-0037 describes phishing-as-a-service activity in which a user may be induced to enter or approve a device code. In the advisory’s recommended framing, this can result in the user authorising an attacker-controlled session on a legitimate Microsoft sign-in page. That is materially different from a claim that the underlying passkey or cryptographic method has been universally bypassed. (CERT-In, Advisory CIAD-2026-0037.)

The same CERT-In advisory also describes password spraying, credential stuffing, rogue-device registration, Conditional Access gaps and trusted-supplier compromise. These paths show why identity defence needs more than a login prompt: administrators need to examine device registration, OAuth grants, mailbox rules and unusual sessions. They also need to consider how a compromised supplier or account could create trusted-looking activity. CERT-In presents these as observed campaign patterns, not as a quantified India-wide ranking.

How token theft turns a sign-in into account takeover

Token theft matters because an attacker may not need to repeat the original MFA step if they can replay a valid session or misuse an OAuth token.** A session token represents an already-established authentication state. If it is stolen from a browser, endpoint, proxy flow or another exposed location, the attacker may attempt to use that state before it expires or is revoked. This is why token theft is a separate problem from password theft and a separate question from whether MFA was present at the first sign-in.

CERT-In’s 2026 advisory explicitly includes stolen session-token replay and OAuth access or refresh-token theft among the identity-attack paths it discusses. It recommends monitoring OAuth activity, device registration and session anomalies, alongside stronger authentication. The practical implication is that an identity team should treat suspicious token or grant activity as a possible active session compromise, not merely as a failed-password event. (CERT-In, Advisory CIAD-2026-0037.)

Once an attacker has access, the impact can extend beyond the first mailbox or application. CERT-In says compromised Microsoft 365 accounts were used for business email compromise, data exfiltration, persistence, financial fraud and extortion. The advisory does not provide a national victim count or prevalence estimate, so the safe conclusion is about capability and response priorities: revoke or invalidate risky sessions and grants, inspect mailbox rules and device registrations, and then investigate what the identity accessed. (CERT-In, Advisory CIAD-2026-0037.)

Token protection also belongs in the same operational conversation as [API security](https://cyberoinfo.com/cybersecurity/api-security) and [privacy and data-breach readiness](https://cyberoinfo.com/cybersecurity/privacy-data-breaches). In both cases, the useful question is not only “How did the attacker get in?” but also “Which credentials, tokens, grants, devices and data paths must be contained now?”

Why passkeys change the MFA bypass equation

Passkeys reduce several common phishing paths because they use origin-bound public-key authentication rather than asking a user to disclose a reusable code.** Google describes passkeys as sign-in using a fingerprint, face scan or screen lock, with the passkey stored on a local device or security key. The private key is used by the authenticator while the service verifies the corresponding public-key proof. This model changes what a phishing page can collect compared with a password or OTP. (Google Safety Center, “Passkey.”)

FIDO2 and WebAuthn are therefore central to the phishing-resistant MFA discussion. A passkey can reduce credential-phishing and OTP-interception paths because the authentication is bound to the legitimate origin. That is why NIST identifies FIDO authenticators using W3C Web Authentication as widely available phishing-resistant authenticators, and why CISA places FIDO/WebAuthn above phishable methods in its comparison. (NIST, “Multi-Factor Authentication”; CISA, “Implementing Phishing-Resistant MFA.”)

Passkeys are not a promise that every identity attack disappears. Google’s explanation supports strong protection against phishing, but it does not say that account recovery, compromised endpoints, malicious browser extensions, stolen sessions, unsafe device registration or a compromised identity provider become impossible. Recovery paths must receive the same scrutiny as the main sign-in path, especially for administrator and high-value accounts. (Google Safety Center, “Passkey.”)

A balanced rollout therefore compares passkeys with the current threat model rather than presenting them as a universal substitute for identity governance. Keep break-glass and recovery processes controlled, record which devices are enrolled, monitor unusual authenticator changes and pair phishing-resistant sign-in with [software supply-chain security](https://cyberoinfo.com/cybersecurity/software-supply-chain) where suppliers and delegated access are part of the trust boundary.

A practical defensive checklist for MFA bypass attacks

The strongest defence against MFA bypass attacks is a layered identity control set.** Start by prioritising phishing-resistant authentication for administrators, elevated-privilege users and access to sensitive data. NIST recommends that direction, while CISA identifies FIDO/WebAuthn and PKI-based methods as stronger choices than app OTP, push and SMS or voice methods. Where a phased rollout is necessary, document which accounts still rely on phishable methods and what compensating controls protect them. (NIST, “Multi-Factor Authentication”; CISA, “Implementing Phishing-Resistant MFA.”)

Next, close avoidable protocol and policy gaps. CERT-In recommends enforcing MFA, disabling legacy authentication such as ROPC where unnecessary, restricting device-code authentication, adopting FIDO2, Windows Hello or certificate-based methods, and strengthening Conditional Access. These controls should be tested against real sign-in journeys, including remote access, service accounts, recovery, new-device registration and delegated applications. A policy that exists only on paper cannot stop an identity path it does not evaluate. (CERT-In, Advisory CIAD-2026-0037.)

Then monitor what happens after authentication. Review OAuth access and refresh-token activity, new device registrations, unusual session locations or patterns, mailbox-rule changes, unexpected consent grants and repeated MFA prompts. Microsoft’s guidance points to Conditional Access and phishing-resistant MFA, while CERT-In highlights OAuth, device-registration and session anomalies. Monitoring should create an actionable investigation record rather than an unprioritised stream of alerts. (Microsoft, “Phishing-resistant MFA”; CERT-In, Advisory CIAD-2026-0037.)

Finally, rehearse containment and recovery. A response plan should identify who can revoke sessions, invalidate tokens, remove malicious OAuth grants, disable rogue devices, reset credentials, protect recovery channels and preserve relevant logs. Treat a suspected token replay as a session-security event even when the password has already been changed. Account recovery, help-desk verification and supplier access should be tested because an attacker may use those paths after the primary account is secured.

FAQ: identity attacks, MFA bypass and token theft

Can MFA be bypassed?** Some MFA implementations can be bypassed or undermined through phishing, push bombing, device-code phishing, SIM-related attacks, recovery abuse or session-token theft. That does not make MFA pointless. CISA and NIST continue to recommend MFA while distinguishing phishable methods from phishing-resistant FIDO/WebAuthn-based authentication. (CISA, “Implementing Phishing-Resistant MFA”; NIST, “Multi-Factor Authentication.”)

Do passkeys stop identity attacks?** Passkeys can strongly reduce credential-phishing and OTP-interception paths because they use origin-bound public-key authentication. They do not remove every endpoint-compromise, recovery, device-registration, session or identity-provider risk. Passkeys should be deployed as part of layered identity protection, not as a claim that every attack path is closed. (Google Safety Center, “Passkey.”)

What is device-code phishing?** It is a technique in which a user is persuaded to enter or approve a device code during a sign-in flow. CERT-In describes a 2026 case pattern in which this can authorise an attacker-controlled session on a legitimate Microsoft sign-in page. Restricting device-code authentication where it is unnecessary and monitoring related activity are among the advisory’s recommendations. (CERT-In, Advisory CIAD-2026-0037.)

What should an organisation do after suspected token theft?** Treat it as a possible active-session compromise. Investigate and revoke risky sessions and OAuth grants, review new devices and mailbox rules, check access to sensitive systems, rotate affected credentials and preserve logs. The exact sequence depends on the identity platform, but changing a password alone may not remove a stolen session or refresh token. CERT-In specifically calls for monitoring OAuth, device registration and session anomalies. (CERT-In, Advisory CIAD-2026-0037.)

Limitations

• Evidence and guidance can change; verify current advisories and organisational applicability before acting.

Evidence sources

1. cisa.gov — CISA, Implementing Phishing-Resistant MFA (October 2022)
2. nist.gov — NIST, Multi-Factor Authentication (updated January 5, 2026)
3. safety.google — Google Safety Center, Passkey
4. learn.microsoft.com — Microsoft, Phishing-resistant MFA (Secure Future Initiative)
5. cert-in.org.in — CERT-In, Advisory CIAD-2026-0037 (August 7, 2026)