TL;DR: MFA remains one of the most effective defences against account takeover, phishing, credential stuffing, and brute force attacks, but teams still struggle to balance assurance, recovery, and usability across consumer and enterprise apps, according to WorkOS. Strong MFA is no longer a point control; it is a programme design choice that must align factor strength, risk-based challenge policy, and lifecycle recovery.
Editorial analysis by NHI Mgmt Group, based on content published by WorkOS: “MFA best practices”.
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 prioritize adaptive MFA over forcing MFA on every login?
A: Organisations should prioritize adaptive MFA when they need stronger assurance for risky sessions without turning every login into a high-friction event.
Q: What are the warning signs that MFA fatigue is in progress?
A: Look for many MFA requests in a short time, repeated denials or cancellations, unusual access geography, and a successful approval after a burst of failures.
Practitioner guidance
- Enforce phishing-resistant MFA for privileged users Require passkeys or hardware security keys for admins, root accounts and developer access, and keep weaker methods only as constrained fallback.
- Define risk-based step-up triggers Step up authentication for password resets, payments, new devices, suspicious IP ranges and geo-velocity anomalies across every app.
- Harden recovery and reset flows Treat backup codes, help desk resets and device re-enrolment as high-risk identity events, with extra verification and logging.
Bottom line: MFA is effective only when factor choice, recovery and step-up policy are governed as one programme instead of separate login features.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
MFA is no longer a control decision, it is an assurance design decision. The article shows that organisations can deploy MFA and still leave major gaps if factor strength, fallback and step-up policy are inconsistent. For IAM teams, the real question is whether the MFA programme meaningfully changes attacker cost across both consumer and enterprise journeys.
A few things that frame the scale:
- 43% of security professionals are concerned about AI systems learning and reproducing sensitive information patterns from codebases, according to the State of Secrets in AppSec.
- Across one million observed logins, 1 in 4 were password-based rather than SSO, 2 in 5 were not protected by MFA and 1 in 5 used a weak, breached or reused password.
A question worth separating out:
Q: What should teams look for in authentication recovery and MFA design?
A: Teams should focus on how an account is recovered when the primary authentication path is unavailable or attacked. Strong primary MFA is not enough if the reset path is weak, because attackers often target recovery. The right test is whether fallback verification, escalation, and logging all preserve the same security standard as sign-in.
👉 Read our full editorial: MFA best practices for B2C and B2B identity programs