One-time passwords live or die by NIST SP 800-63B verifier rules — rate-limiting, replay resistance, no email OTP, restricted SMS. What the standard requires in 2026, and when to move past OTP.
One-time passwords live or die by NIST SP 800-63B verifier rules — rate-limiting, replay resistance, no email OTP, restricted SMS. What the standard requires in 2026, and when to move past OTP.
NIST Special Publication 800-63B does not ban one-time passwords — it tells you precisely how to run them safely. The verifier requirements that harden OTP are concrete: rate-limit and throttle failed authentication attempts (the guidance caps online guessing at no more than 100 consecutive failures), enforce replay resistance so a code works exactly once, never deliver the out-of-band secret over email or VoIP, and treat SMS as a "restricted" channel that needs a documented risk assessment and a migration plan. Get those four controls right and OTP is a legitimate second factor. Get them wrong and a six-digit code becomes a brute-force target. This piece is the practitioner's reading of what the standard actually asks for.
This is the 2026 update of an earlier Avatier post, The New Arms Race: How One-Time Passwords Are Being Weaponized. The original framed OTP as a triumphant counter-weapon against attackers and leaned on a handful of vendor-attributed effectiveness statistics that have not aged well. We have stripped those numbers and rebuilt the piece around the one thing that has held up: the public NIST specification. The threat landscape moved — adversary-in-the-middle phishing became commodity tooling, SIM-swap fraud industrialized, and the standard itself was revised — so the honest 2026 answer is less "OTP defeats hackers" and more "here is exactly how far OTP can carry you, and where the standard tells you to stop."
NIST SP 800-63B does not treat "OTP" as one thing. It classifies authenticators by the factors they prove and the way the secret is exchanged, and one-time passwords appear in several of those buckets. A single-factor OTP device — a hardware fob or a plain authenticator app that generates a code — is a "something you have" authenticator on its own. A multi-factor OTP device additionally requires a PIN or biometric to unlock the code, folding a second factor into the same token. An out-of-band device delivers or confirms a secret over a separate channel to a registered phone; SMS and push both live here. And look-up secrets — printed backup codes — are a close cousin used mostly for recovery.
The distinction matters because assurance follows the classification, not the marketing. A single-factor OTP device generally supports AAL1. Combine an OTP with a memorized secret, or use a multi-factor OTP device, and you can support AAL2 provided the verifier does its job. What no OTP configuration reaches is AAL3, and the reason is structural rather than a matter of key length or code freshness: AAL3 demands a hardware authenticator that is also verifier-impersonation-resistant, and OTP — where a human reads a code and retypes it — has no way to bind the exchange to the real relying party. That single property is the ceiling on the entire category.
This is where accuracy earns its keep. It is correct to say "800-63B lets a multi-factor OTP device support AAL2." It is wrong to say any product "is AAL2" or "is AAL3" — assurance levels describe an authentication ceremony as deployed and assessed, not a vendor. Our organizational OTP guide walks through how the hierarchy maps onto real enrollment and lifecycle decisions; this piece stays on the verifier side of the ledger.
The security of an OTP deployment is decided less by the token than by the verifier — the server that checks the code. NIST SP 800-63B places most of its OTP obligations there, and four of them do the heavy lifting. Read them as a checklist you can hold a deployment against.
The four verifier controls that make a short numeric code defensible. Three of them harden OTP against guessing and interception; the fourth puts SMS on a deprecation clock.
Rate-limiting and throttling failed attempts. A six-digit OTP has a million possible values and a lifetime measured in seconds to minutes. Without a limit on failed guesses, an attacker who can submit attempts quickly enough will land a valid code inside its window. NIST addresses this directly by requiring verifiers to throttle consecutive failures, with a commonly cited ceiling of no more than 100 failed attempts on an account before further attempts are blocked or delayed. You satisfy it with progressive backoff, temporary lockout, CAPTCHA, or source-based limits — but you must count failures in a way an attacker cannot cheaply reset, and ideally per source as well as per account to resist distributed guessing.
Replay resistance. An OTP is single-use by definition, and the verifier must enforce that: a code that has been accepted, or observed in transit, cannot be presented a second time. In practice this means invalidating a code the instant it is consumed and refusing any code outside its time or counter window. Replay resistance is what keeps a briefly intercepted code from becoming a durable credential.
No OTP over email. The standard does not accept email as an out-of-band channel. Out-of-band authentication has to prove possession of a specific device, and an inbox is an account reachable from anywhere — often from the same place the password already is. Emailing a code usually collapses the second factor back into "something you know."
SMS as a restricted channel. SMS delivery is permitted but flagged, which the next section covers in full.
Two of those requirements deserve a closer look because teams get them subtly wrong. Replay resistance sounds automatic — codes expire, after all — but the failure mode is a verifier that accepts a code anywhere inside a generous validity window without marking it consumed. If a TOTP is valid for a 90-second skew window and the verifier does not burn it on first use, an attacker who captures it has the remainder of that window to replay it against a second session. The correct behavior is single-consumption: the moment a code authenticates, it is dead, even if the clock says it should still be valid. This is cheap to implement and routinely skipped.
The email rule trips people up for a different reason: it feels convenient and safe, and it is neither. Sending a login code to a user's inbox seems like a reasonable out-of-band step, but the inbox is precisely the asset attackers pivot through. If the mailbox is protected by a password and — worse — an SMS OTP, then a single SIM swap unlocks both the mailbox and any code you send to it, a circular dependency the standard's channel rules are designed to prevent. Email-delivered codes and magic links have a place in low-impact consumer authentication, but they do not satisfy 800-63B's out-of-band requirement, and they should never gate workforce or privileged access. Our breakdown of the pros and cons of OTP covers where these channels still earn their keep and where they quietly become liabilities.
SMS OTP occupies a specific, and specifically awkward, status in NIST SP 800-63B: it is a RESTRICTED authenticator. That label is not a ban and not an endorsement — it is a formal recognition that the channel has known weaknesses the standard expects you to manage deliberately rather than ignore. The weaknesses are well documented: SIM-swap fraud, in which an attacker convinces or bribes a carrier to move a victim's number to a new SIM; SS7 signaling attacks that let a suitably positioned adversary intercept messages; and plain carrier-side social engineering. None of these require breaking any cryptography. They break the assumption that a phone number reliably maps to one person's device.
Because SMS is restricted, the standard attaches conditions to keeping it. An organization that continues to rely on SMS OTP is expected to conduct and record a risk assessment, present users with a meaningful notice that the method carries elevated risk, offer at least one non-restricted alternative, and maintain a roadmap for migrating away as those alternatives mature. That is a materially different posture from "SMS is fine." It is closer to "SMS is on a deprecation clock, and you are accountable for the clock."
The practical read for 2026 is unchanged from what mature security teams already do: SMS OTP is a defensible fallback and recovery channel, useful when a stronger factor is temporarily unavailable, and it is not a defensible primary factor for anyone whose compromise is expensive. If your only second factor for administrators is a text message, the standard is telling you, in its own careful language, to have a plan for replacing it.
Here is the uncomfortable part that the verifier requirements cannot fix. Rate-limiting, replay resistance, and channel restrictions are excellent defenses against a specific class of attack: guessing and interception. They do almost nothing against the class that actually dominates 2024–2026 incidents: real-time relay. Understanding which control stops which attack is the whole game.
Match the control to the attack. Rate-limiting and replay resistance defeat guessing and reuse; they are silent against a proxy that relays a valid code in real time.
Real-time phishing / adversary-in-the-middle (AiTM). A proxy such as Evilginx presents a pixel-perfect login page, forwards the victim's password and OTP to the real service the instant they are entered, and captures the resulting session cookie. Every verifier rule is satisfied — the code was fresh, used once, and correctly rate-limited — and the attacker still holds the session. This is the structural weakness of OTP, and no amount of throttling touches it.
SIM swap. The attacker moves the phone number, receives the SMS code directly, and never needs to phish the user at all. This is exactly why the standard restricts SMS; the mitigation is to take the phone number off the authentication path.
OTP interception. SS7 attacks against carrier signaling and malware on the endpoint can read codes in transit or as they are typed. Replay resistance limits the value of a single intercepted code, but a device-bound, replay-resistant authenticator removes the readable secret entirely.
Endpoint malware and infostealers. Modern infostealers lift live session tokens straight out of the browser, sidestepping authentication altogether. The answer is phishing-resistant MFA combined with tighter session binding, not a stronger code. We trace these patterns through concrete incidents in our OTP failure case scenarios and the mechanics of coercion in MFA fatigue attacks and defense patterns.
If the threat model tells you why OTP has a ceiling, the strength ladder tells you where to go. The useful way to think about authenticators is as a monotonic climb: each rung closes an attack the rung below it left open, and the top rung closes the one that OTP structurally cannot.
The climb from a typed code to an origin-bound credential. Every rung below FIDO2 shares one weakness — the secret is transmitted and therefore relayable.
The bottom two rungs — SMS and email OTP — are phishable and, per the standard, either restricted or disallowed as out-of-band. TOTP from an authenticator app is a genuine improvement: the code is replay-resistant and generated offline, so there is no SMS channel to hijack. But it is still a code the user types, which keeps it phishable via AiTM. Push with number-matching closes the MFA-fatigue attack by forcing the user to transcribe a server-shown number rather than tap "approve," yet it still does not bind the ceremony to the real origin, so a determined proxy can walk a confused user through it. Only the top rung — FIDO2/WebAuthn passkeys and hardware keys — is phishing-resistant by design, because the credential is cryptographically bound to the relying party's origin and simply cannot be replayed to a look-alike domain.
The decision rule that falls out of the ladder is not "rip out OTP." It is match the rung to the blast radius. For low-impact consumer accounts, a recovery channel behind a stronger primary factor, or a transitional state during a passkey rollout, OTP configured to the verifier requirements is a reasonable place to stand. For workforce single sign-on, administrators, executives, and any account that reaches a regulated control plane, the standard's own logic points past OTP to the phishing-resistant tier. Our reference on phishing-resistant MFA for enterprise lays out the qualifying methods and the deployment architecture across a mixed workforce.
Avatier's role in this is to make the standard-compliant path the easy one. On the OTP side, Identity Anywhere implements the verifier controls the standard asks for — throttling and lockout on failed attempts, single-consumption codes for replay resistance, and out-of-band delivery to registered devices rather than email. Password Station handles self-service password reset and account recovery with workflow-verified identity checks, which closes the social-engineering gap in recovery flows that no amount of code hygiene addresses on its own.
On the other end of the ladder, the platform is FIDO2-compatible across the full ceremony — origin binding, cryptographic challenge-response, and no shared-secret transmission — so the same system that runs your OTP fallback can carry passkeys, hardware security keys, and, for workforce segments where personal devices do not fit, the deviceless Avatier Identity Challenge Card. That matters because the realistic 2026 architecture is not "OTP or FIDO2" — it is both, with OTP fenced to fallback and low-impact use while phishing-resistant factors carry the accounts that matter.
To keep the compliance framing honest: the Avatier Trust Center publishes the current posture — SOC 2 Type II with zero exceptions, ISO/IEC 27001:2022 certified, PCI DSS v4.0.1 compliant, CSA STAR Level 1, NIST 800-53 Rev. 5 aligned, FedRAMP-aligned, and a signatory to the CISA Secure-by-Design Pledge. Note what that list does and does not claim. It describes Avatier's organizational and product security posture. It does not assert an authenticator assurance level for any specific deployment, because AAL is a property of an authentication ceremony as configured and assessed in your environment — a distinction we hold to deliberately, and one that the governance-failure analysis on our CGov blog, the Storm-2949 breakdown, shows the cost of blurring.
Here is the residual weakness stated plainly. You can implement every verifier requirement in NIST SP 800-63B — throttle failed attempts to the letter, burn each code on first use, refuse email delivery, put SMS on a documented migration plan — and OTP will still be phishable. A perfectly rate-limited, perfectly replay-resistant one-time password relayed through an adversary-in-the-middle proxy authenticates the attacker just as cleanly as it authenticates the user. The verifier requirements are real security value against guessing, reuse, and interception. They are not, and were never meant to be, a defense against real-time relay.
That is the reason the standard reserves its highest assurance level for verifier-impersonation-resistant methods and leaves OTP below the line. It is not a knock on OTP; it is an accurate statement of what a typed code can and cannot do. So the 2026 posture is a two-handed one: configure OTP correctly everywhere you keep it, and move past OTP everywhere the blast radius is high. Hold OTP to the verifier requirements so it is the best version of a phishable factor. Then deploy phishing-resistant credentials for the accounts where "phishable, but well-configured" is not good enough — which, for most enterprises, is more accounts than they think.
NIST SP 800-63B requires verifiers to rate-limit — throttle — consecutive failed authentication attempts against an OTP authenticator. The widely cited ceiling is no more than 100 consecutive failed attempts on a single account before the verifier blocks or delays further tries. Because a typical OTP is only six to eight digits, an unthrottled verifier is guessable by brute force; throttling is what makes the short code defensible. The standard lets you satisfy the requirement with progressive delays, temporary lockouts, CAPTCHA, or IP- and device-based limits. Rate-limiting is a verifier control, not an authenticator property — you configure it on the system that checks the code, not on the token that generates it.
Four verifier requirements do most of the work. First, rate-limit and throttle failed attempts so a short numeric code cannot be brute-forced online. Second, enforce replay resistance so each OTP is accepted exactly once and an observed code cannot be reused. Third, never deliver the out-of-band secret over email or VoIP — those are not valid out-of-band channels because they do not prove possession of a specific device. Fourth, treat SMS/PSTN delivery as a "restricted" authenticator, allowed only with a risk assessment, a migration plan, and user notice. Above these sits verifier impersonation resistance, which OTP does not provide and which is why OTP alone cannot reach the highest assurance level.
No. NIST SP 800-63B does not permit email as an out-of-band authentication channel. The out-of-band requirement is that the channel proves possession and control of a specific physical device — a registered phone receiving a push or, in restricted form, an SMS. Email fails that test: an inbox is an account, not a device, and it is frequently reachable from anywhere the user's password already is. Delivering a one-time code by email typically collapses your second factor back into "something you know," inheriting whatever weakness protects the mailbox. If the mailbox is itself protected only by a password and SMS OTP, an email OTP adds almost no independent assurance. Use a genuine out-of-band device or an authenticator app instead.
SMS OTP is permitted but classified as a "RESTRICTED" authenticator under NIST SP 800-63B. Restricted means the standard recognizes real weaknesses — SIM-swap fraud, SS7 protocol attacks, and carrier social engineering — and allows continued use only under conditions. Organizations relying on SMS must conduct and document a risk assessment, present users with a meaningful notice of the risk, offer at least one non-restricted alternative, and maintain a roadmap for migrating off SMS as those alternatives mature. In practice that makes SMS OTP a defensible fallback or recovery channel, not a default primary factor for workforce or privileged access. Treat it as a control on a deprecation clock, not a permanent design choice.
OTP throttling is the verifier-side mechanism that limits how many failed one-time-password attempts an attacker can make before the system slows down or stops accepting guesses. Because an OTP is a short numeric secret, an attacker who can submit unlimited guesses will eventually hit a valid code within its lifetime. Throttling defeats that by capping consecutive failures — NIST's reference point is no more than 100 — and then applying exponential backoff, temporary account lockout, or step-up challenges. Effective throttling counts failures per account and, ideally, per source to resist distributed guessing, and it must not be trivially reset by the attacker. It is the single control that turns a guessable short code into a practical second factor.
Some OTP configurations meet AAL2; none reach AAL3. Under NIST SP 800-63B, a single-factor OTP device generally supports AAL1, and a multi-factor OTP device — or an OTP combined with a memorized secret — can support AAL2 when the verifier requirements are met. AAL3 is different: it requires a hardware-based authenticator that is also verifier-impersonation-resistant, meaning the authentication is cryptographically bound to the relying party so a phishing proxy cannot relay it. OTP, where the user reads a code and types it somewhere, provides no such binding, so it cannot satisfy AAL3 no matter how it is delivered. Reaching AAL3 means FIDO2/WebAuthn or PIV, not a better OTP.
No. In NIST's vocabulary, phishing resistance is called verifier impersonation resistance, and OTP does not have it. Every OTP variant where the user reads a code and enters it elsewhere — SMS, email, TOTP, hardware token — can be captured on a fake login page and replayed to the real service in real time by an adversary-in-the-middle proxy. The code is valid, the user typed it correctly, and the attacker still walks away with the session. Rate-limiting, replay resistance, and channel restrictions harden OTP against guessing and interception, but none of them bind the ceremony to the real site. Only FIDO2/WebAuthn and smart-card credentials meet the verifier-impersonation-resistance bar the standard sets for phishing resistance.
Move past OTP for any account where a stolen session is expensive: workforce single sign-on, privileged and administrator accounts, and anything touching a regulated control plane. Those are exactly the targets adversary-in-the-middle phishing and SIM swap go after, and they are the targets OTP's verifier rules cannot protect. Keep OTP where it still earns its place — as a fallback or recovery channel behind a phishing-resistant primary factor, for low-impact consumer accounts, and as a transitional factor during a passkey rollout. The practical rule is to configure OTP to the 800-63B verifier requirements everywhere you keep it, and to deploy FIDO2 or passkeys everywhere the blast radius of a phished session is high.
NIST SP 800-63B is not an argument against one-time passwords — it is the clearest available specification for running them responsibly. Rate-limit and throttle failed attempts, enforce single-use replay resistance, refuse OTP over email, and treat SMS as the restricted channel it is, and you have the best version of a phishable factor. What the standard will not let you pretend is that a well-configured OTP is phishing-resistant, because a typed code relayed in real time defeats every verifier control at once. Configure OTP to the requirements everywhere you keep it, move workforce and privileged access to FIDO2 and passkeys everywhere you can, and let the blast radius — not habit — decide which accounts sit on which rung of the ladder.
How to assess your own enterprise MFA implementation in 2026 — a scored self-assessment across coverage, factor strength, gaps, user experience, and recovery on a five-level maturity ladder.
Single-factor authentication still runs most login events on earth, and most of the advice about it is a strawman. The 2026 reference on what SFA actually is, where it remains defensible, why factor independence decides whether you really have MFA, and the failure ladder from password-only to phishing-resistant FIDO2.
Enterprise passwordless implementation runs on a specific eight-step deployment sequence — workforce inventory, credential-class selection per segment, IdP configuration, pilot enrollment, workforce rollout with change management, help desk pre-scaling, monitoring and iteration, and passwordless-fallback residual planning. The 2026 enterprise reference on the step-by-step deployment playbook, the go/no-go criteria at each phase gate, and the discipline that produces successful passwordless rollout at workforce scale.
Recognized on Gartner Peer Insights
Based on 14 verified reviews of AvatierIdentity Governance and Administration
Read the reviews on Gartner Peer Insights