How Cybercriminals Exploit Weak OTP: The Attacker Playbook (2026)

How do attackers actually defeat OTP in practice? Not by breaking the math behind the code — by taking a different route to it. Four techniques account for nearly every real-world OTP bypass: SIM swapping ports the victim's phone number to an attacker's SIM so SMS codes arrive on the wrong device; real-time phishing with adversary-in-the-middle (AiTM) relay proxies the login page and captures a genuine code as the victim types it; SS7 interception abuses telecom signaling to redirect or read SMS in transit; and MFA fatigue floods the victim's device with push prompts until exhaustion produces an approval. None of these attacks skip the OTP step — they all get a real, validly-issued code or approval and use it before it expires. That distinction matters, because it means the fix isn't a stronger code. It's a different kind of credential.

This is the 2026 update to an earlier Avatier piece on cybercriminals and weak OTP, which focused on predictable OTP generators, unencrypted delivery, and session-management gaps. Those failure modes still exist in poorly built systems, but the attacks enterprises actually encounter in the field today center on the delivery channel and the human approving the login, not the generator algorithm — which is why this version rebuilds the piece around SIM swap, AiTM relay, SS7, and fatigue bombing instead.

Four techniques, one shared logic: none of them try to guess the code — they all intercept it, redirect it, or talk the victim into handing it over.

This is the companion piece to Does OTP Prevent Breaches? The Attacks It Actually Stops in 2026, which makes the defense-side case for OTP — the attack classes it reliably stops and how to deploy it so that prevention benefit actually shows up. That piece is worth reading alongside this one: it's the reason OTP isn't obsolete, and this piece is the reason it isn't sufficient on its own. Where that post argues from what OTP defeats, this one stays entirely on the attacker's side of the table — the techniques, the mechanics, and what they imply for what should replace OTP where it's exposed.

The SIM-swap playbook: hijacking the number, not the password

SIM swapping doesn't touch the target's device, password, or account directly. It targets the mobile carrier. An attacker assembles enough personal information about the victim — a name, date of birth, last four of a Social Security number, answers to common security questions — usually sourced from unrelated data breaches, data broker sites, or public social profiles, and uses it to convince a carrier's support channel that they are the account holder requesting a new SIM. Sometimes this works through pure social engineering against an overworked support rep; sometimes it works through an insider at the carrier willing to process the port for a fee. Either way, once the port completes, the victim's phone number is now live on a SIM the attacker physically holds.

From that point, anything sent to that number — SMS OTP codes, voice call verification, account recovery texts — arrives on the attacker's device. The victim's first symptom is usually a phone that suddenly loses signal ("no service") with no obvious cause, which by the time it's noticed and diagnosed has often already given the attacker a window to authenticate into whatever accounts use that number for OTP delivery or account recovery. This is why security teams that still allow SMS-based recovery or step-up on high-value accounts are, in effect, trusting the weakest link in a chain they don't control — a carrier support process the enterprise has no visibility into and no way to audit.

The defense implication is specific: SIM swapping is a reason to reduce dependence on the phone number as an identity anchor, not just a reason to "watch for suspicious SMS." Any account where SMS is the only second factor, or the only recovery path, inherits full exposure to a carrier-side social-engineering attack the account holder never even sees coming.

Real-time phishing and adversary-in-the-middle relay

If SIM swapping targets the channel, AiTM phishing targets the moment of authentication itself. The attacker stands up a proxy site — often via widely available phishing kits — that sits between the victim and the real login page. The victim receives a plausible pretext (a password-expiry notice, a shared-document link, an urgent IT request) and clicks through to what looks, pixel for pixel, like the legitimate login screen. They enter their username and password, which the proxy silently forwards to the real site. The real site responds the way it always does: it asks for the OTP code. The victim, still inside what they believe is the legitimate flow, enters the code too.

