How to Prevent Account Takeover: A Control-by-Control Guide for Security Teams

The login is now the best-defended step in most organisations. Microsoft’s Digital Defense Report 2025 says more than 97% of identity attacks are password spray or brute force, and that modern MFA reduces identity compromise risk by more than 99%. That’s a real win, and attackers noticed. They stopped trying to break the login and started going around it.

The losses haven’t slowed down much. Javelin’s 2026 Identity Fraud Study put US account takeover losses in 2025 above $15 billion across 6 million consumers, with losses down 4% year over year while the number of victims rose 18%. More people are getting hit, for a bit less each.

So this guide goes one route at a time, in roughly the order an attacker meets them: leaked credentials, the sign-in itself, the phone call that asks for a code, the authorization step, the help desk, the live session, and what happens once an account has fallen. For each one we give the control the way the people who wrote the guidance state it, and where a control depends on a person, how to test it.

Where account takeover happens now

It helps to separate three things that most advice lumps together. Authentication proves who is signing in. Authorization decides which app gets a token and what a signed-in session may do. Recovery decides how someone who can’t authenticate gets back in. Passwords, MFA and passkeys all live in the first one. The attacks that grew fastest in 2026 live in the other two.

In practice that gives an attacker four routes that skip the password entirely. Device code and consent phishing get a token handed over after a genuine login. Infostealers copy the session cookie, which resumes an authenticated session with no password and no second factor. The help desk can reset any factor on any account. And the person on the phone can be talked into reading out a code or approving a prompt. Any of these ends in the same place: a working account in someone else’s hands, most often an email account takeover that becomes the starting point for fraud.

The phone route deserves the most attention right now. Mandiant’s M-Trends 2026 found that vishing was the single most common initial vector in cloud compromises, at 23%, ahead of third-party compromise at 17%, stolen credentials at 16% and email phishing at 15%. That figure covers cloud intrusions specifically, and for most security teams the cloud identity is exactly the account worth protecting. And the attackers are fast. The CrowdStrike 2026 Global Threat Report describes two named groups going from account takeover to data theft in under five minutes, which rules out any process that depends on someone noticing and reacting within the hour.

Stop reused and leaked credentials from working

The volume end of account takeover is still credential stuffing: username and password pairs leaked from one site, tried on others by bots. The 2026 Cloudflare Threat Report found that 63% of all logins involve credentials already compromised elsewhere and that 94% of all login attempts come from bots. Those numbers explain why the first control is so unglamorous.

Screen every new and existing password against known leaked-credential lists, and reject matches. Rate-limit and score sign-in attempts, so a burst of failures from one network or a login from a device never seen before gets challenged. Bot and fraud detection vendors such as Cloudflare, Imperva and Sift do this at scale for customer-facing sites, and your identity provider does a version of it for staff accounts. Any working second factor also stops stuffing cold, which is why this is the attack MFA statistics describe best.

The harder part is knowing whose credentials are already out there. Infostealer malware has made that list enormous. SpyCloud’s 2026 Identity Exposure Report counted 642.4 million credentials recovered from 13.2 million infostealer infections, plus 8.6 billion stolen cookies and session artifacts. So the useful version of that number is a list of specific people in your organisation, because those are the people most likely to be targeted next.

Brightside checks every employee’s work email address against known data breaches each month and shows a data-leak count per employee and an average per group in the Admin Portal. A ready-made group of employees exposed in the last 90 days updates itself, so training and simulations reach the people already in a breach first. Exposure also feeds into each employee’s risk score, which is how the security team decides where to look next. Employees can add up to 10 personal email addresses to monitor in their own Personal Portal, and that personal monitoring is never visible to the employer.

Move sign-in to passkeys and remove the fallbacks

Once reused passwords stop working, the next attack on the login is adversary-in-the-middle phishing: a proxy page that relays the password and the one-time code to the real site and keeps the session cookie it returns. Ordinary MFA doesn’t stop it. Phishing-resistant sign-in does.

