NIST SP 800-63-4
SMS and email OTP don’t cut it under NIST SP 800-63B-4: what to use instead
Many login flows still rely on a six-digit code sent by text message or email. Under the latest NIST Digital Identity Guidelines, that approach needs another look. Here is what the standard actually says, and a practical path forward.
Why this matters now
NIST SP 800-63-4, the fourth revision of the US Digital Identity Guidelines, sets the benchmark many governments, banks and identity providers use to judge how strong an authentication flow is. Its authentication volume, SP 800-63B-4, defines three Authenticator Assurance Levels (AALs):
- AAL1: basic confidence. Single-factor authentication is allowed.
- AAL2: high confidence. Two distinct factors are required, and a phishing-resistant option must be offered.
- AAL3: very high confidence. Phishing-resistant authentication with a hardware-bound, non-exportable key is required.
Most services that handle personal data aim for at least AAL2. That is where SMS and email codes run into trouble.
Email OTP: not allowed
This is the clearest point, and the most often misunderstood. SP 800-63B-4 does not treat email as a weak option. It rules it out: email SHALL NOT be used for out-of-band authentication.
An email code doesn’t prove you hold a specific device. Anyone who gets into the mailbox gets the code. Email still has a place for notifications and account alerts, but it doesn’t count as an authentication factor.
SMS OTP: restricted, not banned
SMS and voice codes sent over the phone network are the only authenticator NIST classes as restricted. That’s because of well-known attacks: SIM swapping, number porting and interception of messages.
Restricted doesn’t mean prohibited. A service can still use SMS at AAL2, but only if it does all four of the following:
- Offers an alternative that isn’t restricted, such as an authenticator app or a passkey
- Warns users about the security risks of SMS
- Covers SMS in its risk assessment
- Keeps a migration plan for the day SMS is no longer acceptable
So the real compliance gap in most legacy systems isn’t that SMS is used at all. It’s that SMS is the only option, with no alternative and no documented treatment of the risk.
Authenticator apps (TOTP): allowed, but not phishing-resistant
Time-based codes from apps such as Google Authenticator or Microsoft Authenticator aren’t restricted. Combined with a password, they meet AAL2.
They have one important limit. NIST says it plainly: “OTP authentication is not phishing-resistant.” A convincing fake login page can capture the code and replay it in real time. TOTP is a solid step up from SMS, but it isn’t the end point.
Passkeys: the phishing-resistant answer
Passkeys, built on FIDO2/WebAuthn, use public-key cryptography. The private key never leaves the user’s device or keychain, and each passkey is bound to the website’s domain. A phishing site on a look-alike domain simply can’t use it.
SP 800-63B-4 now formally covers syncable authenticators, meaning passkeys that sync across a user’s devices. They are allowed up to AAL2, and they give AAL2 services the phishing-resistant option the standard requires them to offer.
For AAL3, for example privileged administrators or high-impact systems, synced passkeys aren’t enough, because a synced key is by definition exportable. AAL3 needs device-bound authenticators, such as FIDO2 security keys or smart cards with non-exportable keys.
At a glance
| Authenticator | Status under SP 800-63B-4 | Highest AAL | Phishing-resistant |
|---|---|---|---|
| Email OTP | Prohibited for out-of-band use | None | No |
| SMS / voice OTP | Restricted (conditions apply) | AAL2 | No |
| Authenticator app (TOTP) | Allowed | AAL2 | No |
| Synced passkey | Allowed (syncable authenticator) | AAL2 | Yes |
| Device-bound security key | Allowed, non-exportable key | AAL3 | Yes |
A practical migration path
You don’t have to rip and replace everything overnight. A sensible sequence:
- Remove email OTP as a login factor. Keep email for notifications only.
- Add passkeys as the default for new and returning users, with TOTP as an alternative.
- Keep SMS only as a restricted fallback, and meet all four conditions while it remains.
- Issue device-bound keys to privileged users and anyone needing AAL3.
- Measure and improve. Track adoption, recovery requests and fraud attempts, in line with NIST’s continuous-evaluation requirement.
The bottom line
SMS and email codes were the default for a decade. Under NIST SP 800-63B-4, email is out and SMS survives only under conditions. The future is phishing-resistant: passkeys for everyday users, and device-bound keys where the stakes are highest. Making the move now improves security, simplifies the user experience, and gives you a clear, documented position when the auditors ask.
T4Trust designs and integrates digital identity solutions for governments and enterprises, from identity proofing to phishing-resistant authentication. Contact us to review your authentication flow against NIST SP 800-63-4.
References
