When do OTPs and MFA stop being enough for customer identity?

Why This Matters for Security Teams

OTP and MFA were designed to reduce password risk, not to prove that the right person is presenting the right device in the right context. That distinction matters for customer identity because modern attacks increasingly target the session, the phone, or the recovery path rather than the password itself. Once phishing kits, SIM swap attacks, or device malware enter the picture, a one-time code can still be captured and replayed.

For that reason, current guidance suggests treating OTP as one signal in a broader assurance model, not as the end state for high-risk access. The strongest programs use layered checks such as device binding, behavioural signals, document verification, and transaction-specific step-up controls. NIST’s Cybersecurity Framework 2.0 reinforces the need to manage identity risk as part of a wider resilience strategy, not as a single control point.

NHI Management Group’s Ultimate Guide to NHIs shows why this mindset matters operationally: 79% of organisations have experienced secrets leaks, and 77% of those incidents caused tangible damage. In practice, many security teams discover that OTP is still in place only after account takeover has already occurred, rather than through intentional assurance design.

How It Works in Practice

Moving beyond OTP does not mean removing MFA everywhere. It means matching the authentication strength to the transaction risk and the attack path. For low-risk logins, a push or TOTP challenge may still be acceptable. For account recovery, adding a new device, changing payout details, or accessing regulated data, organisations typically need stronger evidence that combines possession, device integrity, and contextual risk.

In practice, that often includes:

• Device binding so the account is tied to a recognised device or cryptographic key
• Phishing-resistant factors where possible, especially for privileged customer actions
• Liveness detection or document checks for identity proofing and recovery
• Risk scoring that considers IP reputation, geolocation, velocity, and behaviour
• Step-up authentication only when the request crosses a defined risk threshold

This is where the distinction between authentication and assurance becomes important. A code proves access to a channel; it does not prove the session is safe. The NIST Cybersecurity Framework 2.0 supports this layered approach by pushing organisations to reduce identity-related risk through continuous protection and monitoring. NHI Management Group’s 52 NHI Breaches Analysis also illustrates a broader pattern: credential possession alone is rarely enough when attackers are already operating inside trusted workflows. For customer identity, similar logic applies when recovery or transaction flows can be abused through social engineering, device compromise, or session hijacking. These controls tend to break down when customer support can override them too easily because the recovery path becomes the weakest link.

Common Variations and Edge Cases

Tighter identity controls often increase customer friction, so organisations have to balance stronger assurance against abandonment, support burden, and false rejects. That tradeoff is especially visible in consumer banking, healthcare portals, and marketplace platforms where high-risk actions are relatively rare but highly sensitive when they occur.

There is no universal standard for when OTP must be replaced entirely. Best practice is evolving toward risk-based authentication, where OTP may remain acceptable for low-risk access but not for step-up events tied to money movement, credential recovery, or account changes. In those cases, phishing-resistant methods and device-bound credentials are increasingly preferred, while SMS-based MFA is generally treated as weaker because SIM swap and number-port attacks are well understood.

Customer identity also differs from workforce identity because support workflows, identity proofing, and recovery can reintroduce trust through the back door. That is why guidance from NHI Management Group’s Top 10 NHI Issues is still relevant here: any process that issues or re-issues trust must be designed as a control surface, not an administrative convenience. For high-value environments, the practical answer is usually not “more OTP,” but a stronger assurance chain that is proportionate to the action being taken.

Related resources from NHI Mgmt Group

• Why do invisible MFA models depend on identity telemetry?
• Why do MFA and SSO controls still fail against identity-focused intrusions?
• What is the difference between identity proofing and MFA?
• Why do legacy MFA controls fail to stop workforce impersonation attacks?