It is only defensible as a tightly governed exception for limited recovery or transition use cases, not as the default login factor for sensitive accounts. If OTP remains easy to invoke, it becomes the weakest path in the authentication stack and weakens the overall passkey programme.
When OTP is a defensible fallback, and when it is not
OTP can be kept only when it has a narrow purpose that does not undercut the stronger primary factor. That usually means account recovery, temporary transition support, or exceptional access for customers who cannot yet complete passkey enrolment. It should not remain the normal alternative path for routine sign-in on sensitive banking accounts.
The practical test is whether OTP is serving as a controlled recovery mechanism or as an easy bypass. If a customer can repeatedly choose OTP instead of phishing-resistant authentication, the fallback has become part of the everyday login design and the security model has already weakened.
Why OTP weakens a passkey programme if it stays too easy to use
Passkeys are meant to move the default authentication path to a phishing-resistant method. OTP reintroduces risks that passkeys are designed to remove, including relay attacks, phishing, token interception, and social engineering against the fallback channel. The more visible and convenient OTP is, the more likely it is to become the path attackers probe first.
That is why the issue is not whether OTP exists at all, but whether it is constrained enough that the organisation can still claim passkeys are the real control baseline. A fallback that is simpler to trigger than the primary factor tends to become the weakest link in the journey, especially where customers manage money, personal details, or high-value transfers.
For teams designing the journey, the right question is whether OTP is still protecting recovery, or whether it is quietly functioning as a second mainstream login option. If it behaves like a routine option, the programme has effectively preserved a weaker MFA path instead of eliminating it.
What a safe OTP exception looks like in banking
A safe exception is tightly governed, time-bound, and intentionally less attractive than the passkey path. It should be limited to defined recovery cases, high-friction transitions, or users who have not yet migrated, and it should be reviewed as part of the customer authentication policy rather than left to product-level convenience.
In practice, that means the fallback should be bound to tighter conditions than ordinary sign-in, with clear expiry, strong step-up rules, and an explicit plan to phase it down. The exception should also be monitored for abuse, because attackers often test fallback routes when the primary factor is hard to defeat.
NHIMG’s MFA Guide is useful here because it frames OTP as one option inside a broader authentication mix, not as an equivalent substitute for phishing-resistant factors.
Risk and Threat Considerations
OTP becomes risky when it remains the easiest path around a stronger authentication programme. In banking, that creates a predictable downgrade route for phishing, SIM swap, OTP interception, and help-desk manipulation, especially when the fallback is reachable without strong friction or business justification.
Failure mechanism: The organisation preserves a weaker factor as a standing or easily invoked alternative, so an attacker targets the path of least resistance instead of the passkey. That can defeat the intended security uplift even if passkeys are technically deployed.
Impact: Account takeover becomes more feasible, and the bank may keep a high-volume fallback channel that attackers can repeatedly test at scale. It also weakens customer trust in the migration programme because the new control no longer clearly displaces the old one.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-63, NIST SP 800-53 Rev 5, CIS Controls v8 and OWASP ASVS set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-63 | Digital Identity Guidelines | Phishing-resistant authentication and authenticator assurance are central to passkey vs OTP decisions. |
| Recommendation — Use phishing-resistant authenticators as the default and constrain OTP to limited recovery cases. | ||
| NIST SP 800-53 Rev 5 | IA-2 — Identification and Authentication (Organizational Users) | Banking customer sign-in policy depends on strong authentication requirements and fallback design. |
| Recommendation — Require strong authentication for primary access and limit weaker fallback paths. | ||
| CIS Controls v8 | CIS-5 — Account Management | Safe fallback handling depends on governing account access paths, exceptions, and lifecycle changes. |
| Recommendation — Review and restrict alternate access paths, exceptions, and account recovery settings. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | The question is about controlling access methods and preventing weaker authentication from becoming default. |
| Recommendation — Define and enforce access rules that keep weaker authentication as a tightly governed exception. | ||
| OWASP ASVS | V6 — Authentication | The subject is authentication strength, fallback design, and recovery-path abuse. |
| Recommendation — Verify that weaker recovery factors do not undermine the intended primary authentication model. | ||
Practitioner Guidance
What to prioritise: Treat OTP as a migration or recovery control, not a parallel everyday login method. If customers can routinely choose it, the control has already expanded beyond the safe exception boundary.
What to verify: Check whether OTP use is time-limited, exception-approved, and instrumented for review. If the bank cannot explain who may use it, for how long, and for what account states, the fallback is not governed tightly enough.
Decision rule: If the account is sensitive enough to justify passkeys, then OTP should require additional gating and should not be the easiest path back into the account. If it is easier than the primary factor, remove that convenience before scaling the passkey rollout.
Practitioner takeaway: Keep OTP only where you can prove it is a controlled recovery bridge, not an alternate sign-in habit. The moment it becomes the default escape hatch, it stops being a fallback and starts being the security exception that attackers will try first.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 11, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org