Notifications
Clear all
Topic starter
08/06/2026 4:18 pm
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.
NHIMG editorial — based on content published by WorkOS: MFA best practices
By the numbers:
- Accounts without MFA are 99.9% more likely to be compromised.
Questions worth separating out
Q: How should security teams implement MFA for privileged accounts?
A: Use phishing-resistant factors such as security keys or passkeys, enforce them through the identity provider, and require them for admins, production access, and sensitive workflows.
Q: Why do MFA fatigue attacks still work in mature environments?
A: They work because repeated push prompts exploit human habit and interface trust, not because MFA is absent.
Q: What breaks when MFA recovery is too easy?
A: The control loses meaning after a device loss, SIM swap, or reset request, because attackers can use the recovery path instead of attacking the primary factor.
Practitioner guidance
- Prioritise phishing-resistant factors for privileged users Make hardware keys, passkeys, or device-bound biometrics the default for admins, finance, and production access.
- Define explicit step-up triggers Use device change, geo-velocity anomalies, suspicious IP ranges, and high-value actions such as password resets or payment approvals to trigger additional verification.
- Cap MFA prompt volume and enforce cooldowns Limit repeated push requests within a short window, require alternate factors after repeated attempts, and flag accounts that generate unusual approval volume.
What's in the full article
WorkOS's full article covers the implementation detail this post intentionally leaves for the source:
- Specific MFA factor selection guidance for B2C versus B2B application design
- Operational examples of risk-based challenge triggers and prompt thresholds
- UX and recovery flow patterns for support teams and product engineers
- Implementation detail on logging, challenge expiry, and secure factor re-enrollment
👉 Read WorkOS's MFA best practices guide for B2C and B2B apps →
MFA design gaps in B2C and B2B apps: are your controls keeping up?
Explore further
08/06/2026 5:51 pm
MFA is a governance layer, not a checkbox, because the security outcome depends on factor strength, recovery design, and enforcement scope. The article shows that teams can have MFA in place and still leave usable attack paths through weak fallback methods, inconsistent rollout, or user fatigue. For identity governance, that means the control must be judged by how it behaves under pressure, not by whether it exists in policy. Practitioners should treat MFA as an operating model, not a feature toggle.
A few things that frame the scale:
- Accounts without MFA are 99.9% more likely to be compromised, according to Microsoft Midnight Blizzard breach.
- A separate NHI research finding shows that when AWS credentials are exposed publicly, attackers attempt access within 17 minutes on average, and as quickly as 9 minutes in some cases.
A question worth separating out:
Q: How do teams know if MFA is actually working?
A: Look for universal coverage, low exception rates, low prompt abuse, and a small number of carefully monitored recovery events. If privileged accounts can bypass enforcement, or if users can repeatedly approve suspicious prompts, the programme is only partially effective. Strong MFA should reduce compromise risk without creating hidden paths around the control.
👉 Read our full editorial: MFA best practices for B2C and B2B identity programs