NIST SP 800-63-4, finalised on 31 July 2025, defines phishing resistance as “the ability of the authentication protocol to prevent the disclosure of authentication secrets and valid authenticator outputs to an impostor verifier… without relying on the vigilance of the claimant.” The last part matters most: a passkey or a FIDO2 security key is bound to the real domain, so it simply won’t sign in on a lookalike, whatever the user believes about the page. At AAL2, NIST requires verifiers to offer at least one phishing-resistant option. That’s a requirement to offer, not to use. And NIST didn’t ban SMS: it stays a valid AAL2 factor, classified as “restricted”.

The evidence for security keys is strong, if dated. Google, NYU and UCSD’s study, “Evaluating Login Challenges as a Defense Against Account Takeover”, found security keys stopped 100% of automated bot attacks, bulk phishing and targeted attacks alike. The study is seven years old and predates today’s proxy kits, so its SMS numbers flatter SMS. Usability has caught up too. Microsoft’s deployment guidance says synced passkey sign-in takes about 3 seconds at 95% success, against about 69 seconds at 30% success for password plus MFA.

The catch is everything you leave enabled next to the passkey. Proofpoint showed that a phishing proxy can spoof an unsupported browser so the sign-in page falls back to a weaker method, and then harvests that one. So a passkey rollout isn’t finished until the phishable fallbacks are switched off for the people who have passkeys.

If you run Microsoft Entra ID, there’s a hard date on this. According to Microsoft, from 1 September 2026 users enabled for SMS or voice are nudged to register a passkey at sign-in, and on 1 February 2027 Microsoft discontinues native SMS and voice delivery, after which those users must register a passkey first, with no opt-out. Plan the recovery path for users who can’t register one now, because that path is exactly what the next two sections are about.

Prepare staff for the call that asks for the code

A passkey can’t be phished, but the migration to passkeys can. Google Threat Intelligence Group reported on 6 August 2026 that the extortion group it tracks as UNC6671 calls employees posing as IT help desk staff and cites a mandatory, urgent migration to passkeys or a required MFA update. “UNC6671 callers have continued to call targeted employees on their personal mobile numbers, circumventing corporate security controls,” GTIG wrote, and “in at least some recent cases, the threat actor has spoofed the legitimate helpdesk phone number.” The caller walks the employee to a lookalike enrolment portal that relays their credentials and MFA to the real Microsoft 365 or Okta sign-in and keeps the session. Then the operators deleted password-reset confirmations and security notifications, so nobody saw the change.

None of this is new as a pattern. The CISA and FBI advisory on Scattered Spider describes the group having “posed as company IT and/or helpdesk staff using phone calls or SMS messages to obtain credentials from employees.” New York’s financial regulator saw the same thing in 2026. Its 6 February 2026 vishing advisory describes attackers “posing as IT help desk staff in calls to personnel in order to steal login credentials,” with victims handing over credentials and MFA codes. That’s from the regulator whose own Part 500 rules, in section 500.12(a), already require MFA “for any individual accessing any information systems of a covered entity.”

The control here is a pair of plain statements, repeated until staff can say them back. IT will never ask for a code, a password or an approval over the phone. IT will never ask you to enrol a new sign-in method from a link someone sent you during a call. Anyone who gets that call hangs up and rings the help desk on the number from the intranet.

The rule is simple to write down and hard to follow when the caller knows your name, your manager and the ticket number. Brightside’s vishing simulator places a live AI phone call from an IT help desk persona working toward the 2FA phishing link goal, with influence techniques such as Appeal to authority and Apply pressure through risk, and the agent holds a real conversation that adapts to what the employee says. A Voice + BEC attack pairs that call with a coordinated email, so the link is already in the inbox when the caller mentions it. Staff rehearse the same kind of call UNC6671 makes before the real one arrives, which is what we like most about it. Vishing is part of the Pro package or the Voice add-on.

Block device code flow and review app consent

