Account Takeover (ATO) Prevention for Business Accounts

An attacker who signs in as one of your users doesn't need to break anything. The login works, the mailbox opens, and every alert you built for malware stays quiet. This guide covers ATO prevention for business accounts: which controls break each step of an account takeover, in the order a small team can roll them out.

TL;DR

Account takeover (ATO) means someone else is signed in as your user. Count every account first, block legacy authentication, put phishing-resistant MFA on admins and finance, bind sessions to managed devices, restrict app consent, and alert on new MFA methods, inbox rules and consent grants. A one-page rollout order sits near the end of this post.

What Account Takeover Looks Like Inside a Business

Account takeover means an attacker signs in with a real user's identity. They get there by guessing a password, tricking the user into approving a login, stealing a session that already passed MFA, or persuading the user to grant a malicious app access. After that, the account does the damage: it reads mail, sets forwarding rules, sends invoices from a trusted address and registers its own MFA method so it can come back.

The best-documented business example is Microsoft's own. In January 2024 the company published how the Midnight Blizzard group got in: password spray against a legacy, non-production test tenant account that had no MFA enabled. The group then abused OAuth applications to reach mailboxes, and routed its sign-ins through residential proxies, which made IP-based indicators useless. Microsoft's write-up says that if the same team deployed that tenant today, mandatory policy would force MFA on it. One forgotten account without a second factor was the way in.

Every route in ends the same way, with the attacker acting as a trusted user. That is why prevention has to be layered: a control for each way in, and a detection for what slips past.

Run the Midnight Blizzard path against the controls in this post and watch where it breaks. An inventory finds the test tenant before the attacker does. Blocking legacy authentication and requiring MFA closes the spray. A consent restriction stops the malicious apps from being approved, and an alert on a new app with offline access fires when someone tries. Each step on its own is modest, and together they remove the whole route.

The phishing and infostealer routes get their own guide on credential harvesting. This post starts from the controls that make a stolen credential worth less.

Count Every Way In First

Controls only cover accounts you know exist. List every identity that can sign in: employees, shared mailboxes, break-glass admins, service accounts, test tenants, old contractor logins and guest accounts. For each one, record whether MFA is enforced and which legacy protocols it can still use.

Block legacy authentication first. Microsoft's analysis, quoted on its legacy authentication page, found that more than 97 percent of credential stuffing attacks and more than 99 percent of password spray attacks use legacy authentication protocols, which can't do MFA. A Conditional Access policy that blocks them starts in report-only mode so you can see what breaks. Printers and scan-to-email devices are the usual casualties. Move them to modern authentication or a dedicated relay. Tenants without Conditional Access licenses can use security defaults to block legacy authentication, per the same page.

Two groups of accounts sit outside normal user policies on purpose. Break-glass accounts and service accounts are excluded so a policy mistake can't lock everyone out or break a backend job, which means they need their own controls: a long random password in a vault, an alert on every sign-in, and managed identities in place of service accounts wherever the platform supports them. Our guide to privileged access management covers the vaulting side.

Pull the numbers instead of trusting the policy screen. Microsoft Graph exposes per-user registration details, and one query lists everyone who has not registered MFA:

powershell
Connect-MgGraph -Scopes "AuditLog.Read.All"
Get-MgReportAuthenticationMethodUserRegistrationDetail -Filter "isMfaRegistered eq false" |
  Select-Object UserPrincipalName, UserType, IsAdmin

Anything that comes back with IsAdmin true is the first ticket. Anything with an old last-sign-in date is a candidate for removal, not for enrollment.

People leave, and their accounts stay. A departed contractor with a working login is a takeover that needs no attacker skill, so offboarding belongs on this list. The client offboarding checklist has the steps for removing access cleanly.

Make MFA Phishing-Resistant Where It Matters

MFA still stops nearly every attempt. In a study of Microsoft Entra accounts, researchers found MFA reduced the risk of compromise by 99.22 percent across the whole population and by 98.56 percent when credentials had already leaked, with authenticator apps outperforming SMS. So turn MFA on everywhere before you debate methods.

Then upgrade the accounts where one approval costs the most. An attacker-in-the-middle page relays a normal MFA prompt in real time, so any method that asks the user to approve or type a code on a lookalike page can be relayed. Phishing-resistant methods tie the sign-in to the real site, so the relay fails. In Entra's built-in authentication strengths, the Phishing-resistant MFA strength allows Windows Hello for Business or platform credentials, FIDO2 security keys and certificate-based authentication. Authenticator phone sign-in sits in the MFA and passwordless strengths, but not in the phishing-resistant one.

Number matching is on for all Authenticator push notifications, which blunts approval fatigue. It doesn't stop a relay, because the attacker's page shows the user the number.

