Rethinking Password Rules with NIST SP 800-63B-4

While reading about security, I came across NIST's latest digital identity guidelines, SP 800-63B-4. The password section made me think about how many applications still carry rules that nobody has revisited since the first registration form was built.

You probably know the form: add an uppercase letter, a lowercase letter, a number, and a symbol. Then come back in 90 days and do it again. I have written validation rules like these myself. Reading the guidance is a good reason to look at those choices again.

What the password guidance says

The password requirements in NIST SP 800-63B-4 set out a different approach:

Length: require at least 15 characters for passwords used alone. Passwords used only within MFA may have a minimum of eight.
Room for longer passwords: systems should support a maximum length of at least 64 characters.
Composition: do not require a mixture of uppercase, lowercase, numbers, and symbols.
Expiry: do not mandate periodic changes; require a change when there is evidence of compromise.
Screening: check new and changed passwords against a blocklist of common, expected, or compromised values, including passwords from breaches.

The distinction between requirements and recommendations matters: the 64-character maximum is a SHOULD, while the minimum lengths and prohibitions above use SHALL or SHALL NOT.

Some of this has been around for a while

The previous revision already discouraged composition rules and arbitrary rotation. Revision 4 strengthens those recommendations into prohibitions and introduces the 15-character minimum for single-factor passwords.

That history interests me. How often do we inherit a security rule, copy it into the next project, and stop asking where it came from?

For me, this is a reminder to treat password policy as an engineering decision that needs an owner and occasional review. A validation chain can look reassuring in a code review while saying very little about the rest of the authentication flow.

The work starts beyond the registration form

NIST also requires rate limiting, salted password hashing, and support for password managers and autofill. Longer passwords do not replace those controls.

My first step in an existing application would be to map every place a password enters the system: registration, resets, account settings, mobile clients, and administrative tools. I would want to know whether they share one policy or have quietly developed different ones.

Then I would try a long password through the complete flow. Can a user create it, sign in with it, and reset it? Does a mobile form impose a different limit from the API? Does the rejection message tell the user what to do next?

These are the kinds of details I would want verified before calling a policy update finished.

Legacy systems need a deliberate migration

Changing a validator is easy when you control the whole application. The discussion gets more interesting when an older directory, vendor integration, or internal policy owns part of the process.

I would start by documenting each constraint and identifying who can change it. That gives the team a concrete migration conversation: which restrictions belong to our code, which come from an upstream service, and which are written policy that needs review?

I would also keep acceptance of new passwords separate from the handling of existing accounts. Before a rollout, the team needs a clear decision about how current users move to the revised policy, what happens during recovery, and how support will explain the change.

This leaves me with a practical question: MFA/2FA setup usually happens after registration, once the account and its password already exist. Can we accept an eight-character minimum at registration and then require users to activate MFA/2FA, or should we require 15 characters upfront and recommend enabling MFA/2FA afterward? How is your team handling this chicken-and-egg situation?

Source: NIST SP 800-63B-4 — Passwords.