Device code phishing is the route that neither passkeys nor URL-checking can stop, and it’s the one that grew fastest. The device code flow exists so a smart TV or a command-line tool can sign in by showing a short code that you enter on another device. The attacker generates the code and persuades the victim to enter it on the genuine Microsoft sign-in page. The victim signs in with their real password and real MFA, and the token goes to the attacker. Push Security states that no authentication control stops this, including passkeys, because the attack happens after authentication has already succeeded.

Push Security recorded a 15x increase in device code phishing pages by early March 2026 and 37.5x by April. Microsoft then documented a campaign on 6 April 2026 that generated device codes at the moment the victim clicked, which removed the 15-minute code expiry that had been the technique’s main practical limit.

The fix is mostly configuration, and it’s cheap. Microsoft’s Conditional Access documentation on blocking authentication flows says: “We recommend organizations get as close as possible to a unilateral block on device code flow.” It advises auditing existing use in report-only mode first and allowing the flow only “in well documented and secured use cases, like legacy tooling that can’t be updated.” Most workforces have very few of those.

Consent phishing works the same way through a malicious app that asks the user to grant it access to their mailbox or files. The matching control is to restrict user consent to verified publishers and low-risk permissions, route everything else to an admin, and review the apps already granted access.

Make the help desk prove who is calling

The help desk is the one place in the organisation that can undo every factor you’ve deployed, which makes it the most valuable phone number an attacker can call. The CISA and FBI advisory describes Scattered Spider doing exactly that: the group “posed as employees to convince IT and/or helpdesk staff to provide sensitive information, reset the employee’s password, and transfer the employee’s MFA to a device they control.” The desk agent wants to help a locked-out colleague. The attacker has already bought the colleague’s personal details. Well, that’s the whole problem.

Mandiant’s hardening guidance for the same group, published 6 May 2025, is the most concrete public playbook we know of for this. Its core controls:

• “Train help desk personnel to positively identify employees before modifying / providing security information (including initial enrollment),” with on-camera or in-person verification, ID verification or challenge questions, at least for privileged accounts.
• “Avoid reliance on publicly available personal data for verification (e.g., DOB, last 4 SSN),” since the attackers usually have it.
• Require strong authentication before anyone changes an authentication method, and allow MFA registration only from trusted locations and compliant devices.
• Alert when the same phone number or MFA method is registered to several accounts.
• Require “a call-back to a registered number or confirmation via a known corporate email before proceeding with any sensitive request.”

We’ve covered how help-desk calls engineered to reset MFA play out against Okta in more depth, but the point for prevention is short. Every one of Mandiant’s controls is a procedure, and a procedure is a document until somebody tests it with a convincing, impatient caller on the line. Brightside’s vishing simulator calls members of the help desk team with a persona posing as a locked-out employee and a goal the admin writes, such as getting an MFA reset without a callback, and the caller can speak in a cloned executive voice made from a 1 to 2 minute recording. What comes back is a failed rate for the help desk team per campaign and as a 7, 30 or 90-day trend, with a baseline round to measure improvement against. That moves Mandiant’s callback rule from written to measured.

Bind sessions to devices and revoke them everywhere

A stolen session cookie beats every factor, because it represents a login that already happened. That’s why infostealers are better understood as an MFA-bypass technology than a password-theft one. SpyCloud’s 8.6 billion stolen cookies and session artifacts are the supply side, and the malware keeps adapting. Vidar 2.0, released in October 2025, added a bypass for the cookie encryption Chrome introduced in 2024 to stop exactly this, according to Trend Micro.

The answer is to make a stolen token useless somewhere else. Microsoft’s Token Protection is a Conditional Access control that accepts only sign-in tokens cryptographically bound to the device they were issued to. Coverage is still partial. Native apps for Exchange Online, SharePoint Online and Teams are generally available on Windows and iOS, while browser-based support is in preview and limited to selected apps. For OAuth tokens more broadly, RFC 9449 (DPoP) binds a token to a key the client holds.

The second half is revocation that actually reaches every app. The OpenID Foundation finalised the Shared Signals Framework, CAEP and RISC on 17 September 2025. They let an identity provider tell every connected app that a session should end, so a takeover spotted in one place kills the attacker’s sessions everywhere. Where your SaaS apps don’t support that yet, shorter session lifetimes for sensitive apps narrow the window a stolen cookie is good for.

