Yes, in some cases. OTPs can still serve high-assurance or transitional workflows where device binding, backup access, or regulatory interpretation require an additional factor. The key is to limit OTPs to defined exceptions rather than keeping them as the default path for all sign-ins.
Why This Matters for Security Teams
OTPs still show up in regulated environments because compliance, legacy application support, and recovery procedures rarely move in lockstep with passkeys. The practical question is not whether passkeys are stronger, but whether OTPs remain necessary as a constrained exception path. NHI Management Group’s research on the Ultimate Guide to NHIs — Regulatory and Audit Perspectives shows how often identity controls fail when governance is vague, and NIST’s NIST Cybersecurity Framework 2.0 reinforces that authentication choices need to map to risk, not habit. A regulated control can be acceptable and still be a poor default if it broadens the attack surface unnecessarily. In practice, many security teams discover OTP sprawl only after auditors, help desks, or exception-heavy fallback paths have already made it the real standard rather than the temporary one.
How It Works in Practice
The most defensible model is layered: passkeys become the primary authentication method, while OTPs are retained only for narrowly defined cases such as device replacement, account recovery, or a limited set of high-risk workflows where a regulator or internal policy still expects an additional factor. The key operational distinction is that OTPs should be exception-based, time-bounded, and monitored. If they remain broadly available, they quickly become the easiest bypass for phishing-resistant controls.
A practical rollout usually includes:
- Defining which user groups, applications, and jurisdictions can use OTPs.
- Requiring approval or documented justification for OTP exceptions.
- Setting a sunset date for OTP fallback where regulations allow it.
- Logging every OTP challenge, success, and recovery event for audit review.
- Testing whether passkey enrollment and recovery paths are usable enough to avoid OTP dependence.
For regulated identity operations, the question is often less about technology preference and more about control evidence. The Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs is useful here because it illustrates the broader principle: identity methods need lifecycle controls, not just enrollment controls. When that principle is applied to human authentication, the organisation can prove why OTP exists, who can use it, and when it will be removed. These controls tend to break down when recovery workflows are outsourced to the help desk without strong verification and exception tracking.
Common Variations and Edge Cases
Tighter authentication policy often increases operational overhead, requiring organisations to balance phishing resistance against recovery friction and regulatory interpretation. Best practice is evolving, and there is no universal standard that says every OTP must disappear immediately after passkeys are deployed.
Some environments still need OTPs because:
- Legacy SaaS or VPN tooling does not yet support passkeys.
- Audit or contractual obligations require a fallback factor during transition.
- Shared terminals, break-glass access, or constrained devices make passkeys impractical.
- End-user populations have uneven device compatibility or enrollment readiness.
That said, OTPs should not become the permanent safety net for weak enrollment design. If passkey recovery is poorly implemented, OTPs will quietly absorb all failures and undermine the migration. NHI Management Group’s Top 10 NHI Issues highlights a recurring pattern across identity programs: controls intended as temporary exceptions often become long-lived exposure points when ownership is unclear. The right test is simple: if OTP is still needed, it should be because the organisation can name the exception, defend the risk, and retire it on a schedule.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0 and NIST SP 800-63 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AA | Authentication choice should map to risk and identity assurance needs. |
| NIST SP 800-63 | AAL | Defines assurance levels that help justify when OTP is acceptable. |
| OWASP Non-Human Identity Top 10 | NHI-03 | Exception handling and rotation discipline matter for fallback credentials and recovery paths. |
Use phishing-resistant sign-in by default and keep OTP only as a documented exception path.