Roll the stronger method out in order of blast radius. Admin roles first, since a takeover there is a tenant takeover. Then anyone who approves payments or changes bank details. Then everyone else. Microsoft's short explainer on passkeys shows what the user sees:

A phishing-resistant method is only as strong as the way back in. If the help desk resets MFA over the phone, that call is the weakest door in the building, and the section on recovery below deals with it.

Protect the Session, Not Just the Sign-In

Once a user passes MFA, the browser or app holds tokens. An attacker who steals a session cookie or token replays it and skips MFA entirely. That is how a takeover follows a perfectly good MFA sign-in.

Token Protection is the control aimed at it. This Conditional Access session control accepts only sign-in session tokens bound to the registered device, so a stolen token can't be replayed from another machine. Per Microsoft's Token Protection page, updated in August 2026, it is generally available for native apps on Windows, iOS and iPadOS, and macOS, covering Exchange Online, SharePoint Online and Teams, while browser-based support is in preview for selected web apps. Microsoft's deployment advice is the right order for anyone: start with a pilot group, run the policy in report-only mode, capture interactive and non-interactive sign-in logs, then enforce.

Cheaper levers sit beside it. Require a compliant or hybrid-joined device. Require a trusted location for admin roles. Block sign-ins that Identity Protection rates medium or high risk. Device compliance comes from Intune, and our Intune review covers what it can and can't replace.

Tokens live on the endpoint, so a device with an infostealer is a token source. Keeping everyday users off local admin rights, patching browsers and blocking unmanaged devices from core apps all reduce what an attacker can lift from a machine. Our guide to endpoint privilege management covers removing admin rights without breaking the help desk.

Continuous access evaluation closes the revocation gap. Access tokens normally last an hour. In CAE sessions Microsoft lengthens that up to 28 hours but ties revocation to critical events instead of a clock: disabling the user, a password change or reset, and a location change are enforced in near real time. Microsoft's CAE page says latency of up to 15 minutes can be observed for event propagation, while IP location enforcement is instant.

The licensing problem is where small teams get stuck. An October 2024 r/msp thread on stopping token theft drew its loudest replies about paid tiers being required for protections that look like baseline security:

The same author's June 2025 follow-up listed six Conditional Access policies: managed device, compliant device, phishing-resistant MFA, trusted location, token protection and Global Secure Access. The top reply was a fair reality check. Few clients are anywhere near that list.

Which control needs which license changes with Microsoft's packaging, so check the current licensing table before you quote a client a price. The order that holds up for small teams is managed device first, Token Protection where the apps support it, and risk-based blocks if the license is there. Microsoft Mechanics walks through how the pieces fit:

Close the Password, Consent and Help Desk Doors

Passwords still matter, mostly because spray attacks win on common ones. NIST's current guidance, SP 800-63B-4, says verifiers shall check new passwords against a blocklist of commonly used, expected or compromised values, shall not impose composition rules, and shall not require periodic changes unless there is evidence of compromise. In practice that means turning on password protection in your directory and dropping 90-day rotation.

The list of what attackers try first is in our post on the most common passwords. Compare it with the passwords your users pick before you decide how strict the blocklist should be.

OAuth consent is the quiet takeover. A user clicks Accept on a malicious app, and the app holds a token with mail access that survives a password reset. Microsoft's page on user consent settings shows admins how to restrict or disable user consent and turn on an admin consent workflow, so users can request review instead of approving blind. Midnight Blizzard used the other side of the same mechanism: the group created malicious OAuth apps, had a new user account grant consent to them, and then used a legacy test app to give itself the Exchange Online full_access_as_app role.

The help desk is a door too. Attackers phone in as the user and ask for an MFA reset or a new password. Write down what proves a caller is who they say they are: a callback to a number already on file, a manager's approval, or a Temporary Access Pass issued only after a video check. Make resets on admin accounts need a second person. None of this needs a license, only a script the whole desk follows, and our guide to security awareness training covers how to teach it so it sticks.

Detect a Takeover in the First Hour

Prevention fails sometimes, so detection needs a short list of signals that point at a takeover in progress. Microsoft's catalog of risk detections includes the relevant ones: anomalous token, attacker in the middle, password spray, leaked credentials, suspicious inbox forwarding, suspicious inbox manipulation rules, token issuer anomaly and a possible attempt to access a Primary Refresh Token. In Microsoft's table, leaked credentials and Entra threat intelligence are non-premium detections, while attacker in the middle, inbox rules and password spray are premium.

Without the premium tier, the audit logs still carry four signals worth an alert. A new MFA method registered on an account. A new inbox rule that forwards or deletes mail. An OAuth consent grant. A sign-in from a new country followed by a mailbox sync. Microsoft's own Midnight Blizzard guidance lists a detection for a user consenting to a previously unknown app with offline access, and notes that such consent should generally be rare.

