Topic starter
07/03/2026 12:58 am
TL;DR: Passwords remain easy to steal, and legacy MFA that depends on SMS codes or other phishable factors can still leave accounts exposed to takeover, according to Beyond Identity and Google. The security problem is not MFA in name but whether the second factor actually resists phishing, SIM swapping, and token theft.
Editorial analysis by NHI Mgmt Group, based on content published by Beyond Identity: “What Developers Need to Know About Multi-Factor Authentication”.
Key questions
Q: What breaks when MFA is configured with weak, phishable factors?
A: Weak factors such as SMS codes, OTP apps, or push-based approvals can satisfy a policy checkbox while still leaving the environment open to phishing, man-in-the-middle, and push bombing attacks.
Q: When should organisations move beyond MFA to device-bound authentication?
A: Organisations should move beyond MFA when users access high-value systems from unmanaged, remote, or adversarial networks, or when the threat model includes local trust-store tampering.
Q: What do security teams get wrong about MFA in identity attacks?
A: They often assume MFA ends the problem once the code is entered.
Practitioner guidance
- Prioritise phishing-resistant factors Replace SMS codes and similar relayed factors for high-value accounts with cryptographic or hardware-bound methods that are materially harder to intercept or replay.
- Review account recovery paths Check whether password reset, help desk verification, or fallback methods reintroduce the same weakness that your primary MFA step was meant to remove.
- Map MFA by risk tier Assign stronger authentication requirements to privileged users, sensitive workflows, and externally exposed systems instead of applying one MFA pattern everywhere.
Bottom line: MFA only meaningfully reduces takeover risk when the added factor cannot be easily phished, relayed, or redirected.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
08/10/2026 5:05 pm
Phishable MFA is not a second factor problem, it is a factor-quality problem. If the added factor can be relayed, reset, or socially engineered, the control does not materially change the takeover equation. That means identity programmes should stop measuring MFA by deployment count and start measuring it by resistance to phishing, SIM swapping, and token theft. The practitioner conclusion is simple: factor strength, not MFA presence, is the real control variable.
A few things that frame the scale:
- Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap, according to the State of Secrets in AppSec.
A question worth separating out:
Q: When should organisations treat MFA as necessary but not sufficient?
A: Organisations should treat MFA as necessary but not sufficient whenever users can still recover access through weaker routes, reuse credentials or operate on unmanaged devices. MFA blocks many common attacks, but it does not fix bad exception handling or weak access governance. The right standard is whether every access path is held to the same assurance level.
👉 Read our full editorial: Why MFA still fails when it relies on phishable factors