You have multi-factor authentication. So did Uber when they got breached. So did Cisco. So did MGM Resorts.
The attacker didn't crack their MFA. They used it against them.
What follows isn't an argument against MFA. It's an argument for the right kind — and an honest look at why most organisations don't have it, what that costs them, and what the path forward actually looks like.
Five things. All of them verifiable. All of them fixable. None of them requiring a complete infrastructure rebuild.
Most Enterprise MFA Has Three Known Back Doors
When an organisation deploys MFA, they typically solve one problem: an attacker cannot log in with a stolen password alone. What most deployments don't solve is an attacker who has the password and can bypass the second factor.
Push notification fatigue. The attacker obtains valid credentials and triggers repeated push notifications until a user approves one to stop the interruption. Used in the Uber breach (2022), documented in dozens of enterprise incidents since. Requires no technical sophistication beyond a valid credential.
Adversary-in-the-middle proxy. A fake login page relays credentials and OTP codes to the real site in real time — before the code expires. The user sees nothing unusual. Freely available toolkits make this accessible to low-skill attackers.
SIM swapping. The attacker redirects SMS authentication to a device they control by social engineering the victim's mobile carrier. Requires no access to your organisation's systems whatsoever.
All three attacks succeed because they target a shared secret — a code, a notification approval, a phone number — that can be intercepted or relayed. The solution is not to patch these methods. It is to replace them with authentication that has no shared secret.
Ask your vendor one question: does our current authentication depend on a code, notification, or message that could be intercepted between the user and our systems? For push, OTP, and SMS MFA — the answer is yes. That acknowledgement is your starting point.
Phishing-Resistant MFA Is Not the Same as "Stronger" MFA
The typical response to MFA security concerns is to add controls to what already exists — adaptive authentication, anomaly detection, risk-based step-up. These reduce the attack surface. They do not eliminate the structural weakness.
Phishing-resistant authentication is architecturally different, not incrementally stronger. The credential is generated on the user's device and never leaves it. It is mathematically bound to the specific domain of the legitimate site. Authentication requires cryptographic proof of possession — not knowledge of a secret.
Push fatigue attacks have nothing to push. Adversary-in-the-middle proxies receive a credential mathematically useless on a fake domain. SIM swapping is irrelevant because there is no SMS in the flow.
This is why CISA, ENISA, and NIST all designate FIDO2/WebAuthn-based authentication as the standard for phishing-resistant controls — not because it is more complex, but because it is structurally different.
Before your next identity platform review, establish a clear internal standard: we will only accept authentication methods that are phishing-resistant under NIST AAL2/AAL3 criteria. This shapes your vendor evaluation rather than letting the vendor define what "secure" means.
You Don't Need Biometrics or Hardware Tokens to Get There
The most common objection to phishing-resistant MFA adoption is deployment complexity. The assumed model is hardware security keys — physical tokens that must be purchased, distributed, and managed for every user. For a 5,000-person enterprise, that is a material logistical and cost problem.
This assumption is out of date. Modern phishing-resistant authentication uses device-bound credentials stored in the secure enclave or trusted platform module of the device the user already owns.
No hardware tokens. The credential lives in the device's secure hardware. No separate equipment to procure, distribute, or manage.
No biometrics stored centrally. Any device-based biometric verification is processed locally. The biometric data never leaves the device and is never transmitted to or stored by the authentication system.
No reusable credentials. Each authentication is a unique cryptographic exchange. There is no credential to steal from a database because no reusable credential exists.
GDPR-compliant by design. Because no sensitive personal data is processed or stored centrally, the compliance implications are significantly simpler than traditional MFA systems.
Inventory your device estate. Phishing-resistant MFA works on any device manufactured in the last five to seven years with a trusted platform module or secure enclave — which is most enterprise device fleets. A pilot with a defined user group can generate operational evidence without an organisation-wide commitment.
It Costs Less Than What You're Currently Paying
The assumption that superior security costs more is wrong in this case. Phishing-resistant authentication is available at a per-user cost materially below the Okta or Microsoft tiers most enterprises are currently running.
For a 2,000-user enterprise moving from Okta Essentials, the annual saving is typically £150,000–£200,000 — with a materially better security outcome and no hardware procurement.
Get a comparison quote before your next renewal. If your Okta or Microsoft identity contract renews in the next 12 months, run the numbers now — not at renewal when the incumbent has all the leverage.
NIS2 Has Drawn a Line Your Current MFA May Not Cross
NIS2 Article 21 requires appropriate technical measures including multi-factor authentication. The guidance following its enforcement is increasingly explicit: push-based MFA, OTP codes, and SMS authentication are not considered phishing-resistant under current NIS2 and DORA guidance for regulated environments.
NIS2 — enforceable since October 2024. Covers essential and important entities across energy, financial services, healthcare, transport, telecoms, and digital infrastructure in the EU and equivalent UK frameworks. Push and OTP MFA does not satisfy phishing-resistant authentication requirements.
DORA — fully in force since January 2025. Financial entities must implement ICT risk management measures including MFA resistant to phishing and social engineering. Standard push and OTP methods do not satisfy this description.
Personal liability — NIS2 Article 20 makes management bodies personally liable for non-compliance with cybersecurity governance requirements. The authentication standard your organisation operates is a governance decision, not just a technical one.
Map your current MFA method against NIS2/DORA requirements explicitly — not via your vendor's compliance marketing. Ask your legal or compliance team to document whether your current authentication satisfies the phishing-resistance standard as interpreted by your national competent authority. Then build the compliance case: a phishing-resistant MFA migration documented as a NIS2/DORA compliance measure has a different internal funding conversation than a security improvement with uncertain ROI.
What Happens Next
The honest version.
We wrote this guide because the information in it is genuinely useful — and most organisations only engage with it after a breach has made the conversation unavoidable. If you're reading this before anything has gone wrong, that's the right time.
Three things worth doing this quarter:
If you'd like an independent assessment of your current MFA position — no commitment required — we're happy to have that conversation.