Field guideNo. 04
Preparing for NIST SP 800-63-4: a working plan for banks and agencies
Revision 4 of NIST’s Digital Identity Guidelines doesn’t ban SMS codes, but it puts conditions on keeping them. How to map your authenticators, document the restricted ones and show an examiner a plan.
The short answer
What do organizations need to do to prepare for NIST SP 800-63-4?
Map every authenticator you use to NIST’s assurance levels, identify the restricted ones (SMS and voice codes), and for each restricted authenticator document a risk assessment, user notice, a non-restricted alternative and a migration plan. Add a phishing-resistant option such as passkeys, which Revision 4 accepts at AAL2.
If you read nothing else
- Revision 4 has three volumes: identity proofing (63A), authentication (63B) and federation (63C).
- SMS and voice codes stay allowed as “restricted” authenticators, with four conditions.
- Synced passkeys are accepted at AAL2; hardware security keys remain the AAL3 option.
- Federal agencies must follow it; for banks it is a benchmark examiners and auditors use.
What Revision 4 is, and who it binds
NIST’s Digital Identity Guidelines are the reference US federal agencies must follow. Revision 4, finalized in 2025, is split into three volumes: identity proofing (63A), authentication (63B) and federation (63C).[1] Banks aren’t directly bound, but examiners and auditors reach for it when they assess authentication, and the FFIEC’s own 2021 guidance is written in terms of risk rather than named methods, which leaves NIST as the most specific benchmark available.[4]
For authentication, two changes matter most. SMS and voice codes stay allowed as “restricted” authenticators, and synced passkeys are accepted as a phishing-resistant option at AAL2.[2][3]
Step 1 Map every authenticator to an assurance level
| Method | Phishing-resistant? | NIST 800-63B-4 |
|---|---|---|
| SMS or voice OTP | No | Restricted |
| Authenticator app code (TOTP) | No | Allowed at AAL2 |
| Synced passkey | Yes | Allowed at AAL2 |
| Hardware security key (FIDO2) | Yes | Eligible for AAL3 |
| Carrier / SIM-based verification | [EDITORIAL: confirm] | [EDITORIAL: confirm classification] |
List every sign-in, step-up and recovery flow, the authenticators each accepts, and the assurance level you intend it to meet. Restricted doesn’t mean banned. It means you have to show your working.
Step 2 Flag every restricted authenticator
Mark each flow that accepts SMS or voice codes, including fallbacks and recovery paths that are easy to miss. A flow that offers passkeys first but falls back to a text message still relies on a restricted authenticator.
Step 3 Meet the four conditions, with evidence
For each restricted authenticator you keep, Revision 4 expects four things.[2] The evidence column is Tradecraft’s suggestion of what to keep on file.
| Obligation | Evidence to keep | Owner |
|---|---|---|
| Offer a non-restricted alternative | List of alternatives per flow, with availability by platform | IAM engineering |
| Tell users the risks | The customer-facing wording and where it appears | Product and legal |
| Assess the risk | A dated, signed risk assessment per flow | Compliance and risk |
| Keep a migration plan | A plan with owners and milestones, reviewed on a schedule | CISO |
Step 4 Add a phishing-resistant option
Synced passkeys are the practical choice for most customers at AAL2; hardware security keys remain the option for AAL3 use cases, such as administrators.[2][3] Our passkey rollout field guide covers enrollment and recovery.
Step 5 Check recovery and federation paths
Account recovery is often where a restricted authenticator survives unnoticed. If you federate identity to partners or across business units, review those flows against volume 63C as well.[1] [EDITORIAL: add 63A and 63C specifics after legal review]
Step 6 Package it for examiners and auditors
Keep one document that ties it together: the authenticator map, the list of restricted authenticators, the evidence for each of the four conditions, and the migration plan with dates. Date it, name an owner, and review it when your flows or the guidelines change.
Who owns this
| Activity | Compliance | CISO | IAM eng. | Product | Legal | Internal audit |
|---|---|---|---|---|---|---|
| Authenticator map | C | A | R | C | I | I |
| Restricted-authenticator risk assessments | R | A | C | C | C | I |
| User risk notices | C | I | I | R | A | I |
| Migration plan | C | A | R | R | I | I |
| Examiner package | A/R | C | C | I | C | C |
Questions readers ask
Does NIST 800-63-4 ban SMS OTP?
No. It classifies SMS and voice codes as restricted: allowed, with conditions.
Do US banks have to follow NIST 800-63?
Not directly. The guidelines are written for federal agencies, but examiners and auditors often use them as the benchmark.
What counts as phishing-resistant under Revision 4?
Authenticators that are cryptographically bound to the real site or service, such as FIDO2 passkeys and hardware security keys. SMS codes and authenticator-app codes are not phishing-resistant.
Sources
- NIST NIST SP 800-63-4: Digital Identity Guidelines
- NIST SP 800-63B-4: Authentication and Authenticator Management
- FIDO Alliance NIST cites phishing resistance of synced passkeys in digital identity guidelines update
- FFIEC Authentication and Access to Financial Institution Services and Systems (2021-08-11)
Changelog
- : First edition, assembled from Tradecraft’s sourced explainers. Awaiting editorial verification.
Cite this
Tradecraft. “Preparing for NIST SP 800-63-4: a working plan for banks and agencies.” Tradecraft, September 24, 2026. https://glide-tradecraft.pages.dev/field-guides/preparing-for-nist-800-63-4/
Read next
Explainer
SMS one-time passcodes are “restricted” under NIST’s new guidelines. Here’s what that means for US banks
NIST SP 800-63-4 does not ban SMS one-time passcodes. It classifies SMS and voice codes as “restricted” authenticators: still allowed, but only if the organization assesses the risk, tells users about it, offers at least one non-restricted alternative, and keeps a plan to migrate away.
Field guide
Moving a bank off SMS OTP: the field guide
Inventory every flow that sends a code, write the risk assessment NIST SP 800-63B-4 asks for, fix account recovery and new-payee setup first, then move customers to phishing-resistant or device-bound methods such as passkeys and in-app approval. Keep SMS only as a restricted fallback, with a dated plan to remove it.
Buyer’s guide
Phishing-resistant MFA: a buyer’s guide
Phishing-resistant MFA is authentication that a fake site or man-in-the-middle can’t capture and replay, because the credential is cryptographically bound to the real site. FIDO2 passkeys and hardware security keys are the common examples, and CISA also counts PKI-based smart cards. SMS codes, authenticator-app codes and simple push approvals are not phishing-resistant.
Take the checklist
Checklist
NIST 800-63B-4 restricted-authenticator file
The four conditions for keeping SMS or voice codes, and the evidence to keep for each.