Teach the three rules no control enforces

A few steps happen where no policy can see them. Conditional Access can block the device code flow, but it can’t stop someone reading a code aloud to a caller. So there are three rules worth teaching until they’re reflexes:

1. Never enter a code that someone else sent you. If you didn’t start the sign-in, the code isn’t yours.
2. Never read a code, password or approval to anyone on the phone, including IT.
3. Never approve a sign-in prompt or an app consent screen you didn’t start.

We’ll be honest about the evidence on training. A randomised controlled trial at UC San Diego Health, published at the 2025 IEEE Symposium on Security and Privacy, ran monthly simulations against more than 19,500 employees for eight months and found embedded training reduced failure rates by 1.7% on average against the control group. Vendors answered that the study tested annual modules and click-triggered training. Either way, it argues for teaching short, specific rules tied to the attacks people will actually get, rather than general advice about spotting suspicious emails. That’s the approach behind training employees against AI voice scams too.

The three rules need a home in the regular training schedule, or they fade after the first announcement. Brightside’s course library includes courses on passwords, two-factor authentication, and smishing and vishing, each built around one learning goal and delivered in a chat-based format guided by Brighty, the interactive learning companion. Courses are grouped into curricula with a deadline for every assigned course and automatic reminders, and they run in English, French, German, Italian and Spanish. Completion and overdue courses show per employee and group, so the three rules are tracked like any other control.

Limit what a taken account can reach

Assume one account falls anyway. Mandiant found the handoff between an initial access broker and the operator who uses that access had shrunk to 22 seconds, and CrowdStrike’s under-five-minutes figure says the same. Response has to be automatic: revoke sessions on a high-risk sign-in, and alert on the changes attackers make first, which are a new MFA method, a new inbox rule and a new OAuth grant. UNC6671 deleted security notifications precisely because those alerts work.

Integrations need the same least-privilege thinking as people. In August 2025 the group Google tracks as UNC6395 used stolen OAuth tokens from the Salesloft Drift integration to pull data from customers’ Salesforce instances, then searched it for AWS keys, passwords and Snowflake tokens, according to Google Threat Intelligence Group. Cloudflare found 104 of its own API tokens in the stolen case data and rotated them, as it described in its own disclosure. Nobody was phished at the victim companies. So review what each connected app can read, scope its tokens narrowly, and know how to rotate them in an afternoon.

And remember what a taken mailbox is usually for. The FBI’s IC3 2025 Annual Report recorded business email compromise losses of $3,046,598,558 across 24,768 complaints. Payment verification belongs in your account takeover plan as much as in a BEC prevention framework, because it’s the control that still works after every earlier one has failed.

FAQ

How do hackers gain access to your account?

Most often with a password leaked from another site, tried by bots, or through a phishing page that relays the password and MFA code to the real site. Increasingly they skip the password: they steal a session cookie with infostealer malware, trick the user into entering a device code on a genuine sign-in page, or call the help desk and ask for a reset.

What is the typical method of account takeover?

By volume it’s credential stuffing. The 2026 Cloudflare Threat Report found that 63% of all logins involve credentials already compromised elsewhere. For targeted workforce accounts, voice phishing now leads: Mandiant’s M-Trends 2026 found vishing was the most common initial vector in cloud compromises, at 23%.

What is the difference between account takeover and identity theft?

Account takeover means someone gains control of an existing account and uses it as the owner. Identity theft is broader and usually means using someone’s personal details to open new accounts or commit fraud in their name. In Javelin’s 2026 Identity Fraud Study, US account takeover losses alone were above $15 billion in 2025.

What are the best ways to prevent account takeover?

Screen passwords against leaked-credential lists, move sign-in to passkeys and switch off phishable fallbacks, and block device code flow where it isn’t needed. Make the help desk verify identity with a callback to a number on file before any reset. Bind sessions to devices where your identity provider supports it, and revoke them automatically when a sign-in looks risky.