Your MFA was on. They got in anyway.
How Microsoft 365 and Google Workspace accounts are taken over in 2026, what it looks like from the inside, and what we watch in each.
Almost every account compromise we are called into had multi-factor authentication switched on. That is not a failure of MFA exactly. It is that the common attack stopped trying to beat it and started going around it.
The method is a fake sign-in page that sits in the middle. You type your password into it, it passes that to the real Microsoft or Google, they ask for your second factor, you approve it on your phone because you were expecting to, and the page in the middle keeps the session that comes back. The attacker now holds a signed-in session. They never needed your password again and they never have to pass MFA, because as far as the provider is concerned they already did.
This works identically on both platforms. The console is different, the exposure is the same, and so is the aftermath: it is quiet. There is no alert that says you have been breached. There is a mailbox behaving slightly differently, and somebody usually notices weeks later because an invoice was paid to the wrong account.
The consent grant almost nobody checks
An application consent grant is the one we find most often and the one most providers never look at, and it exists on both platforms. Instead of stealing a password, an attacker asks the user to approve an application. The prompt looks like every other permission dialogue, and people approve those all day.
Once granted, that application can read mail without needing the user's password, without triggering MFA, and it survives a password reset. Every incident response that stops at resetting credentials leaves this in place. We have found consents still active months after an organisation believed they had cleaned up.
Microsoft calls it application consent, Google calls it third-party app access. The fix is the same and it is boring: restrict who can grant it, review what is already granted, and treat a new grant as an event worth an alert. A line in a log nobody reads is not a control.
Sign-in policy is the control that works
Multi-factor authentication answers whether the right person is signing in. Sign-in policy answers whether this sign-in should be allowed at all, which is a different and more useful question. Microsoft calls it Conditional Access. Google calls it Context-Aware Access.
Either way it means blocking the legacy sign-in paths that skip modern controls, requiring a device you know, so a password alone gets nobody in, treating sign-ins from countries you do not operate in as failures and not prompts, and binding a session to the device it was issued to so a stolen token is worth less.
In most tenants this needs no new licensing. It needs somebody to sit down and configure it, and then to keep watching it, which is the part that does not happen when a tenant is set up once and left.
What we watch, on either platform
The same eight questions, asked in two different consoles. If you run both, which a surprising number of organisations do after an acquisition, we watch both.
Microsoft 365
- Sign-in risk and impossible travel in Entra ID
- Inbox rules, especially forwarding and delete-on-arrival
- OAuth application consent grants and their permissions
- MFA methods added, changed or removed on an account
- Legacy authentication attempts, and blocking the protocols
- Conditional Access policies, including device and location
- Token protection and sign-in session lifetime
- Exchange Online audit logging, on and retained
Google Workspace
- Suspicious login alerts and the Alert Center queue
- Gmail filters and forwarding, including delegated access
- Third-party app access and OAuth scopes granted
- 2-Step Verification enrolment and recovery methods
- IMAP, POP and app passwords that bypass modern sign-in
- Context-Aware Access rules by device and location
- Session length and re-authentication for admin actions
- Login and admin audit logs, and how long you keep them
Four questions to ask your provider
Including us, and they work for either platform. If the answers are vague, that is the finding. There is a longer version of this as a two minute self-assessment.
Who can approve an application against our data?
If the answer is every user, an attacker only needs one person to click approve. In most tenants this is still the default.
Would we know if a forwarding rule appeared today?
Not whether it is logged, whether anyone finds out. There is a difference between an audit trail and an alert.
Is legacy authentication blocked, or just discouraged?
Legacy protocols bypass MFA outright. If they are still permitted anywhere, MFA is optional in practice.
How long do we keep sign-in and mailbox audit logs?
Compromises are usually found weeks after they start. If the retention window is shorter than that, nobody can tell you what was taken.
Let's talk about what's not working.
A 20-minute call with a consultant. No sales script.