When one of those alerts fires, ask three questions in order. Was it the user? A short message to the user, through a channel the attacker can't read, settles most of it. What did the session touch? The mailbox rules, the files opened and the apps consented tell you the blast radius. Is it still live? If yes, go straight to the revocation steps below before you write anything down.

Keep the logs long enough to use them. Microsoft found the Midnight Blizzard activity by reviewing Exchange Web Services activity in audit data, which only works if the data still exists when someone asks. Our guide to log management covers retention and where to collect it.

The mailbox side of a takeover, hidden rules and forwarding, is the business email compromise pattern. The email security guide lists the switches that stop it.

What to Do When One Gets Through

Speed matters more than polish. Microsoft's guidance on revoking access gives the order for a compromised account:

1. Disable the account, so no new sign-ins start.
2. Revoke its refresh tokens, so existing sessions stop renewing.
3. Reset the password. On a hybrid account, Microsoft suggests resetting it twice to limit pass-the-hash risk if on-premises replication lags.
4. Remove any MFA method the attacker registered and any device they enrolled.
5. Delete inbox rules and forwarding, and revoke consent for any app the user granted.
6. Review sent items and what the mailbox could reach, and notify whoever received something from it.

The Microsoft Graph calls for the first two steps are short:

powershell
Connect-MgGraph -Scopes "User.ReadWrite.All"
Update-MgUser -UserId $user.Id -AccountEnabled:$false
Revoke-MgUserSignInSession -UserId $user.Id

Revoking refresh tokens doesn't kill access tokens already issued. Microsoft's page notes access tokens last one hour by default, so a client without CAE support can keep working for up to an hour after you revoke. That is the reason step five matters as much as the first two, and the reason to treat the account as hostile until the whole list is done. The wider process, roles and clocks live in our incident response plan.

Tell the client the same day, with facts: which account, when the first suspicious sign-in was, what you've revoked and what you're still checking. A takeover that touched invoices or payment details also needs a call to whoever receives those payments, because the attacker's last message may still be in their inbox. Cyber insurance policies often set a notification window, and our summary of cyber insurance requirements shows what questionnaires ask about it.

A Rollout Order for a Small Team

You don't need all of this on day one. This order puts the cheapest, highest-return controls first.

Steps one to six cost time, not licenses, on most tenants. Steps seven and eight depend on the devices and the tier, which is why they sit later. OpenFrame can run a dsregcmd /status script across a client's devices and collect the output, which gives you the join state that device-based policies depend on.

The Short Version

Account takeover works because the attacker looks like a user. Prevent it in layers: count every account, block legacy authentication, make MFA phishing-resistant for admins and finance, bind sessions to managed devices, restrict app consent, and close the help desk door. Then watch for the four signals that say a layer failed, and keep the revocation steps where the on-call person can find them. Start with step one this week.

FAQ

What is account takeover (ATO)?

Account takeover is when an attacker signs in as a legitimate user and acts with that user's permissions. The routes in include guessed or reused passwords, phishing and attacker-in-the-middle pages, stolen session tokens and malicious app consent. The damage usually shows up as inbox rules, payment fraud, data theft and new MFA methods the attacker registers to keep access.

Does MFA stop account takeover?

It cuts the odds sharply. In Microsoft's study of Entra accounts, MFA reduced the risk of compromise by 99.22 percent, and by 98.56 percent when credentials had already leaked. It does not stop a stolen session token or a malicious app consent, so pair it with Token Protection, device checks and consent controls, and move admins to phishing-resistant methods.

What is the difference between account takeover and credential stuffing?

Credential stuffing is one way in. Attackers replay passwords leaked from other sites against your sign-in page. Account takeover is the outcome: the attacker is signed in as your user, whether they got there by stuffing, spraying, phishing, token theft or consent abuse.

How do I know an account has been taken over?

Look for a new MFA method or device on the account, a new inbox rule that forwards or deletes mail, an OAuth consent grant the user doesn't remember, a sign-in from a new country followed by mailbox activity, and Identity Protection detections such as anomalous token or suspicious inbox rules. A user reporting mail they didn't send counts as a signal too.

What should I do first after a takeover?

Disable the account, revoke its refresh tokens, and reset the password. Then remove any MFA methods and devices the attacker registered, delete inbox rules and forwarding, and revoke app consent. Remember that access tokens already issued can work for up to an hour on clients without continuous access evaluation.

Do small businesses need premium licenses to prevent account takeover?

Some controls need none. Security defaults block legacy authentication and require MFA on tenants without Conditional Access licenses, and a help desk callback script costs nothing. Others are tiered: Microsoft's risk detection table marks attacker in the middle, inbox rule and password spray detections as premium, and Conditional Access features depend on the license. Check Microsoft's current licensing table before you scope a client.