Account takeover (ATO) is the point at which an attacker gains control of a real user’s account and can act as that user, usually by logging in with stolen credentials, a hijacked session or a manipulated recovery process. It is different from a data breach, which is about information leaving your systems, and from identity theft, which is about someone misusing a person’s identity elsewhere. With ATO the attacker uses your own login and your own product, so most of the work of preventing it is making the login harder to abuse: phishing-resistant authentication, limits on automated guessing, short and revocable sessions, a recovery path that cannot bypass those controls, and alerts when a user’s sign-in methods change.
This post is a map of the topic for teams that run a SaaS login, and where a subject has its own deeper article we link to it instead of repeating it.
What is account takeover?
An account takeover happens when someone other than the account owner gets the ability to authenticate as that owner, or to take over a session the owner already had. From the application’s side the attacker is simply a valid user. The requests carry a real session, the account passes every permission check, and nothing in the application’s own logic is violated, which is why ATO is hard to spot with controls that look for malformed or unauthorized requests.
Typical goals are reading customer data, acting as the victim, or, for an administrator account, creating further access such as a new API key or a second login method so the attacker keeps access after the compromise is noticed.
How is it different from a data breach and from identity theft?
The three terms overlap in news coverage but describe different things, and the difference matters because each one calls for a different response.
| Term | What it means | Who is the victim | Typical response |
|---|---|---|---|
| Account takeover | An attacker controls an existing account on your service | The account owner and your service | Revoke sessions, reset credentials, review what the account did |
| Data breach | Data was accessed or copied without authorization | Everyone whose data was exposed | Contain, assess scope, notify as required by law |
| Identity theft | Someone uses another person’s personal details to open accounts or commit fraud | The person whose identity was used | Credit and fraud remediation, usually outside your product |
The three feed each other: a breach elsewhere produces the leaked passwords that credential stuffing replays against your login, and a takeover can become a breach if the attacker exports data through the account.
How do attackers take over accounts?
There are seven entry paths worth designing against. Most real incidents use one of them, or chain two together, such as phishing a password and then abusing recovery to remove the second factor.
| Entry path | What the attacker needs | What it defeats | Main control |
|---|---|---|---|
| Credential stuffing and password spraying | Leaked or common passwords | Password-only login | Passkeys or MFA, breached-password checks, rate limits |
| Phishing and adversary-in-the-middle (AiTM) | A convincing page that relays your login | Passwords, SMS and app codes | Phishing-resistant authenticators (WebAuthn) |
| Session and cookie theft | A stolen session cookie or token | MFA, because it already happened | Short sessions, revocation, sender-constrained tokens (DPoP) where clients support it |
| SIM swap and SMS code interception | The victim’s phone number | SMS one-time codes | Do not rely on SMS for high-value accounts |
| Account recovery and helpdesk abuse | A convincing story or a weak recovery channel | Every login control | Recovery that cannot bypass MFA, verified helpdesk process |
| MFA enrollment abuse | A brief window of access | Future logins, by adding the attacker’s own factor | Step-up before factor changes, alerts on changes |
| Login flow bugs | A flaw in your own flows | Whatever the flaw sits behind | Patching, testing, narrow flows |
Credential stuffing and password spraying
Credential stuffing takes username and password pairs leaked elsewhere and tries them on your login, relying on password reuse. Password spraying does the opposite: it tries a few very common passwords against many accounts so that no single account sees enough failures to trip a lockout. Our article on what credential stuffing is covers detection and defenses in depth, and the IP-based protection gap in Keycloak’s brute force detection explains why per-account counters alone do not stop spraying.
Phishing and adversary-in-the-middle proxies
A phishing page that only collects a password is defeated by a second factor, so attackers now commonly run a proxy that sits between the victim and the real login page. The victim types their password and one-time code into what looks like the real site, the proxy forwards them, and the proxy keeps the session that the real site issues. Because the attacker ends up with a valid session, a code from an authenticator app or SMS does not help. Passkeys and other WebAuthn credentials resist this because the browser ties the credential to the real domain, so a relayed login on a lookalike domain produces nothing the attacker can use. The Keycloak-specific side of this, including the device authorization grant, is in device code phishing and passkey lures.
Session and cookie theft
Malware on a user’s device, called an infostealer, can copy browser cookies and saved tokens. An attacker who replays a stolen session cookie is already logged in, so no password and no MFA prompt is ever shown. What limits the damage here is how long the session lives, whether you can end it from the server side, and whether you notice it being used from somewhere new. The full mechanism and the Keycloak settings are in session hijacking and stolen sessions.
SIM swap and SMS code interception
A SIM swap is when an attacker persuades a mobile carrier to move a victim’s phone number to a SIM they control, which lets them receive the victim’s text messages. Any login or recovery step that sends a code by SMS then goes to the attacker. SMS codes are better than having no second factor, but they should not be the strongest factor you accept for administrators or high-value accounts.
Account recovery and helpdesk abuse
Recovery is often overlooked as an attack path because it is designed to let someone without their credentials back into an account. If a password reset link, a support agent or a recovery email can bypass the second factor, then an attacker can skip the second factor by going through recovery instead. Help desks are a frequent target because an agent can be persuaded by a confident caller; our post on MFA fatigue and helpdesk vishing covers how that works and why the exposure sits in enrollment. Recovery can also fail through software flaws, as in the Keycloak password reset takeover CVE-2026-18963, where the reset flow itself was the way in. For a worked example of tightening which contact methods may be used to recover an account, see Entra SSPR registered methods and Keycloak account recovery.
MFA enrollment abuse
Once an attacker has any foothold, such as a stolen session or a single successful recovery, the next move is often to add their own authenticator or remove the victim’s. After that, they can log in at will and the real user’s password reset does nothing. This is why changes to sign-in methods deserve the same protection as the login itself, which we come back to in the checklist.
Login flow bugs
The last path is a defect in your own authentication code or configuration: a flow that skips a step under unusual input, an endpoint that accepts a user identifier it should not, or a reset or verification step that can be replayed. The Keycloak reset flow case above is one example, and the practical answer is to keep the identity layer on a supported, patched release.
What does account takeover look like in your logs?
No single signal proves a takeover, but combinations of weak signals are reliable. These are the patterns worth alerting on, ordered roughly from cheapest to build to most involved.
- A successful login after a run of failures. A burst of failed logins across many accounts from one network, followed by a few successes, is the usual signature of stuffing or spraying.
- Impossible travel. The same account signs in from two places too far apart to reach in the time between them. VPNs and mobile networks cause false positives, so use it to raise a risk score rather than block outright.
- New device plus a change of MFA method. A sign-in from an unfamiliar device followed within minutes by a new authenticator being added or an old one removed is one of the strongest single indicators.
- A password reset followed by a factor swap. A reset that is followed shortly by changes to the second factor suggests that someone used recovery as the way in.
- Token or session use from a new network. A session that was created from one autonomous system number (ASN, the identifier of a network operator) and is then used from another, especially a hosting provider, suggests the session was copied.
Keycloak does not compute impossible travel or ASN changes for you. What it provides is the event stream those checks need: user events such as login errors and credential updates, and admin events for actions taken through the admin API. You send those to your log pipeline or security information and event management (SIEM) system and write the correlations there.
Account takeover prevention: how do you stop it on a SaaS login?
Account takeover prevention comes down to making a stolen password or session insufficient on its own, and the checklist below is ordered by how much each item removes from the table above. The first item matters most because it closes several entry paths at once.
- Use phishing-resistant authentication. Passkeys, and other WebAuthn authenticators such as security keys, are bound to the real site, so proxies and lookalike pages cannot reuse them. Offer them first and require them for administrators. See our guide to passkeys and WebAuthn in Keycloak and the background on FIDO2.
- Slow down automated guessing. Apply per-account lockout or delay, rate limits by network at the edge, and watch for spraying patterns that a per-account counter will not see.
- Reject breached and common passwords. NIST SP 800-63B-4, the current NIST guideline on authentication, tells verifiers to check chosen passwords against a list of commonly used, expected or compromised values. This does not help users who already have a weak password, but it stops new ones from being added.
- Require step-up for sensitive actions. Changing an email address, adding or removing an authenticator, creating an API key or exporting data should require the user to authenticate again, even in a live session.
- Keep sessions short and revocable. Set idle and maximum session lifetimes that match the risk, keep access tokens short, and make sure you can end every session for a user from the server side.
- Make recovery no weaker than login. A reset must not let someone skip a stronger factor, and a help desk agent should follow a written identity-verification process instead of judgment on a call.
- Alert users on factor and credential changes. An email to the account owner when a password, authenticator or recovery method changes gives the real user a chance to react and gives you a signal that the user reports.
Skycloak’s pages on advanced security, multi-factor authentication, passwordless and session management describe the product side of these controls.
Does enterprise SSO remove the account takeover risk?
For B2B products it moves most of it, but not all. When a customer connects their own identity provider through single sign-on, the customer’s IdP (identity provider, the system that actually authenticates their employees) holds the password, the MFA policy and the recovery process, so a takeover of one of their staff is largely a problem in their tenant rather than in your login.
Two kinds of account stay your responsibility. The first is the local or fallback account, for example the first administrator created before SSO was configured, or a break-glass login kept in case the customer’s IdP is unavailable. Attackers look for these because they often sit outside the customer’s policies. The second is your own staff and any support or impersonation tooling that can reach customer tenants. A reasonable baseline is to require a passkey or equivalent for every local administrator, disable password login for accounts that should only use SSO, and log and alert on every use of a fallback account, since in normal operation it should almost never be used.
How do you implement this on Keycloak 26.x?
The settings below are from the Keycloak 26.8 Server Administration Guide, and the names match what you see in the admin console. If you run Keycloak through a managed service, some of these are set by the provider, so check which ones you can change.
Brute force detection
Go to Realm settings, then the Security defenses tab, then Brute force detection. It is disabled by default. The guide says it applies to password, OTP and recovery code authentication, and it offers permanent or temporary lockout. The parameters include Max login failures (default 30), Wait increment (default 1 minute), Max wait (default 15 minutes), Failure reset time (default 12 hours), Quick login check milliseconds (default 1000) and Minimum quick login wait (default 1 minute). The default of 30 failures is permissive, so consider lowering it. Prefer temporary lockout, because permanent lockout lets an attacker lock real users out deliberately. When a user is locked, Keycloak still shows the generic Invalid username or password message so the attacker is not told the account is disabled. The counter is per account, so pair it with the edge controls described in the IP-based protection article.
Passkeys and WebAuthn
Keycloak acts as a passkey relying party and implements them through its WebAuthn support. In Authentication, under Policies, you configure the WebAuthn Passwordless Policy, and in the Required actions tab you enable Webauthn Register Passwordless so users can enroll. With passkeys enabled, the default browser flow skips the Browser – Conditional 2FA sub-flow when a passkey was used, so users are not asked for a second factor on top of a credential that already counts as one. The Passkey Mediation setting in the passwordless policy controls whether the browser shows a passkey dialog automatically on page load. The passkeys and WebAuthn guide walks through enrollment and flow changes.
Required actions and enrollment control
Required actions are steps a user must complete at next login, such as Configure OTP, Update Password or Webauthn Register. You can assign them to a user individually or enable defaults in the Required actions tab. For enrollment abuse, treat who may add or remove a credential as a policy decision and combine it with step-up and change alerts. Keycloak’s Delete Credential action is meant to be triggered by an application, such as the Account Console, with a parameter naming the credential, and it should not be assigned to users directly.
Conditional flows and step-up
Authentication flows can include conditional sub-flows, which run only if their conditions are true. The available conditions include Condition – User Role, Condition – User Configured, Condition – User Attribute, Condition – sub-flow executed and Condition – credential. Use them to require a stronger factor for administrators or particular clients. Keycloak also documents a step-up flow, in which each factor level is given a Level of Authentication (LoA) and clients request the level they need, so a sensitive application can demand a stronger login than a general one.
Session limits and timeouts
Under Realm settings, the Sessions tab holds SSO Session Idle, SSO Session Max, Client Session Idle, Client Session Max, Login timeout and Login action timeout, and the Tokens tab holds Access Token Lifespan and Revoke Refresh Token. Lower the idle and maximum values for administrator-facing clients, and consider enabling Revoke Refresh Token so that a refresh token can only be used once. Whichever party refreshes first wins and the other copy stops working, which cuts off a thief when the legitimate client refreshes first, and it can also break clients that send concurrent refresh requests. To cap concurrent sessions, add the User session count limiter authenticator to the flow, set the realm and client limits, and choose between Deny new session and Terminate oldest session. The guide recommends adding it to the browser flow with care, because the Cookie authenticator can re-authenticate users automatically, and to the direct grant, reset credentials and post broker login flows. For a compromised user, Sign out all active sessions exists at realm level, but the guide notes that it does not revoke access tokens already issued, which expire naturally, so keep access token lifespans short.
Login events and admin events
Under Realm settings, Events, switch on Save events in User events settings, set an expiration, and use Add saved types to include the credential events you want to analyze, such as Update Credential and Remove Credential. Under Admin events settings, enable Save events and Include representation so you can see what an administrator changed. The built-in Email Event Listener can notify users about login errors, password updates, OTP updates and removals, and Update Credential and Remove Credential, which covers the “alert on factor changes” item in the checklist. You can also opt in to notifications for temporary and permanent lockout through the --spi-events-listener--email--include-events option.
Recovery and the Reset Credentials flow
The Reset Credentials flow is where recovery logic lives, so review it the way you review login. Make sure it does not offer a way around the factors you require elsewhere, add the session limiter to it as the guide recommends, and keep the identity layer patched, since the flow was the subject of CVE-2026-18963, described in our write-up.
FAQ
What is the best account takeover prevention for a SaaS login?
The most effective single step is phishing-resistant authentication, meaning passkeys (WebAuthn) for users and administrators, because it removes the password that credential stuffing and phishing depend on. It works best combined with brute force detection, short and revocable sessions, step-up authentication for sensitive actions, and a recovery flow that cannot bypass the second factor.
How do you detect account takeover?
Look for combinations of events and not single ones: a password reset followed by a new second factor, a login from a new device or network followed by a credential change, or tokens used from an unexpected network. Keycloak records the events, and you correlate them in your own logging or SIEM system.
Is account takeover the same as identity theft?
No. Account takeover is an attacker controlling an existing account on a particular service, while identity theft is the misuse of a person’s personal details to open new accounts or commit fraud. They are related because information gathered in a takeover can feed identity theft, but they happen in different places and are fixed by different people.
Does MFA stop account takeover?
MFA stops many takeovers, particularly those that rely on a leaked password, but not all of them. Codes from SMS or an authenticator app can be relayed by a phishing proxy, a stolen session cookie skips the login entirely, and a weak recovery path can remove the factor. MFA is much more effective when it is phishing-resistant and when sessions and recovery are controlled as well.
Do passkeys stop account takeover?
Passkeys close the largest paths, because there is no password to stuff or phish and the credential only works on the real domain. They do not stop a stolen session, a compromised device, or a recovery flow that lets someone enroll a new authenticator. Treat passkeys as the strongest login factor, and still apply the session, recovery and alerting controls.