Notifications
Clear all
Topic starter
12/06/2026 10:17 pm
TL;DR: Basic MFA methods such as SMS, OTPs, and push approvals still leave organisations exposed to phishing, SIM swapping, and man-in-the-middle attacks, according to Axiad, while more secure options like FIDO2/WebAuthn and PKI remain underused because teams perceive them as complex and costly. The real issue is that “good enough” MFA often satisfies compliance without materially changing the attack surface.
NHIMG editorial — based on content published by Axiad: Today's “Good Enough MFA” Should Be Phishing-Resistant
By the numbers:
- 93% of organizations are still using passwords at work for business.
- When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes and as quickly as 9 minutes in some cases.
Questions worth separating out
Q: What breaks when organisations rely on basic MFA against phishing attacks?
A: Basic MFA breaks when the attacker can relay, proxy, or socially engineer the second factor in real time.
Q: Why do phishing-resistant factors matter more for privileged accounts?
A: Privileged accounts are the highest-value targets because compromise often leads to broader administrative reach, session abuse, or lateral movement.
Q: How do security teams measure whether MFA is actually protecting the business?
A: Measure whether your strongest factor is enforced on the accounts and applications that matter most, not just whether MFA exists somewhere in the stack.
Practitioner guidance
- Prioritise phishing-resistant MFA for privileged access Move administrators, help desk operators, and remote access users to cryptographic authenticators first, because these accounts carry the highest account-takeover impact and are the easiest to monetise after compromise.
- Retire weak fallback methods and recovery bypasses Remove SMS, OTP, and push-based exceptions wherever possible, and redesign account recovery so it does not quietly reintroduce the same weak factor you are trying to eliminate.
- Map authentication methods to actual assurance levels Inventory which applications still accept weaker second factors, then classify them by business criticality so you can target the highest-risk paths before broadening rollout.
What's in the full article
Axiad's full blog covers the implementation detail this post intentionally leaves for the source:
- How the vendor positions phishing-resistant MFA options such as FIDO2/WebAuthn and PKI in practical deployment terms
- The specific arguments the vendor uses to explain why SMS, OTP, and push methods remain vulnerable to man-in-the-middle abuse
- The operational trade-offs the vendor highlights for teams balancing user experience, cost, and rollout complexity
- The full context behind the vendor's survey claim that 93% of organisations are still using passwords at work for business
👉 Read Axiad's analysis of why good enough MFA is not enough →
Good enough MFA: is your phishing-resistant roadmap behind?
Explore further
13/06/2026 12:57 am
Good enough MFA is an assurance problem, not a checkbox problem. The article shows how organisations can satisfy a policy requirement while still leaving the authentication ceremony vulnerable to phishing, relay attacks, and SIM swap abuse. That means the programme has met the form of MFA without gaining the substance of resistance. Practitioners should treat MFA quality as part of access assurance, not just enrolment coverage.
A few things that frame the scale:
- Two-thirds of enterprises have endured a successful cyberattack resulting from compromised non-human identities, with a quarter encountering multiple attacks, according to The 2024 ESG Report: Managing Non-Human Identities.
- 72% of organisations have experienced or suspect they have experienced a breach of non-human identities, showing that identity compromise is already a mainstream operational issue, not a niche control failure.
A question worth separating out:
Q: Who is accountable when weak MFA remains enabled after a phishing incident?
A: Accountability usually sits across identity governance, security operations, and application ownership because each group can leave a weak path in place. If the control gap was an allowed fallback method, the question is not only who approved it but whether policy, recovery design, and access reviews were aligned with the risk of replayable authentication.
👉 Read our full editorial: Good enough MFA leaves identity teams exposed to phishing
