Password Policy Best Practices for Businesses (NIST-Aligned)

Walk into most offices in 2026 and the password policy on the intranet still reads like it was written in 2003. At least 8 characters. One uppercase, one number, one special character. Changed every 90 days.

Here's the twist: every one of those rules is now explicitly discouraged by the US standards body that made them famous. NIST's Special Publication 800-63B is the federal guideline that most auditors, frameworks and security teams trace back to. It has said since 2017 that composition rules and scheduled expiration do more harm than good - And its latest revision doubles down.

If you own the password policy at your company, this article gives you the NIST-aligned version. You'll learn what to require, what to drop, why the old rules backfire, and how to roll out the change without a compliance headache.

What NIST SP 800-63B actually says

NIST first flipped the script in 2017 with SP 800-63B. The Revision 4 update, finalized in 2025, kept the direction and strengthened it. Here are the core requirements for "memorized secrets" - That's NIST-speak for passwords - Condensed:

• Length is the primary control. Accept passwords of at least 8 characters as a floor, and NIST recommends encouraging or requiring longer. 15 characters or more is the revision's preferred minimum. Support lengths up to at least 64 characters so passphrases fit.
• No composition rules. Do not require mixtures of uppercase, lowercase, digits and symbols.
• No scheduled expiration. Do not force periodic changes. Require a change only when there is evidence of compromise.
• Blocklist screening. Check candidate passwords against lists of breached, dictionary and context-specific passwords (like the company name). Reject matches.
• Usability rules that are really security rules. Allow paste, so password managers work. Accept all printable characters, including spaces and Unicode. Don't truncate silently, and offer a "show password" option.
• No knowledge-based questions or hints. "Mother's maiden name" is not authentication.

The UK's NCSC and Microsoft's own security baseline landed in the same place. Microsoft removed the password-expiration recommendation from its Windows security baseline back in 2019. This isn't one agency's quirk - It's the consensus.

You can read the primary source at NIST's SP 800-63 digital identity guidelines - It's more readable than most standards.

Old policy vs NIST-aligned policy

Quick summary: require length, screen against breach lists, drop everything else.

Why forced rotation backfires

Mandatory 90-day changes were meant to limit how long a stolen password stays useful. In practice, they fail. Research on real user behavior - The studies NIST cites - Found that people respond to forced rotation with tiny, predictable tweaks. Falcon#7 becomes Falcon#8. March2026! becomes June2026!.

Attackers know this, and cracking tools apply those transforms automatically. An attacker who obtained one old password can often derive the current one in seconds.

Meanwhile, the policy hurts you in three more ways:

• It trains users to pick weak-but-mutable passwords in the first place.
• It floods the helpdesk with reset tickets every quarter.
• It encourages sticky notes.

You pay a real cost for negative security value. The reasoning is unpacked further in our companion piece on how often you should change your password - Short version: rotate on evidence, not on a calendar.

Rotate secrets when something happens - A breach, a departure, a phish - Not because a date arrived. Calendars don't detect compromise; monitoring does.

One honest caveat: some compliance regimes still lag. PCI DSS 4.0, for instance, retains a 90-day change requirement for certain accounts - unless you implement continuous risk-based authentication analysis. If a specific framework binds you, document the exception. Don't let one regulated system drag the whole company back to quarterly rotation.

Length beats complexity - The math and the humans

Composition rules feel rigorous but add surprisingly little. Forcing a symbol into an 8-character password nudges its search space slightly. Adding four more characters multiplies it by many orders of magnitude.

Worse, humans satisfy complexity rules in utterly predictable ways - Capital letter first, 1 or ! last. So the real entropy gained (entropy is just a measure of how hard a password is to guess) sits far below the theoretical figure.

Crack-time tables published by Hive Systems illustrate the cliff. Short complex passwords fall to modern GPU rigs in hours or less, while long passwords push into centuries.

That's why the modern policy centers on length:

Encourage employees toward machine-generated random passwords stored in a company password manager. For the few passwords they must type from memory - Device login, vault master password - Multi-word passphrases work best.

Want staff to feel the difference rather than take your word for it? Point them at a password strength checker that shows entropy and estimated crack times as they type. It runs entirely in the browser, so no real passwords leave their machine.

Blocklists: the control that replaced complexity

