Should regulated environments keep OTPs after adopting passkeys?

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.

Related resources from NHI Mgmt Group

• Why is OAuth token management critical in cloud environments?
• How should security teams authenticate AI agents in enterprise environments?
• What makes OAuth tokens risky in NHI environments?
• When do passkeys work best for regulated or high-assurance environments?