MFA passed, and the attacker still walked in through one consent screen

One of your team gets an email that looks like a document shared through Microsoft. They click it, and they land on a real Microsoft sign-in page — not a lookalike, the genuine one, on a genuine Microsoft address. They type their password. Their phone buzzes with the usual approval prompt, and they tap “Approve,” because they always do. Everything behaved exactly the way it’s supposed to. The multi-factor authentication you rely on did its job.

And the attacker still walked away with a live token to that person’s mailbox, files and calendar — a token that keeps working after the session ends, that survives the next password change, and that never faces an MFA prompt again. Nothing was cracked. The login was real. What the email actually did was walk your user through granting access, using a Microsoft flow called device-code sign-in (a way to log a device in by having a person approve a short code) or a consent screen that quietly asked for standing permission to their account. MFA guards the front door. This came in through a side door your tenant left unlocked.

That’s the quiet failure: not a stolen password, but two settings left at their permissive defaults, so a real login hands a stranger a key that doesn’t expire when the password does.

Why it stays invisible

The trouble is that this doesn’t look like an attack from any angle you’re watching.

Your sign-in logs show a successful, MFA-satisfied login from your own user — because that’s genuinely what happened. There’s no failed-password spike, no “impossible travel” alert, no brute force to notice. The malicious step wasn’t the login; it was the consent or the device-code approval that rode in on the back of it, and that gets recorded as a routine, user-approved action rather than a break-in.

Two defaults are doing the damage. The first is device-code flow left enabled for accounts that never legitimately need it — it exists to sign in TVs and command-line tools that can’t show a login box, and a phishing kit abuses it to have your user approve the attacker’s device. The second is open app consent: by default, an ordinary user can grant a third-party app standing access to their own mailbox and files without anyone approving it. Put those together and a convincing email can turn one distracted click into a durable, MFA-bypassing foothold — because an OAuth token, once granted, sits beside your password defences rather than behind them.

None of this is hypothetical. A phishing-as-a-service kit called EvilTokens — a subscription product, rented out over Telegram — went live in February 2026 abusing exactly this device-code flow, and within about five weeks researchers had counted more than 340 Microsoft 365 organisations compromised through it.

And because the access is a token rather than a session, revoking is not the same as changing the password. The person can reset their password, tick “MFA on,” feel safe — and the granted app keeps its access until someone explicitly takes it away. Which, as with most quiet failures, is nobody’s job until it is.

Find it yourself

You can check both defaults, and look for anything already granted, in about ten minutes. You’ll need administrator access to Microsoft 365 / Entra. One note before you start: Microsoft reshuffles and renames these admin menus often, so if a label below has moved, the search box at the top of the admin centre will find it by name.

1. See what’s already been consented to. In the Microsoft Entra admin centre, go to Identity → Applications → Enterprise applications. Filter to applications users have consented to, open a few, and read their Permissions. You’re looking for apps you don’t recognise, and any holding broad mail or file access. Anything suspicious here may already be an active grant, not a hypothetical risk.
2. Check whether device-code flow is open. Still in Entra, open Conditional Access and look for a policy restricting authentication flows (device-code is the one to block). If there’s no such policy, device-code sign-in is effectively available to everyone — the state you want to change.
3. Check who can consent to apps. Go to Identity → Applications → Enterprise applications → Consent and permissions → User consent settings. If it’s set to allow users to consent to apps for themselves, an ordinary user can grant a third-party app access to their account with no review. Note what it’s currently set to.
4. Look for the after-effects. A successful token grab is often followed by a quiet inbox rule that hides the attacker’s tracks. In the Exchange admin centre, or by asking affected users to check Outlook → Settings → Rules, look for rules that forward mail externally or shove messages into obscure folders. (Our companion issue on malicious inbox rules covers this in full.)
5. No admin access? Ask one question. If someone else runs your tenant, email them: “Are device-code sign-in and open user app-consent both restricted in our Microsoft 365 tenant, and can you list the third-party apps users have consented to?” A clear “both are locked down, here’s the list” is the answer you want.

The usual reaction on first run is not a dramatic discovery but a mild unease at how many apps are on the consented list, and how few people knew.

The fix

The good news is that the two settings behind this are yours to change, and changing them closes the side door for everyone at once.

Turn off device-code flow where it isn’t needed. Add a Conditional Access policy that blocks the device-code authentication flow for your ordinary users, leaving it on only for the rare account that genuinely signs in a shared device or a headless tool. This removes the exact mechanism the phishing kit relies on.

Make risky consent a decision, not a default. Change user consent settings so that users can only consent to low-risk, verified apps — or so that anything touching mail and files routes to an administrator for approval. Set up the admin consent workflow so those requests come to you instead of being granted silently. An invisible permission becomes a visible request.

Revoke and reset properly if you found a live grant. If step 1 turned up an app that shouldn’t be there, removing it is not enough on its own: revoke the app’s access, then revoke the user’s active sessions/tokens (sign them out everywhere) and have them reset their password. Because the token survives a password change, you must kill the token explicitly — otherwise the door you think you shut is still ajar.

Look again on a schedule. New apps get connected every month, and settings drift as tenants are reconfigured. A standing quarterly review of consented apps and these two settings is the difference between a one-off clean-up and the same pile quietly rebuilding.

None of this needs a security team — it needs an administrator to change two defaults once, and to look at the consented-apps list on a rhythm.

Reviewing consented apps by hand, every quarter, across a live tenant is exactly the chore that slips when the week gets busy. AuthScope watches OAuth grants and consent across Microsoft 365 and Google Workspace continuously and flags the risky ones, so nobody has to remember to look. The two settings above, though, cost nothing but ten minutes — so change those today, whether or not you ever automate the watching.