MFA still matters, but the biggest Entra ID attacks now happen after sign-in, so if you want to see how prompt fatigue, stolen tokens, and hijacked sessions are slipping past trusted access, read the full post.
You can enable MFA and still lose control of an Entra ID environment.
It still blocks a huge amount of routine phishing and password abuse. The problem is that attackers have adapted. Rather than trying to beat MFA head-on, they pressure users into approving prompts, steal the tokens and cookies issued after sign-in, or take over an already authenticated session. Public cases such as Uber’s 2022 breach, Cisco’s 2022 compromise and wider adversary-in-the-middle phishing campaigns show the same pattern clearly: once trust has been granted, attackers try to reuse it.
For Entra ID teams that means identity defence is no longer just about the login but about the full chain: sign-in, session use, device trust, and how quickly access can be cut off when something goes sideways.
While we’re saying it can’t fully prevent attacks, we don’t mean you should do away with MFA. It remains a baseline control.
Modern identity attacks often happen around MFA rather than through it:
In all three cases, the attacker may end up inside Microsoft 365 and cloud apps without needing to start from scratch. Campaigns using AiTM infrastructure have done exactly that, stealing credentials and session cookies and then using mailbox access for follow-on business email compromise.
And unless your team is aware of it, they may think they’re covered with MFA and assume the identity layer is handled. Meanwhile, the real pressure points have shifted to session theft, token replay, unmanaged devices, and weak post-login detection.
These patterns overlap in the wild but separating them helps because each creates different blind spots.
MFA fatigue, also called prompt bombing or MFA exhaustion, is the psychological version of brute force. The attacker gets valid credentials first, then keeps triggering approval requests until the user finally accepts one. Sometimes they add a call or message pretending to be IT support to push the victim over the line.
Uber’s 2022 breach remains the clearest example. The company said an attacker likely bought a contractor’s password after malware infected the contractor’s personal device. The attacker then repeatedly pushed login approvals until one was accepted.
Cisco was hit by a similar tactic in 2022. The company said an attacker gained credentials tied to a personal Google account and then used repeated voice-phishing and MFA push manipulation to get access.
This example shows the dangers of improper MFA implementation – if the settings are too strict and users are prompted every time they log on, they get annoyed. As a result, push-heavy approval flows can train users to treat security decisions as background noise. Once that happens, MFA becomes something to clear rather than something to evaluate.
Tokens are the proof that authentication has already happened. If an attacker steals that proof and successfully reuses it, they may not need the password or the second factor again.
And that’s where the compromise becomes difficult to spot: Rather than smashing the front door in, the attacker gets in through it being left ajar. Activity can look close to normal, especially if device, browser, or network context is weak or noisy.
This also changes containment. Resetting the password may not be enough on its own. If the attacker still has a usable session or token, they may keep operating until sessions are revoked, authentication methods are reviewed, and the affected endpoint is investigated.
Session hijacking is the practical outcome defenders care about most. The attacker takes over an authenticated session instead of logging in cleanly themselves.
That often happens through stolen session cookies or adversary-in-the-middle phishing kits that capture credentials and session data in transit. Publicly reported AiTM campaigns targeting more than 10,000 organisations used stolen credentials and session cookies to access mailboxes and run business email compromise operations.
This is why session abuse is so tricky. From the service’s point of view, the session can still look valid. The user signed in. Access was granted. The browser looks plausible enough. The only problem is that the person driving the session is no longer the legitimate user.
In Entra ID environments, you can feel the snowball effect real quick. A hijacked session can open the door to email, files, Teams, SaaS applications, and administrative workflows without much extra friction.
The encouraging part, if we are allowed a crumb of optimism, is that these attacks usually leave clues. The frustrating part is that the clues are often weak on their own.
A single denied MFA prompt may mean nothing. A new browser may mean nothing. An odd sign-in location may just be a VPN doing VPN things. What matters is correlation.
For MFA fatigue, the strongest signal is repeated prompt activity followed by an eventual approval that does not fit the user’s normal behaviour. Uber turned that pattern into a household example for security teams.
For token theft and session hijacking, the signs are subtler. Watch for:
No single event proves compromise. Together, though, they often sketch the outline before the attacker has finished colouring it in.
Conditional Access is one of the strongest controls in Entra ID, but only if it is built around attacker behaviour.
In practice, that means
Public attacks against Microsoft 365 accounts have repeatedly shown that once a session is stolen, the fight moves to device trust, session control, and speed of containment.
It also means using device compliance properly. A sensitive app accessed from a hardened managed endpoint should not be treated the same way as the same app accessed from a random unmanaged laptop with a dubious browser state.
What should be avoided is just as important:
A policy can technically require MFA and still leave attackers with plenty of room if session reuse, unmanaged-device access, and method registration are loosely governed.
While risk-based policies are useful, they shouldn’t be treated as the holy grail of cybersecurity.
They help when suspicious sign-in behaviour is happening in front of you. They can trigger extra checks, block questionable access, and help analysts prioritise investigations.
They help less when the attacker is already operating inside a valid session. If the trust decision has already been made and the stolen access still looks plausible, sign-in risk alone becomes a weaker signal.
That makes these policies valuable but situational. They are good at spotting strange activity at the front door. They are less impressive once the burglar is already inside with the right access codes to sensitive areas.
Ergo: it’s all about giving analysts the tool, but it won’t help you solve cybersecurity just by existing.
If attackers want reusable access, then device trust and session control matter more.
Managed and compliant devices reduce the attacker’s room to reuse stolen access outside the expected trust boundary. Session lifetime and sign-in frequency controls reduce how long stolen access remains useful. Endpoint and browser visibility matter because session hijacking often shows up as unusual browser behaviour, odd client attributes, or cloud app access patterns that do not fit the user.
The goal is not to drown people in prompts because that’s exactly how you trigger MFA fatigue. Instead, make stolen access harder to replay, easier to detect, and faster to revoke.
If this piece does one useful thing, it should be this: get more teams monitoring identity attacks as identity attacks, not just failed logins.
Start with the patterns that show up early and matter most:
That last is especially important. If the attacker is using a stolen session or replayed token, resetting the password alone may not end the problem.
MFA still matters, but attackers are now going after the session around it. Uber’s 2022 breach showed how MFA fatigue can turn valid credentials into access. Wider AiTM campaigns showed the next stage: once attackers capture tokens or hijack a live session, they can move through cloud services with far less resistance than teams expect.
The lesson for you? Identity security is no longer just about who logged in but about who is still using the session, from which device, under what conditions, and how quickly you can cut off access when something goes wrong.