OTP authentication is losing ground in high-assurance access

At a glance

What this is: This article explains why OTP remains common but is losing suitability for high-assurance access because modern interception, relay, and telecom attacks can defeat it without breaking cryptography.

Why it matters: IAM teams need to distinguish between a code that expires quickly and a control that actually resists phishing, interception, and account takeover in high-risk workflows.

Context

OTP authentication is a possession-based control: the user proves access to a device, inbox, or token by entering a short-lived code. That model works only while the delivery path and receiving device remain trustworthy, which is exactly where modern attackers now focus.

For identity programmes, the question is not whether OTP is better than a password. It is whether the assurance level is high enough for the access decision being made, especially where account recovery, financial transfer, or privileged login is at stake.

Key questions

Q: What breaks when OTP is used for high-assurance access?

A: OTP breaks when the organisation treats possession of a device or inbox as strong enough proof for sensitive actions. Attackers can redirect the code path, relay the code in real time, or compromise the device itself, so the login appears valid even when the underlying trust assumption has failed.

Q: Why do OTP codes remain vulnerable even when they expire quickly?

A: Short expiry reduces replay risk, but it does not protect the delivery channel or the user session. If an attacker can intercept, forward, or relay the code before expiry, the authentication succeeds on the attacker’s timeline rather than the defender’s.

Q: How do security teams know when OTP is no longer appropriate?

A: OTP is no longer appropriate when a successful bypass would materially affect money movement, account recovery, or privileged access. Those journeys need phishing-resistant methods because the control objective is resistance to interception and relay, not merely one-time code generation.

Q: What should organisations do when mobile numbers or inboxes are the second factor?

A: Organisations should assume the second factor is only as strong as the weakest delivery path. If the business still relies on phone numbers or email inboxes, it should add stronger verification for sensitive steps and reduce OTP exposure in recovery and transaction flows.

Technical breakdown

Why SMS OTP breaks under telecom interception

SMS OTP relies on the mobile network to deliver a code to the right number at the right time, but the code is not cryptographically bound to the handset. That creates exposure to SIM swapping, SS7 interception, and network-level relay attacks. In practice, the attacker does not need to defeat the OTP algorithm. They only need to redirect or intercept the message path, which leaves the possession factor intact on paper but not in reality. This is why SMS-based second factors are increasingly treated as low-assurance, especially where account takeover would cause material harm.

Practical implication: Treat SMS OTP as unsuitable for high-assurance access and remove it from the strongest authentication journeys.

Why app-based TOTP still fails in real time

TOTP improves on SMS because the code is generated locally and is not transmitted over the carrier network. Even so, it still only proves possession, not the authentic identity of the person using the device. Real-time phishing toolkits can capture the code, relay it to the legitimate service before expiry, and complete the session. The result is a valid login that was fully attacker-mediated from the moment the user entered credentials. TOTP also becomes weaker when the same device holds both the authenticator and the active session, because the two factors collapse into one physical control point.

Practical implication: Do not assume authenticator-app codes deliver phishing resistance or sufficient separation of factors.

Why biometric face verification changes the assurance model

Face verification with liveness detection shifts the factor from possession to inherence, which makes the authentication event much harder to intercept, port, or replay. The article’s key point is not that biometrics are perfect, but that they remove the dependency on phone numbers, code entry, and network-delivered secrets for high-risk access decisions. When the control also confirms live presence, the authentication step becomes materially harder to relay through a proxy page or compromised inbox. For high-assurance use cases, that changes the control objective from code delivery to identity presence.

Practical implication: Reserve biometric verification for journeys where phishing resistance and genuine presence matter more than code-based convenience.

Threat narrative

Attacker objective: The attacker’s objective is to complete a fraudulent authenticated session and drain accounts or access protected services without triggering effective resistance.

1. Entry occurs when attackers harvest login credentials through phishing or social engineering and then target the OTP delivery path rather than the password itself.
2. Credential access is achieved by intercepting or redirecting the one-time code through SIM swapping, SS7 abuse, or real-time proxy phishing.
3. Impact follows when the attacker replays the captured code fast enough to complete the authenticated session and perform unauthorised account actions.

Breaches seen in the wild

• Uber breach 2022: A contractor's stolen password and MFA fatigue gave a Lapsus$-linked attacker Uber's internal tools; Uber rotated keys to many services.
• Microsoft Midnight Blizzard breach: Midnight Blizzard (APT29) exploited legacy test account without MFA to breach Microsoft.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

