Topic starter
06/07/2026 9:42 am
TL;DR: Customer MFA is moving beyond static second factors toward adaptive, context-aware flows that combine passkeys, OTP, biometrics, and step-up checks for sensitive actions, according to Descope. The governance issue is not whether MFA exists, but whether it is tuned for customer journeys, tenant complexity, and fraud exposure without adding avoidable friction.
Editorial analysis by NHI Mgmt Group, based on content published by Descope: “Top 7 Customer MFA Solutions: Strengths & Comparisons”.
Key questions
Q: How should teams implement customer MFA for external users across different tenants?
A: Start by separating policy by tenant, user segment, and application risk level.
Q: When should organisations add step-up authentication during a session?
A: They should add step-up authentication when the action is higher risk than the original login, such as privileged resource access, unusual device changes, or a suspicious location shift.
Q: What breaks when customer MFA is designed as a one-size-fits-all control?
A: It usually fails in two ways: either it adds too much friction for low-risk users or it leaves high-risk journeys under-protected.
Practitioner guidance
- Define tenant-specific MFA policy Set separate authentication requirements for consumer, partner, and B2B tenant populations so one policy does not over- or under-protect every external user group.
- Add step-up checks for sensitive actions Require additional verification before payment changes, address changes, fund movement, or other high-risk in-app actions rather than only at sign-in.
- Use contextual risk signals Base prompts on device trust, IP reputation, and session behaviour so routine logins stay low-friction while higher-risk sessions are challenged.
Bottom line: Customer MFA is most effective when assurance changes with context rather than remaining fixed across every login.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
06/07/2026 9:58 am
Adaptive customer MFA is now a governance problem, not just an authentication feature. External user flows vary too widely for a fixed second-factor model to hold up across consumers, partners, and SaaS tenants. The more an organisation relies on one-size-fits-all MFA, the more it forces either excess friction or weak assurance into the same journey. Practitioners should treat MFA policy as part of identity governance, not as a login checkbox.
A few things that frame the scale:
- 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: Why do customer MFA policies need strong recovery and factor-management flows?
A: Because external users lose devices, change channels, and forget enrolled factors more often than internal workers do. If enrollment and recovery are weak, support teams end up bypassing the intended assurance model to restore access. That turns recovery into the weakest part of the control instead of a governed part of the lifecycle.
👉 Read our full editorial: Customer MFA solutions for external users need adaptive controls