Security questions are dead: What NIST 800-63B-4 allows instead

Security questions are knowledge-based authentication (KBA): your product stores a user's answer to a personal question and later accepts that answer as proof of identity. NIST no longer recognizes KBA as an acceptable authenticator, and it isn't one of the four account recovery methods SP 800-63B-4 recognizes. A recovery flow that still asks for a mother's maiden name relies on a control the standard has dropped.

Why do security questions fail?

NIST's position, from its SP 800-63 FAQ, is blunt:

The reasons NIST gives are how easily an attacker can discover the answers to many of these questions, and how few possible answers many of them have. Earlier editions did allow the pattern, under the name "pre-registered knowledge token" in SP 800-63-2. It was removed rather than tightened.

The data behind that decision is public. In "Secrets, Lies, and Account Recovery" (WWW 2015), Bonneau, Bursztein, Caron, Jackson and Williamson studied personal knowledge questions across a large set of real recovery attempts at Google. Secret questions offered a security level far lower than user-chosen passwords. Users made it worse in a way that looks like caution: 37% of those who admitted to giving fake answers said they did it to make the answers harder to guess, and in aggregate that had the opposite effect.

Usability fails too. About 40% of the English-speaking US users in the study couldn't recall their answers when they needed them, while SMS reset codes succeeded more than 80% of the time. The questions with the most potential security, such as "What is your first phone number?", were the ones people remembered worst. The authors concluded that it appears next to impossible to find secret questions that are both secure and memorable.

Two related rules belong in code review. SP 800-63B-4 says verifiers shall not prompt subscribers to use KBA or security questions when choosing passwords, with "What was the name of your first pet?" as its example. The same section bans storing a password hint that an unauthenticated claimant can read. Both rules have the same reason: a secret someone else can look up isn't a secret.

For users who still meet these prompts on other sites, NIST's FAQ suggests letting a password manager generate random text as the answer. The recommended way to use the field is to fill it with noise.

What does NIST 800-63B-4 allow instead?

The standard first narrows what account recovery means. In SP 800-63B-4, account recovery is when a subscriber has lost control of the authenticators needed to authenticate at a desired assurance level. Replacing a forgotten password while the user can still sign in with another authenticator isn't recovery in this model; it counts as binding a new authenticator. That distinction matters, because the requirements below apply to the first case, not the second.

For real recovery, NIST recognizes four classes of method:

• Saved recovery codes, issued at enrollment and stored by the user. Each code includes at least 64 bits from an approved random bit generator, is stored in the account hashed with an approved one-way function, and is invalidated after use, when a new one is issued.
• Issued recovery codes, sent on demand to a recovery address the user registered: email, text, voice or postal mail. Each code includes at least six decimal digits (or equivalent) from an approved random bit generator.
• Recovery contacts: trusted people the user nominates, whose addresses receive the issued recovery code to pass along. The code's validity may be extended by 24 hours to give them time.
• Repeated identity proofing, for accounts proofed at IAL1 or above: repeating part of the original proofing process.

Saved codes are the cheapest to build, and the requirements describe the implementation almost line by line:

  
import { randomBytes } from 'node:crypto';

// 128 bits, comfortably above the 64-bit floor for a saved recovery code
const code = randomBytes(16).toString('base64url');

await db.recoveryCodes.insert({
  userId,
  // store only the hash, using an approved one-way function
  codeHash: await hashSecret(code),
  createdAt: new Date(),
});

// show `code` to the user exactly once, then never again
  

Providers must support at least one of the four. An application-specific method is allowed, but NIST requires it to be based on a risk analysis and documented by the provider. Read that sentence twice if you hoped to keep security questions as a fallback: the bar is a written risk analysis, not a decision made in sprint planning.

How strong does recovery have to be?

The requirements scale with the account. For an account that was never identity-proofed, recovery uses a saved recovery code, an issued recovery code or a recovery contact. For an account that can authenticate at AAL2, NIST requires one of three combinations:

Offer more than one method, because the last resort is unpleasant. A user with no saved code, no verified address and no recovery contact is left with repeated identity proofing, and only if the account was proofed in the first place. NIST says recovery is expected to be rare and may involve extended waiting times. That's tolerable for a path a user walks once, and not as the only path.

Which details do teams get wrong?

A new recovery address doesn't count until it's confirmed. When a user adds a recovery address that wasn't validated during identity proofing, the provider sends a confirmation code with the same characteristics as a recovery code, and the address becomes usable only after the user enters it. Providers also have to let users register at least two recovery addresses. A product that writes a freshly typed phone number straight into its recovery table has built an account takeover path, not a safety net.

Issued codes expire. The ceilings are specific:

Every recovery event notifies the user. Account recovery always sends one or more notifications to the subscriber, accounts support at least two notification addresses, and each notification carries clear instructions, including contact information, for when the recipient didn't request it. If the only other notification address is the one the recovery code went to, the notification also goes to a postal address. Binding a new authenticator triggers its own notification, through a channel independent of the transaction that bound it.

Code entry is rate limited. Verifying saved and issued recovery codes is subject to the same throttling requirements as other authenticators. Six digits with unlimited attempts is an open door.

Email is allowed here. SP 800-63B-4 prohibits email as an out-of-band authentication channel, then says explicitly that confirmation codes used to validate email addresses, or issued as recovery codes, aren't authentication and aren't covered by that prohibition.

How do you migrate off security questions?

1. Stop collecting new answers. Remove the fields from sign-up and account settings. NIST's FAQ says answering knowledge-based questions for password reset is KBA, isn't allowed, and leaves the account vulnerable to takeover.
2. Give users a second way in before you remove the old one. NIST tells providers to encourage subscribers to keep at least two separate means of authentication, so recovery is needed less often. Offer saved recovery codes at enrollment and prompt existing users to add a second authenticator at sign-in. Binding it requires authentication at the maximum AAL available on the account or the AAL the new authenticator will be used at, whichever is lower. Our MFA best practices post covers the factor options in more depth.
3. Verify the addresses you're about to depend on. Run the confirmation-code flow on recovery addresses already in your database before you route recovery through them.
4. Delete the stored answers. Hashed or not, those rows are a liability with no remaining purpose, and they're the kind of data that makes a breach worse for every other site where the user gave the same answer.
5. Add notifications and throttling, then treat the recovery path with the same care as sign-in. Best practices for secure user authentication applies here in full.

Which recovery method should you offer?

For most SaaS products, the first two are the sensible default, with repeated proofing reserved for high-value accounts. The AAL2 pairing rule is the reason to ship more than one: two codes from different methods, or one code plus a surviving single-factor authenticator.

Security questions lasted this long because they were cheap to build and let teams claim a recovery story without owning one. What replaces them isn't more expensive, only more explicit: random codes, verified addresses, expiry windows and a notification on every event. All four recognized methods assume someone will eventually try the recovery door instead of the front one. Security questions assumed no one would.