When MFA is bypassed, why is backup your last line of defence?

How do attackers bypass MFA?

Mostly by not breaking MFA at all. They steal the proof that MFA already happened, trick the user into completing it for them, or keep asking until the user says yes.

An IT manager gets an alert: an admin account has been deleting SharePoint libraries for two hours. No failed logins, no MFA prompts. The attacker didn't break in; they used a session that a real user had already authenticated. That's why identity security needs a recovery plan behind it, and why backup as a service belongs in the same conversation as MFA.

The best-known fatigue case is Uber in September 2022. According to Uber's own security update, an attacker bought a contractor's password, sent repeated two-factor requests and the contractor "accepted one", which gave the attacker access to internal tools including G-Suite and Slack.

How common are MFA bypass attacks?

Common enough that European and vendor threat reports single them out. Most identity attacks still target passwords, but the techniques that defeat ordinary MFA are now part of the standard toolkit.

• The ENISA Threat Landscape 2025 analysed 4,875 incidents in the EU between July 2024 and June 2025. It names phishing as a primary route in, highlights infostealers and session hijacking, and lists MFA bypass and adversary-in-the-middle attacks among the tactics in use. It calls ransomware the most consequential threat to EU organisations.
• Microsoft's Digital Defense Report 2025 says more than 97% of identity attacks are password attacks, that phishing-resistant MFA can block over 99% of identity-based attacks, and that infostealers are used to harvest credentials and browser session tokens at scale.
• According to Help Net Security's summary of the Verizon 2026 DBIR, ransomware was involved in 48% of breaches and the human element in 62%.

The conclusion isn't that MFA is useless. It's that MFA, ideally phishing-resistant, stops most attacks, and you need a plan for the ones it doesn't.

What can an attacker do with a hijacked admin session?

Anything that account is allowed to do. To your systems, the attacker is the legitimate user, so authentication-based controls see nothing wrong.

• Delete files, sites, mailboxes or whole directories.
• Modify or encrypt data, including with ransomware run through admin tools.
• Disable backup jobs, shorten retention or delete backup data that sits in the same tenant.
• Add their own MFA method or mailbox forwarding rules to stay in.
• Download large volumes of data for extortion.

Microsoft's playbook lists mass file downloads, new MFA methods, and new or edited mailbox forwarding and inbox rules as signs to watch for. In the AiTM campaign Microsoft described, attackers opened compromised mailboxes within minutes, searched for payment emails and created inbox rules to hide replies before attempting invoice fraud.

Time is on the attacker's side. Identity-based breaches are often found days or weeks later, and an attacker with that much time will look for your backups before you notice.

Does backup still protect you if the attacker has admin rights?

Yes, but only if the backup is out of that admin's reach. A backup that shares credentials or single sign-on with production can be disabled or deleted by the same hijacked session.

The NCSC UK principles for ransomware-resistant cloud backups set the bar. Destructive requests from customer accounts, including administrators, should be forbidden or authorised out-of-band; deletion requests can be delayed for an agreed period; and privileged actions should trigger alerts.

Our backups follow the same thinking. They're immutable with Object Lock, an air-gapped copy is kept in line with the 3-2-1-1-0 rule, admin actions require MFA, the platform is monitored 24/7, and backups are scanned for malware so you don't restore the attacker's tools.

How do you recover after an identity-based attack?

Contain the identity first, then restore. Restoring while the attacker still holds a valid session means they can destroy the restored data again.

1. Contain: block the account, revoke sessions, reset passwords and remove MFA methods you didn't add, as Microsoft's token theft playbook describes.
2. Scope: use sign-in and audit logs to find the first malicious action and every system the account touched.
3. Pick a clean restore point: one from before that first action, not the most recent one.
4. Restore: granularly for files and mailboxes, or boot VMs instantly in an isolated recovery environment on a separate, clean network to check them first.
5. Remove persistence: inbox rules, forwarding, OAuth app consents and new devices.
6. Report: under NIS2 Article 23, significant incidents need an early warning within 24 hours, a notification within 72 hours and a final report within one month. A personal data breach may also need reporting within 72 hours under GDPR Article 33.

For critical workloads, we restore on a 4-hour SLA. For the wider picture, read how long ransomware recovery takes and how to recover Microsoft 365 after ransomware.

How do you make MFA harder to bypass?

Move to phishing-resistant MFA, bind sessions to trusted devices and protect the endpoints where tokens live. That closes most of the gaps above.

• Phishing-resistant MFA: CISA calls FIDO/WebAuthn and PKI-based methods "the gold standard", resistant to phishing, push bombing and SIM swaps.
• Conditional access: require compliant devices and check location and risk for admin sign-ins.
• Token controls: Microsoft recommends continuous access evaluation, token protection and shorter session lifetimes.
• Endpoint security: infostealers run on devices, so detect malware and patch vulnerabilities there. MSPs can use our EDR platform, with malware detection, vulnerability management and MITRE ATT&CK mapping, to run that service for their clients.
• Separate admin identities: keep backup administration on different credentials from day-to-day accounts.

What to do next

Keep MFA and make it phishing-resistant. Then assume that one day a session will be stolen anyway, and make sure the damage can be undone. That means a backup the attacker can't reach: immutable, under separate credentials, with an air-gapped copy and restores you've tested.

Check one thing today: could your Global Admin account delete your backups? If the answer is yes or "not sure", that's the gap to close first. Our backup as a service overview shows how the isolated layer works.

Want to see how a restore works after a compromised admin account? Book a free 15-minute demo in Dutch, German or English.

This article is information, not legal advice.