The proxy now holds a valid password and a valid, correctly-timed OTP code, and replays both against the real service within the few seconds or minutes the code remains valid. In many documented attack kits, the proxy goes a step further and captures the resulting session cookie once authentication succeeds, letting the attacker skip re-authentication entirely for as long as that session token is honored. From the victim's perspective, nothing looked wrong — they landed on a page that looked right, entered credentials that were requested at every step, and logged in successfully to what they thought was their real account.

This is the single most consequential entry on this list because it defeats both SMS OTP and most app-based TOTP the same way — the weakness isn't in how the code is delivered, it's in the fact that a code exists at all for a human to be tricked into typing into the wrong place. Push notifications without number-matching are similarly vulnerable in a related form: an AiTM flow that captures a password can trigger a push prompt on the real device, and a victim mid-phishing-flow who's already been primed to expect a verification step will often approve it without a second thought.

SS7 and telecom-level interception

SS7 — Signaling System 7 — is the protocol suite carriers have used since the 1970s to route calls and text messages between networks, including across international borders. It was designed for a small, closed circle of mutually trusted telecom operators, an assumption that hasn't scaled cleanly to the current global interconnection landscape, where SS7 access is available — legitimately or otherwise — to a much wider set of parties than the protocol's original trust model anticipated. Documented weaknesses in SS7 let an attacker with network-level access intercept, reroute, or read SMS messages in transit, including one-time passcodes, without ever touching the victim's phone, SIM card, or carrier account directly.

This is meaningfully different from SIM swapping and phishing in one important respect: it requires no interaction with the victim and no social engineering against a carrier support desk. The victim does everything right — strong password, no phishing click, no SIM-swap-enabling data exposure — and is still vulnerable, because the weakness sits in telecom infrastructure the enterprise and the end user both have zero visibility into or control over. That's also why SS7 interception is less common at the opportunistic, high-volume end of the threat landscape than SIM swapping or phishing kits — it demands specialized network access that isn't available to a typical criminal forum buyer — and shows up more often in targeted operations against high-value individuals: executives, journalists, political figures, and specific high-privilege enterprise accounts.

For enterprise security teams, the practical takeaway from SS7 isn't "expect this attack on a random employee." It's that SMS OTP carries a structural risk that no amount of user training, password hygiene, or phishing awareness eliminates, because the vulnerability lives in infrastructure between the carrier and the phone, not in anything the user or the enterprise directly controls.

OTP fatigue and MFA-bombing social engineering

MFA fatigue — also called push-bombing or MFA bombing — is different from the first three techniques in one important way: it doesn't intercept or relay anything. It exhausts a person. Once an attacker has a valid username and password — pulled from a breach dump, a phishing kit's harvest, or an infostealer log that scraped saved credentials off an infected device — they repeatedly initiate login attempts against the account. Each attempt fires a push-approval notification to the victim's enrolled device: "Approve sign-in?" Sent once, it's an easy no. Sent a dozen times in ten minutes, often late at night, it becomes a different kind of pressure.

Attackers frequently pair the barrage with a phone call or message impersonating internal IT: "We're seeing repeated login alerts on your account — go ahead and approve the next one so we can investigate and shut it off." A victim who's already annoyed, confused, or simply wants the notifications to stop taps approve. The resulting login is completely legitimate from the authentication system's point of view — a real user approved a real prompt on a real enrolled device. The system did exactly what it was designed to do; the attacker won by targeting the person's patience and trust rather than the cryptography.

This technique has driven several of the highest-profile enterprise intrusions of the past few years, precisely because it requires no technical sophistication beyond scripting repeated login attempts and picking up a phone. The direct countermeasures are specific and available today: number-matching (requiring the user to enter a number displayed on the login screen rather than tap a single approve button), strict rate limits on how many push prompts an account can receive in a given window, and moving any account that's been targeted once — or that carries elevated privilege — off single-tap push approval entirely.

Why SMS and voice OTP are structurally weaker

