Table of Contents
Don't have the time to read the entire post? Our human writers will be sad, but we understand. Summarize the post with your preferred LLM here instead.
An account takeover (ATO) happens when an attacker signs in to a customer’s account as that customer. To your app, it usually looks like any other login. The email matches, the password is correct, and if you ask for a one-time code, it checks out. Nothing in the request tells the app that the password came from another company’s breach, or that the code was relayed from a spoofed copy of your website seconds after the real customer typed it.
ATO prevention addresses the failure points that lead to legitimate customers losing access to their own accounts:
At sign-in, passkeys change what counts as proof, so a breached password or a relayed code is no longer enough to get in.
Adaptive multi-factor authentication (MFA) checks the signals surrounding each attempt, like whether the device or IP address is familiar, and asks for more proof before a suspicious login succeeds.
Bot detection shuts down automated attacks that evade rate limits and lockouts through multi-origin botnets.
Session management limits how long an attacker can use a session they steal after login.
Most auth providers advertise features that try to tackle all of these failure points, so the details are what separate them: whether phishing-resistant methods come with weak fallbacks, how reliable the risk signals are, and what happens when a customer’s device can’t use a passkey. This post explores ATO protection through that lens, with evaluation questions for ATO solutions and best practices for preventing ATO in your app.
At a glance
The most common causes of account takeover in customer-facing apps are credential stuffing, phishing, SIM swapping, and session hijacking.
Passkeys only work on the domain they were created for, so they can’t be phished, and replacing passwords removes what credential stuffing relies on.
SMS codes, email one-time passwords, and push approvals don’t count as phishing-resistant. Each can be circumvented by a determined or lucky attacker.
Fallback and recovery paths need the same protection as the login, since an SMS password reset is still vulnerable to SIM swapping.
What is account takeover protection?
Account takeover protection is everything that keeps an attacker from signing in as one of your customers, or from using a session they’ve stolen. Most of that protection happens in authentication, at the entry points where an attacker can present stolen credentials or tokens and be treated as the customer.
Entry point | What the attacker presents | Controls that protect it |
|---|---|---|
Sign-in | A breached or phished password, or a relayed one-time password | Passkeys, breached-password checks, and bot detection |
Fallback methods | An SMS or email code sent to customers without a passkey | Fallbacks that avoid SMS, with adaptive MFA on risky attempts |
Account recovery | A reset link sent to a hijacked phone number or inbox | Recovery that avoids SMS, and step-up before recovery details change |
Active session | A stolen session cookie or token | Short-lived tokens, refresh token rotation, and server-side revocation |
It’s tempting to pour all your effort into the sign-in screen, since that’s the front door everyone pictures. But securing one entry point alone doesn’t protect the other three: an app can offer passkeys at sign-in yet still fall back to SMS codes, or let stale sessions live for weeks. Effective account takeover solutions have to be comprehensive, covering the login, the fallback, the recovery path, and session management at once. Fraud tools help, too, and our guide to fraud detection in authentication covers how to watch the signals that matter.
How does account takeover happen in customer-facing apps?
Customer-facing apps are especially exposed to all four main attack paths. While B2B apps still need ATO prevention in place, B2C apps face the added risk of larger user bases (which means a larger attack surface) and public-facing login pages (which means automated attacks are more frequent).
Credential stuffing
Credential stuffing starts with someone else’s breach. Attackers use bots to try leaked email and password pairs against your login page, relying on customers who reuse passwords. Descope’s analysis of the Verizon 2026 DBIR found credential abuse in 39% of breaches, more than any other vector. Descope’s State of Customer Identity research found that 87% of organizations still use passwords for customer auth. And Dashlane puts the average number of passwords one person manages at 301, more than anyone could remember and keep unique.
Phishing
Credential phishing targets the customer directly. A convincing copy of your login page, often on a lookalike URL, collects their password. If you ask for one, it can also capture the one-time password (OTP) in real time. More advanced phishing kits act as a proxy between the customer and your real site, relaying credentials automatically without a human attacker present. Your app sees a valid login and issues a session cookie, which the attacker’s adversary-in-the-middle (AITM) tool captures.
SIM swapping
SIM swapping goes after a user’s phone number. The attacker convinces a mobile carrier to move the customer’s number to a SIM they control, and from then on every SMS your app sends, including password reset links, goes to the attacker. While SIM swapping is rare and typically targets high-profile accounts, the results can be extremely costly. The FBI’s Internet Crime Report for 2025 lists 971 SIM swapping complaints, a fraction of a percent of all incidents, but with reported losses of $17.3 million.
Session hijacking
Session hijacking skips sign-in entirely. An attacker who steals a valid session cookie or token, for example with malware on the customer’s device, can replay it, and your app treats each request as the customer’s. Passkeys can’t help here because the attacker never touches the login page. Short session lifetimes and server-side revocation limit the damage, though they don’t always prevent it.
What should you look for in an account takeover solution?
Ask every account takeover solution provider about the same essential areas: sign-in methods, phishing resistance, risk checks, bot and fraud signals, and change management. For each area, we’ve paired the question to ask with what a strong answer should include. Each strong answer describes something you can set up and check yourself during a trial.
Area | What to ask | What a strong answer includes |
|---|---|---|
Sign-in methods | Are passkeys supported natively for both registration and sign-in? | FIDO2 passkeys, plus a defined fallback for devices that can’t create one |
Phishing resistance | Which standard are the “phishing-resistant” methods built on? | FIDO2 and WebAuthn, with SMS codes and push approvals excluded |
Risk signals | Which signals are evaluated at login, and who sets the thresholds? | Device trust, impossible travel, and IP reputation, with step-up for scenarios your team defines |
Bot and fraud signals | Do native and third-party signals feed the same login decision? | Built-in bot and breached-credential checks, plus connectors for outside risk scores |
Change management | Does changing a sign-in method or risk rule require a release? | Changes made in configuration, without redeploying your app |
Secure sign-in methods
No amount of monitoring stops a password from being reused, stuffed, or phished. One-time passwords (OTPs) via SMS, email, or authenticator apps address the reuse problem but leave the phishing one open. Single-device magic links are arguably more secure than a transferable one-time code, but the user’s email account (and its security hygiene) is outside your control. Passkeys address both the reuse and phishing risks of passwords: a passkey created for your domain won’t work on a lookalike site, and your server stores only the public key. Passkeys aren’t always the whole answer to ATO prevention, but today, they’re almost always part of it.
Phishing resistance with strong fallbacks
NIST defines phishing resistance as protection that keeps secrets away from an impostor without counting on the user to notice anything is wrong. That especially matters for customer-facing apps, where you can’t expect to train users to spot fakes. Passkeys meet the bar because they’re built on FIDO2, which runs through the browser’s WebAuthn API. The best approach is to keep each user on the most phishing-resistant method their device supports, and to layer methods (for example, any two methods other than a password) when they have to fall back to a weaker path.
Risk signals and step-up authentication
Adaptive risk checks decide which logins need a second factor, and your team should decide what counts as a red flag. In Descope, for example, adaptive MFA conditions can check whether a device is trusted, whether the customer is signing in from somewhere they couldn’t have reached since their last login, and whether the IP address has a bad reputation according to a connector like AbuseIPDB.
Step-up authentication is a simpler approach: one more check that’s always on before a specific action, like a big transfer or a password change. When it triggers on a fixed dollar amount, it adds friction for many legitimate customers. It’s easier to set up, and it works well in environments with a higher tolerance for security checks, but the friction can lead to abandoned carts.
Bot and fraud signals in one decision
High-volume bot traffic against a login page is almost always malicious, and it’s much easier to turn bot attacks away before they reach a credential check. In Descope, Bot Trap adds a hidden field that people never see and simple bots fill in, and the Have I Been Pwned connector flags passwords that have already turned up in a breach. Scores from fraud providers like Fingerprint, Arkose Labs, and Sardine feed into the same Flow, so they all inform the same decision.
Changes without a redeploy
Risk policy needs adjusting as attack patterns evolve. If adding a new sign-in method requires a code change and a redeploy, those adjustments happen less often than they should. In Descope, for example, sign-in methods, risk conditions, and fallback routing are configured through Descope Flows, and changes take effect without redeploying your app. Similarly, you shouldn’t have to rip and replace your existing auth system just to add passkeys. A good ATO prevention provider lets you offer passkeys alongside your existing methods, falling back to the next-best option when your policy allows it.
How do you prevent account takeover in your app?
A rollout order that strengthens protection without locking customers out begins with these steps:
Offer passkeys next to your existing sign-in methods. The best way to improve adoption is to ask customers to create a passkey right after a successful login. Descope Flows can A/B test that prompt before you show it to everyone. Branch rolled passkeys out to its independent agents in waves, routing each user to a passkey or a fallback depending on their device.
Turn on adaptive or step-up MFA. With adaptive MFA, a second factor only shows up when something looks off, like an untrusted device, impossible travel, or a flagged IP address. Everyone else signs in without the extra step. If your customers tolerate always-on security, turn on step-up authentication for specific actions or conditions, such as high-value transactions, viewing payment info, or changing account details.
Close the weak recovery and fallback paths. If customers without a passkey fall back to SMS codes, or password resets arrive by text, SIM swapping and relay kits still work on those accounts. Require step-up authentication before anyone changes recovery details, so an attacker in a hijacked session can’t replace them with their own phone number or email.
Filter bots and breached passwords before they reach a credential check. Bot Trap catches the simple bots that fill in its hidden field, and the Have I Been Pwned connector flags passwords that appear in breach data, so you can force a reset or ask for another factor. If your app tends to draw more sophisticated bots, consider a fraud connector such as Arkose Labs or Fingerprint.
Keep sessions short. Descope’s session management pairs short-lived session tokens with longer-lived refresh tokens, and supports refresh token rotation, inactivity timeouts, and server-side revocation. A stolen session token expires quickly, and revoking the session prevents the attacker from getting a new one.
Stopping account takeover with Descope
Account takeover protection holds up when every entry point is covered: passkeys at sign-in, adaptive MFA and bot detection around each attempt, recovery paths that don’t depend on SMS, and sessions short enough that a stolen token expires quickly. Descope covers each of these in one platform. The sign-in journey, from the passkey prompt to the risk conditions and fallback routing, lives in Descope Flows, and session settings are managed in the same project, so your team can tighten protection as attack patterns change without rebuilding anything.
To see how it fits your app, create a Free Forever account and build a passkey login Flow with adaptive MFA, or book a demo to walk our team through your setup.