OTP is not collapsing because codes stopped expiring. It is collapsing because the delivery path, session timing, and user-device trust assumptions no longer hold. OTP was designed for a world where the receiver path was hard to interfere with and the code entered manually was the decisive control. That assumption fails when attackers can redirect numbers, intercept messages, or relay codes in real time. The implication is not that short-lived codes became obsolete overnight, but that assurance must now be measured against interception resilience, not token freshness.

High-assurance access is no longer a possession-factor problem alone. OTP proves access to a channel, not the identity of the person using it, and that distinction matters when the login event is tied to payments, account recovery, or privileged actions. Biometric face verification and other phishing-resistant methods are rising because they change the control question from 'who has the code?' to 'is the right person present right now?' For identity programmes, that is a different assurance model, not just a different user experience.

SMS OTP should now be treated as an availability of channel issue as much as an authentication issue. The control fails when mobile carriers, inbox security, or relay infrastructure become the weakest link, which makes the threat surface broader than the login page. This is why NIST SP 800-63B’s restrictions on SMS-based factors matter: the framework is recognising a structural weakness in the trust chain, not a usability preference. Practitioners should read that as a signal to separate convenience from high-risk assurance.

OTP's real limitation is that it can be defeated without breaking the authentication math. That is a governance problem as much as a technical one, because controls that appear strong in policy can still be bypassed in operational reality. The better test is whether the method survives modern phishing relay, telecom redirection, and device compromise. Where it does not, the assurance gap belongs in access design, step-up policy, and recovery flows.

Named concept: verification path trust debt. OTP programmes accumulate trust debt when they depend on delivery channels, device state, and user action that are no longer reliably under the organisation’s control. Once that debt grows, the organisation is no longer governing authentication strength, it is governing assumptions about transport reliability and human reaction speed. Practitioners should treat that as a sign to reclassify which journeys still deserve OTP at all.

What this signals

Verification path trust debt: OTP programmes fail when organisations continue to trust delivery channels that attackers can now redirect, intercept, or relay in real time. The control looks familiar, but the trust model underneath it has changed, which means assurance decisions need to shift away from code freshness and toward channel resilience.

The next governance question is where OTP still belongs. If the journey involves recovery, payments, or privileged access, a possession-based factor is no longer enough on its own, and the control design should reflect that before an incident forces the change.

For practitioners

• Reclassify high-risk journeys Move payments, account recovery, and privileged access out of OTP-only flows and into phishing-resistant authentication methods with stronger assurance properties.
• Retire SMS OTP from strong assurance paths Keep SMS-based codes only where the business accepts lower assurance, and remove them from workflows that would be materially harmed by interception or SIM swapping.
• Separate authenticator and session devices Avoid workflows where the same phone or browser session both generates the OTP and completes the transaction, because that collapses the intended factor separation.
• Harden recovery and step-up controls Treat account recovery, reset, and step-up prompts as the real attack surface, because attackers often bypass the normal login path and target the fallback journey instead.

Key takeaways

• OTP still adds protection compared with static passwords, but it no longer provides enough assurance for the highest-risk access journeys.
• The dominant failure mode is not code reuse but interception, relay, and device or channel compromise.
• Security teams should move sensitive workflows toward phishing-resistant verification and keep OTP only where lower assurance is acceptable.

Key terms

• One-Time Passcode Check: A one-time passcode check is a verification step that proves control of a phone number or other registered channel by requiring a short-lived code. It is a common authentication signal in onboarding and step-up flows. By itself it does not prove identity, but it strengthens confidence that the applicant controls the claimed contact point.
• Phishing-Resistant Authentication: Phishing-resistant authentication proves identity without relying on a user to approve a prompt or reveal a reusable secret. It typically binds access to a device, key, or cryptographic proof that an attacker cannot easily reuse or coerce. This approach reduces reliance on human judgment at login time.
• Adversary-in-the-middle Attack: An adversary-in-the-middle attack intercepts and relays authentication in real time between the user and the legitimate service. It is especially dangerous for OTPs because the attacker can capture the code while it is still valid and immediately use it to complete login.
• High Assurance Authentication: Authentication that gives a higher level of confidence in the user’s identity than password-only login. In healthcare, it usually combines stronger factors, device context, or approved authenticators so staff can access sensitive systems securely without turning clinical work into a manual checkpoint.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.