Three of the four techniques above — SIM swap, SS7 interception, and a meaningful share of AiTM and social-engineering variants — specifically exploit the fact that SMS and voice OTP route through a channel the enterprise doesn't control and the user doesn't fully control either: the carrier network and the phone number as an identity anchor. App-based TOTP removes two of those three exposures outright. A code generated locally on the device from a shared secret never travels over SMS, so there's nothing for a SIM swap or SS7 attacker to intercept — the attacker would need the device itself, not just the phone number.

That's a real, structural improvement, not a marginal one. But it isn't a complete fix, because AiTM phishing doesn't care where the code came from — it captures whatever the victim types into the fake login page, whether that's an SMS code, an app-generated TOTP code, or a backup code. The delivery channel determines exposure to SIM swap and SS7; it does nothing for exposure to real-time relay. That's the gap push notifications with number-matching close a little further (the victim has to actively transcribe a number rather than tap once) but still don't close entirely, because a sufficiently primed victim mid-phishing-flow can still be talked through matching the number correctly.

Delivery channel is a real variable, not a rounding error — SMS carries every exposure on this page, app-based methods close two of them, and only the top step closes all three.

The honest ranking, in order of resistance to the techniques above: SMS and voice OTP sit at the bottom, exposed to SIM swap, SS7, and AiTM alike. App-based TOTP and number-matched push sit meaningfully higher, closed off from SIM swap and SS7 but still exposed to a well-run AiTM proxy. FIDO2 and passkeys sit at the top, and the next section covers exactly why that's a structural difference rather than a matter of degree.

What "phishing-resistant" actually means

"Phishing-resistant" gets used loosely enough in vendor marketing that it's worth being precise about what it actually requires. A phishing-resistant credential is cryptographically bound to the origin domain it was registered against at enrollment. When a login attempt comes in, the browser or authenticator checks the requesting domain against that binding before releasing anything — and if the domain doesn't match (because the victim is on a proxy site at a different domain, however convincing the visual clone), the credential simply doesn't respond. There's no code, no push approval, no shared secret transmitted anywhere for an AiTM proxy to capture and replay, because nothing reusable ever leaves the device in the first place.

This is precisely why FIDO2 security keys and passkeys defeat every technique in this piece simultaneously rather than closing one gap at a time. SIM swap and SS7 are irrelevant because there's no SMS channel involved at all. AiTM relay fails because the origin-binding check rejects the phishing domain outright — the victim can be as thoroughly fooled visually as any phishing kit can manage, and the credential still won't authenticate against the wrong domain. MFA fatigue loses its mechanism because there's no repeatable approve/deny prompt to spam; the interaction is a single cryptographic exchange tied to the correct origin, not a decision a tired user can be worn down into approving incorrectly.

Each step up this list removes one more thing a human can be tricked into handing over — the top two remove the possibility of relay entirely.

None of this makes OTP worthless — the companion piece on what OTP actually prevents covers the large, real class of attacks it reliably stops. It does mean that "phishing-resistant" isn't a synonym for "has a second factor" or "uses an authenticator app." It's a specific structural property, and OTP in every form covered in this piece — SMS, voice, and app-generated — lacks it, because all of them ultimately produce a value a human can be induced to hand over somewhere other than the intended destination.

A practical checklist for auditing your OTP exposure

Security teams evaluating their own OTP exposure against the techniques above can work through a short, concrete list rather than a general "improve MFA" mandate:

