Which NIST authentication levels can include one-time passwords?

Why This Matters for Security Teams

One-time passwords can be a valid part of NIST authentication, but the real question is not whether OTPs exist in the standard. It is whether they are being used at the right assurance level, with the right binding to the authenticator, and with the right lifecycle controls. Security teams often misread OTP support as a blanket endorsement, then discover that the control weakness is not the code itself but how it is delivered, replayed, or paired with weak recovery paths.

NIST guidance is explicit that assurance depends on the overall authenticator design, not just the presence of a numeric code. For teams managing secrets and credentials across large environments, that distinction matters as much as the lifecycle issues documented in the Ultimate Guide to NHIs — Standards. In practice, the same pattern appears in both human and non-human identity programs: organisations confuse “can be used” with “should be used,” then inherit avoidable risk.

Where OTPs are used well, they can improve access flow without raising the phishing and replay risks that come with weaker implementations. Where they are used badly, they become another secret to protect, rotate, and recover. In practice, many security teams encounter OTP failure only after an incident has already exposed brittle enrollment, weak fallback, or over-permissive recovery paths.

How It Works in Practice

NIST SP 800-63-3 treats OTPs differently depending on the Authentication Assurance Level. At AAL1, OTPs may be used as part of single-factor or multi-factor authentication after the initial credential is presented. At AAL2, the OTP-generating device can itself be the physical authenticator, which means the device binding and activation process become important. At AAL3, OTPs are only acceptable when they are hardware-based and meet the stronger requirements for impersonation resistance.

That means the implementation question is not “does this login use a code?” but “what exactly is issuing, protecting, and validating the code?” Current guidance from NIST Cybersecurity Framework 2.0 and NIST SP 800-53 Rev 5 Security and Privacy Controls supports layered control selection, but NIST SP 800-63 is the authoritative source for authentication assurance decisions.

• Use OTPs only where the assurance level matches the threat model and user journey.
• Prefer hardware-backed or device-bound OTP methods over shared or easily replicated secrets.
• Treat enrollment, recovery, and re-enrollment as security-critical flows, not helpdesk afterthoughts.
• Align OTP policy with session management, phishing resistance goals, and revocation procedures.

For identity-heavy environments, the operational lesson from Ultimate Guide to NHIs — Standards is that control strength depends on visibility, lifecycle discipline, and revocation speed. OTPs can satisfy part of an assurance requirement, but they do not replace binding, assurance, or recovery governance. These controls tend to break down when legacy MFA portals, shared fallback methods, and loosely governed enrollment processes are combined in the same authentication stack.

Common Variations and Edge Cases

Tighter OTP policy often increases user friction and support overhead, requiring organisations to balance authentication strength against enrollment complexity and account recovery risk. That tradeoff becomes sharper in regulated environments, high-scale workforce access, and mixed device estates.

Best practice is evolving around phishing-resistant MFA, so OTPs are often acceptable at lower assurance levels but are no longer the preferred answer for every use case. NIST does not treat every OTP method equally: software-generated codes, SMS-delivered codes, and hardware OTP devices carry different risk profiles, and many organisations are moving toward stronger authenticators for privileged access. That shift is consistent with the broader identity risk picture described in Ultimate Guide to NHIs, where lifecycle and control gaps amplify compromise impact.

Edge cases usually arise when organisations try to stretch OTPs into scenarios they were not designed for, such as privileged admin access, high-risk remote access, or environments that require impersonation resistance. In those cases, current guidance suggests treating OTP as one control component, not the entire assurance strategy. Where recovery channels are weak, OTP also becomes a liability because account takeovers can pivot through fallback mechanisms rather than the primary factor.

Related resources from NHI Mgmt Group

• How should security teams use one-time passwords as part of multi-factor authentication without creating avoidable friction?
• Why do time-based one-time passwords reduce the risk of account compromise better than reusable login codes?
• Why do usernames, passwords, and one-time codes create weak assurance in modern authentication flows?
• Why does multi-factor authentication matter most when passwords are reused across services?