Dropping composition rules is safe only because blocklist screening replaces it. A blocklist is simply a list of known-bad passwords your system refuses to accept. iloveyou1 satisfies no complexity rule wisdom anyway, but it's rejected instantly by any breached-password check. At minimum, screen new passwords against:

• Known breached passwords. Have I Been Pwned's Pwned Passwords corpus is the de facto standard, and it's free. It holds hundreds of millions of real leaked passwords, queryable via a k-anonymity API that never sees the full hash.
• Top common-password lists. The same handful of strings top every breach analysis, year after year. Our roundup of the most common passwords shows how depressingly stable that list is.
• Context words: your company name, product names, the word "password," the user's own username, keyboard walks like qwerty123.

Most identity providers (Entra ID, Okta, modern IAM on Linux/AD via plugins) support this natively or via well-maintained integrations. This is usually a configuration project, not a development project.

The policy is bigger than passwords

A NIST-aligned password policy assumes passwords are one layer, not the whole defense:

• Require MFA everywhere it exists, prioritizing phishing-resistant methods (security keys, passkeys) for admins and finance. Authenticator-app TOTP is the solid middle tier. If your team wants to understand or test how those six-digit codes work, a TOTP code generator demonstrates the whole mechanism in the browser. SMS is the floor, not the goal.
• Provision a password manager for every employee. Put shared credentials (service accounts, social media, the office router) in shared vaults instead of spreadsheets. Choosing one is covered in our password manager guide.
• Don't forget infrastructure secrets. The guest Wi-Fi key taped to the reception desk is part of your password policy too. Generate a proper random WPA2/WPA3 key with a WiFi password generator and rotate it when staff with knowledge of it leave.
• Define compromise triggers. Spell out exactly what forces a reset: appearance in a breach corpus, a successful phish, malware on the endpoint, or offboarding of anyone with access to shared credentials.

A one-page policy you can adapt

1. Passwords must be at least 12 characters (15 for privileged accounts); up to 64 characters and all printable characters are supported.
2. No composition requirements. Length and unpredictability are what count.
3. New and changed passwords are screened against breached and common-password blocklists. Matches are rejected with a helpful message.
4. Passwords do not expire on a schedule. IT forces a reset on evidence of compromise or role change.
5. Every employee gets a password manager license; shared credentials live only in shared vaults.
6. MFA is mandatory on all remote-accessible and admin systems. SMS codes are permitted only where no stronger option exists.
7. Passwords are never sent over email or chat. Use the manager's sharing feature.
8. Security questions and password hints are not used anywhere.

Eight lines, defensible to any modern auditor, and - Unlike the 2003 version - Your users can actually comply without sticky notes.

FAQ

Is it really NIST-compliant to never expire passwords?

Yes. SP 800-63B states verifiers SHOULD NOT require periodic password changes. It says they SHOULD force a change when there is evidence of compromise. "Never expire on a schedule" plus "always expire on evidence" is the compliant position. Document your compromise triggers so auditors can see the second half of that sentence.

What minimum length should we set?

Twelve characters is a defensible floor for ordinary user accounts today. NIST's Revision 4 recommends 15 where practical, and 15+ is appropriate for admin and remote-access accounts. Whatever floor you choose, also raise the ceiling: support at least 64 characters so passphrases and generated passwords aren't rejected.

Do we still need complexity rules for compliance frameworks like PCI DSS?

Check the current text of each framework that binds you. PCI DSS 4.0 still contains composition and rotation language for in-scope systems, though it allows alternatives with risk analysis and continuous authentication controls. The clean pattern: a NIST-aligned policy company-wide, with documented stricter exceptions only for systems a lagging framework explicitly covers.

How do we check passwords against breach lists without sending them anywhere?

Use a k-anonymity API like Pwned Passwords. The client hashes the candidate password and sends only the first five characters of the hash. It receives all matching hash suffixes and compares them locally. The service never sees the password or even its full hash. Major identity platforms have this built in or available as a vetted plugin.

Should employees be allowed to use personal password managers for work accounts?

It's better than reuse or sticky notes, but the clean answer is to provide a company-managed tier of a mainstream manager. That gives you shared vaults, offboarding (revoke the account, credentials stay with the team), and policy enforcement. Employees keep a separate personal vault. Mixing work credentials into personal vaults makes departures messy.