• Map every account still on SMS-only OTP or recovery. SIM swap and SS7 exposure is proportional to how many accounts still treat a phone number as an identity anchor with no upgrade path — this includes recovery flows on accounts otherwise protected by stronger methods.
• Check push-approval configuration for number-matching and rate limits. Single-tap approve without number-matching is the exact interface MFA-fatigue bombing is built to exploit; confirm rate limits actually cap prompt volume rather than just logging it.
• Identify privileged and previously-targeted accounts for priority migration. Executives, admins, and anyone who's already been on the receiving end of a phishing or fatigue attempt should move to FIDO2 or passkeys first, not wait for a uniform rollout.
• Review carrier-side account security for SIM-swap-sensitive employees. Where a carrier offers PIN-protected porting or port-freeze options, high-privilege employees are worth walking through the setup directly rather than assuming the carrier's default protects them.
• Test whether your login flow can be proxied. A basic internal AiTM simulation (many phishing-awareness platforms include one) shows concretely whether your current OTP or push flow would survive a real relay attempt — most teams that haven't tested this are surprised by the answer.
• Confirm backup-code and account-recovery paths don't quietly reopen the gap. A phishing-resistant primary method paired with an SMS-based or security-question-based recovery flow still inherits the recovery flow's weaknesses.

What Avatier ships toward this pattern

Avatier Identity Anywhere MFA is built around the tiering this piece argues for rather than a single uniform method across every account. The platform supports FIDO2-compatible hardware security keys and platform passkeys for accounts that need genuine phishing resistance against AiTM relay and MFA fatigue, alongside app-based authenticator support and the Avatier Identity Challenge Card for deviceless workforce segments — shared-device environments like healthcare bedside stations, manufacturing floors, and contact centers, where a personal smartphone isn't always available to receive an OTP or push prompt in the first place. Adaptive, risk-based step-up moves higher-exposure accounts toward FIDO2-compatible methods first, rather than treating migration as a single company-wide cutover.

None of this is presented as a certification claim — Avatier's platform is FIDO2-compatible, supporting the open standard rather than claiming a specific certification status, and the distinction matters when evaluating any vendor's authentication story. What's independently verifiable is the operational and compliance posture behind the platform: SOC 2 Type II with zero exceptions, ISO/IEC 27001:2022 certification, PCI DSS v4.0.1 compliance, CSA STAR Level 1, alignment with NIST 800-53 Rev. 5, and status as a CISA Secure-by-Design Pledge signatory. The full detail is published at the Avatier Trust Center. For the breach patterns that show up when authentication controls fail across an entire identity program — not just at the OTP step — Avatier's Credential Governance blog covers the biggest identity-related breaches of the past several years and what let each one happen.

The broader migration path — how to sequence a workforce off OTP without stalling adoption or breaking legacy integrations — is covered step by step in the phishing-resistant MFA enterprise guide and in the hardware FIDO2 keys versus passkeys comparison for teams deciding between the two leading phishing-resistant form factors. Teams still running OTP as a baseline and wanting the fuller failure-mode picture should also read the OTP failure case scenarios piece, the hidden challenges of OTP authentication, and the dedicated MFA fatigue attacks and defense patterns piece, which goes deeper on push-bombing mitigations than the summary above.

What moving beyond OTP doesn't solve

None of the above is an argument that switching every account to FIDO2 or passkeys is simple, fast, or free of trade-offs, and it's worth being direct about what a migration away from OTP does not fix. It doesn't solve user experience friction — enrolling a workforce in hardware keys or passkeys is a real project with real support-desk load, lost-device recovery flows to design, and employees who will resist changing a habit that's worked fine for years. It doesn't solve legacy system constraints — plenty of internal applications, especially older ones, only integrate with OTP or don't support modern authentication standards at all, which means a meaningful subset of any enterprise's footprint will keep running on OTP for years regardless of strategy. And it doesn't eliminate the service-desk burden of account recovery, which shifts in shape (device loss instead of forgotten codes) rather than disappearing.

The realistic posture for 2026 is the same tiered approach the checklist above implies: OTP remains a legitimate, cost-effective baseline for the accounts where opportunistic, high-volume credential attacks are the dominant threat, and FIDO2 or passkeys become the priority for the accounts — privileged, public-facing, previously targeted — where the four techniques in this piece are a realistic and consequential threat. Getting that tiering right, and being honest about which bucket each account actually falls into, matters more than picking a single authentication method and declaring the problem solved.