Modern Password Security Strategy: From NIST 800-63B to Passkeys (2026)

Something quietly important happened in August 2025. NIST withdrew the old version of Special Publication 800-63B and published Revision 4. In doing so it put the final nail in the coffin of several practices that had been considered "security best practice" for two decades: the 90-day forced rotation, the "must have one uppercase and one symbol" rule, the 8-character minimum. All of it is now formally discouraged by the body that writes the rules.

If you manage authentication for a product, a team, or just your own accounts, this is the guide that tells you what to do now instead. We will walk through what changed at NIST, the entropy math that actually matters, how passkeys work, which MFA methods hold up in 2026, how to pick a password manager, and how the breach-check APIs let you verify password safety without trusting anyone. The goal is a working playbook, not a lecture.

What NIST 800-63B Revision 4 actually says

The National Institute of Standards and Technology publishes the reference document for federal digital authentication. Private industry largely follows it because auditors lean on it and because, honestly, it has usually been well-researched. The August 2025 revision is the first major rewrite since 2017 and it ratifies several positions that security researchers had been arguing for a decade.

The "SHALL NOT" list

These are the items where the language moved from guidance to mandate. A verifier compliant with rev 4:

• SHALL NOT impose composition complexity rules (uppercase, digit, special character requirements)
• SHALL NOT require periodic password changes unless there is evidence of compromise
• SHALL NOT use password hints or knowledge-based authentication (secret questions) as a factor
• SHALL NOT truncate passwords during verification

The "SHALL" list

• SHALL permit passwords up to 64 characters
• SHALL allow all printable ASCII and Unicode characters
• SHALL enforce a minimum of 15 characters when the password is the sole authenticator (8 characters if combined with WebAuthn or another factor)
• SHALL screen new passwords against a breach-database blocklist and periodically re-screen stored credentials
• SHALL rate-limit failed authentication attempts

The rationale is empirical. Forced rotations produced predictably worse passwords (security researchers call this the "Password1 → Password2 → Password3" pattern). Composition rules pushed users into predictable insertions (most "complex" passwords put the capital at the start and the digit at the end, reducing the effective search space). Length and breach screening — both now mandated — are what actually move the needle.

For enforcing the 15-character minimum, NIST explicitly allows generated passphrases because they tend to score well on both length and memorability. Password Generator creates passwords from 12 to 64 characters with configurable character sets, and Password Strength Checker runs the strength and entropy analysis entirely in your browser.

The entropy math that matters

Password strength is a quantifiable thing. The unit is bits of entropy, which is the base-2 log of the number of possible passwords an attacker would have to try on average to guess yours. The formula for a randomly generated password is:

E = L × log₂(R)

where:
  L = password length in characters
  R = size of the character pool
  E = entropy in bits

Some worked examples:

• 8 characters, lowercase only (R=26): 8 × log₂(26) ≈ 37.6 bits. Crackable on a laptop in minutes.
• 12 characters, mixed case + digits (R=62): 12 × log₂(62) ≈ 71.5 bits. Crackable by a well-funded attacker in days to weeks.
• 16 characters, mixed case + digits + symbols (R=94): 16 × log₂(94) ≈ 104.8 bits. Beyond practical brute force.
• 6-word Diceware passphrase (R=7776): 6 × log₂(7776) ≈ 77.5 bits. Memorable and strong.
• 20-character random from 94-char pool: 20 × log₂(94) ≈ 131.1 bits. Strong beyond any projectable threat model.

Two pitfalls in this math. First, it assumes truly random generation. If you picked the password yourself, the effective entropy is much lower because humans cluster around predictable patterns. Second, it assumes the attacker is doing a full brute force. In reality, dictionary attacks, rule-based mangling, and pattern-based attacks prune the search space. A "random-looking" password you made up is usually not actually random.

The practical upshot: use a password manager to generate passwords. The one time you might hand-craft a password — your master password that unlocks everything — use a high-entropy passphrase generated by tools like Diceware. For everything else, let the machine do it. Password Generator produces cryptographically random passwords in the browser with a single click.

Breach-check APIs and k-anonymity

Have I Been Pwned (HIBP) is the most important piece of security infrastructure that is not run by a big company. Troy Hunt's service holds about 15 billion breached credentials and exposes them through a thoughtfully designed API that lets you check a password against the breach list without ever sending the password to the server.

The mechanism is called k-anonymity. Here is how it works:

1. Compute SHA-1 of your password. Example: for "password123" you get CBFDAC6008F9CAB4083784CBD1874F76618D2A97.
2. Take the first 5 hex characters (CBFDA) and send them to the API: GET https://api.pwnedpasswords.com/range/CBFDA.
3. The API returns a text body containing every hash suffix in the database whose prefix matches, plus a count of how many times it was seen in breaches. Typically 400-600 results.
4. Scan the response locally for the suffix C6008F9CAB4083784CBD1874F76618D2A97. If you find it, the password is breached. If not, it is not in the database.

The server learns only the 5-character prefix, which is consistent with roughly 2^140 possible passwords. That is the k-anonymity: the server cannot narrow down which password you asked about beyond a set large enough to be useless. Cloudflare, which hosts the endpoint, has published detailed writeups of the protocol. It is the right model.

Here is the check in ~15 lines of JavaScript that you can drop into any browser:

async function checkPwned(password) {
  const buf = new TextEncoder().encode(password);
  const hashBuf = await crypto.subtle.digest('SHA-1', buf);
  const hash = Array.from(new Uint8Array(hashBuf))
    .map(b => b.toString(16).padStart(2, '0'))
    .join('')
    .toUpperCase();
  const prefix = hash.slice(0, 5);
  const suffix = hash.slice(5);
  const res = await fetch(`https://api.pwnedpasswords.com/range/${prefix}`);
  const body = await res.text();
  const match = body.split('\n').find(l => l.startsWith(suffix));
  return match ? parseInt(match.split(':')[1], 10) : 0;
}

If the return value is nonzero, your password has been in a breach that many times and should never be used. NIST 800-63B rev 4 mandates this kind of screening at account creation, password change, and periodically. If you are shipping an auth system, integrate it. Password Strength Checker includes a local HIBP integration that runs the check from your browser with no backend.

Passkeys and the FIDO2/WebAuthn stack

Passkeys are the post-password story. The underlying technology is FIDO2 (the alliance spec) and WebAuthn (the W3C API). The user experience is "sign in with Face ID" or "approve this login with a PIN." The cryptography is asymmetric: your device generates a keypair bound to the origin, keeps the private key locally (or syncs it end-to-end encrypted through iCloud Keychain, Google Password Manager, or a third-party manager), and proves possession of the private key by signing a challenge.

Three properties follow from the design:

1. Phishing-resistant by construction

The authentication ceremony includes the origin (the exact domain). A passkey for github.com cannot be used on g1thub.com because the signature will not validate against the wrong origin. This eliminates the single biggest class of credential attacks.

2. Useless in a server breach

The server stores only the public key. If an attacker dumps the database, they get public keys that cannot sign anything. There is nothing to crack offline. This is why adoption is accelerating: a breach of a passkey-only site does not leak credentials, it leaks public keys, which by definition are not secret.

3. Synced across devices via platform keychains

Apple syncs passkeys through iCloud Keychain, end-to-end encrypted. Google syncs through Google Password Manager. Microsoft does the same with Windows Hello. Third-party managers (1Password, Bitwarden, Proton Pass, Dashlane) now store and sync passkeys too. Credential Exchange Protocol (CXP), standardized in 2024, lets you move passkeys between ecosystems.

Adoption as of April 2026

The FIDO Alliance's March 2026 reporting shows passkey adoption has crossed critical mass:

• Over 1 billion activated passkeys globally
• 15+ billion online accounts support passkey authentication
• 48 percent of the top 100 websites offer passkeys as a login option
• ~87 percent of enterprises have deployed or are deploying passkeys
• Microsoft reports 98 percent login success for passkeys vs 32 percent for passwords
• Google reports 800 million accounts using passkeys, with 2.5 billion passkey sign-ins in the past two years

In May 2025 Microsoft made passkeys the default sign-in method for new Microsoft accounts, which alone drove 120 percent growth in passkey authentications. The tipping point is well behind us.

If you are building a new product in 2026, support passkeys from day one. Passkey Generator creates WebAuthn test credentials for development.

Password manager comparison 2026

Even with passkey adoption climbing, you still need a password manager. Most services do not support passkeys yet, legacy accounts exist, and managers also store secure notes, credit cards, and recovery keys. Here is how the leading options compare as of April 2026:

Manager	Free tier	Paid (individual)	Architecture	Passkey sync	Notable feature
Bitwarden	Unlimited passwords, unlimited devices	$10/yr	Open source, zero-knowledge	Yes, with CXP	Self-hostable server
1Password	Trial only	$47.88/yr	Zero-knowledge + Secret Key	Yes, cross-platform	Secret Key adds device-bound entropy
Proton Pass	Unlimited on one device	$1.99/mo	Zero-knowledge, Swiss jurisdiction	Yes	Built-in email aliases
iCloud Keychain / Apple Passwords	Free with Apple ID	Included	End-to-end encrypted	Yes, Apple ecosystem	Native to iOS/macOS
Google Password Manager	Free with Google account	Included	End-to-end encrypted	Yes, Android/Chrome	Works with Chrome everywhere
Dashlane	Limited to 25 passwords	$59.88/yr	Zero-knowledge	Yes	Built-in VPN

The short version:

• If you want the best free tier: Bitwarden.
• If you are deep in the Apple ecosystem and do not need cross-platform: Apple Passwords.
• If privacy is the top priority: Proton Pass (Swiss jurisdiction, built-in aliases).
• If UX polish is worth paying for: 1Password, but know the price went up 33 percent in March 2026.
• If you want to self-host: Bitwarden is the only mainstream option with official self-host support (Vaultwarden for lighter instances).

All five use AES-256 encryption with zero-knowledge architecture. None of them has had a successful vault breach to date. Whichever you pick, turn on two-factor authentication for the manager itself, store the recovery code somewhere physical (a safe, not a cloud drive), and enable emergency access or a trusted recovery contact.

MFA methods ranked

Multi-factor authentication is where most people already know they should improve but have not gotten around to it. The methods differ substantially in security. Here is the honest ranking as of 2026:

Tier S: Hardware-backed WebAuthn (passkeys and security keys)

Phishing-resistant. Cannot be intercepted. Binds to the origin. YubiKeys, Titan Keys, SoloKeys, and device-bound platform passkeys (Touch ID, Windows Hello, Android biometrics) all fall here. For high-value accounts — your email, your financial accounts, your domain registrar, your password manager — this is the only tier worth using.

Tier A: TOTP authenticator apps

Google Authenticator, Authy, Aegis, 1Password's built-in TOTP, Ente Auth. A 6-digit code that rotates every 30 seconds, derived from a shared secret. Phishable (an attacker can proxy a login page and relay the code), but resistant to SIM swap, SS7 interception, and everything short of a real-time phishing attack.

Tier B: Push-based MFA

Duo, Microsoft Authenticator push, Okta Verify. You get a notification on your phone and tap approve. Vulnerable to "MFA fatigue" attacks where an attacker sends repeated push prompts until the user approves one by mistake. Modern push implementations mitigate this with number-matching, which helps.

Tier C: SMS and email codes

SMS is vulnerable to SIM swap attacks (attacker convinces the carrier to port your number) and SS7 network interception. Email codes depend on the security of the email account, which is often the attacker's original target. Still better than no MFA. Use it only when nothing else is offered.

Tier F: Security questions, phone callbacks

NIST rev 4 flatly forbids knowledge-based authentication as a factor. Your mother's maiden name is in a public records database somewhere. Do not accept these as security.

If you want to experiment with TOTP generation for dev or test, TOTP Generator creates codes from a base32 secret in-browser.

Enterprise patterns that hold up

Enterprises sit awkwardly between the individual user and the federal compliance stack. A few patterns that work in 2026:

Kill forced rotations

Rev 4 forbids them, most CIS benchmarks have dropped them, and the empirical evidence against them is overwhelming. Replace with breach-triggered rotation: check stored credentials against HIBP monthly, rotate on hit, and rotate on suspected compromise events.

Minimum 15 characters, generous maximum

Set the floor at 15 and the ceiling at 64. Accept all printable Unicode. Do not truncate passwords in the hashing function. The old "max 20 characters" rule is a leftover from bad database schemas and should be deleted wherever you find it.

Breach-database screening at creation and change

Integrate HIBP Passwords (the k-anonymity API) or a commercial equivalent into your account flow. Reject passwords with more than a small number of breach appearances. This single control prevents credential stuffing attacks against your service.

Block session token theft, not password theft

Attackers increasingly steal session tokens via infostealer malware rather than passwords. Session theft bypasses every MFA factor the user has configured. Defenses: short session lifetimes, device binding for high-value sessions, bound authenticators that require per-request signing. Passkeys plus bound tokens is the direction.

Centralize on passkeys, SSO, and SCIM

SSO (Okta, Azure AD, Google Workspace) with passkey enforcement at the identity provider covers most of the fleet. SCIM for provisioning and deprovisioning covers lifecycle. You want to minimize the number of places that hold a long-lived password hash.

A personal hygiene playbook

Eight steps. Most take under 10 minutes each. Do them in order.

1. Pick a password manager and import. Bitwarden if you want free and open source. Apple Passwords if you are all-Apple. Proton Pass for privacy. Spend 30 minutes importing from browsers and existing spreadsheets.
2. Generate a strong master password. 6-word Diceware or 20-character random. Write it down on paper and store it physically. Do not store it in the manager that it unlocks.
3. Turn on passkeys everywhere they are offered. Google, Apple, Microsoft, GitHub, Facebook, most major SaaS. passkeys.directory has a current list.
4. Replace SMS MFA with TOTP or hardware. For your email, financial, and registrar accounts, move to hardware keys. For the rest, TOTP.
5. Audit existing passwords against HIBP. Most managers have a "breach report" feature that runs the check in bulk. Rotate anything flagged.
6. Enable account recovery with care. Security questions are banned. Use a trusted recovery contact, a physical recovery code stored offline, or a secondary email that is itself well-secured.
7. Separate your attack surfaces. Do not use your "everything" email for sensitive accounts. A dedicated address (or alias, via Proton Pass or SimpleLogin) for banking and recovery is worth the five-minute setup.
8. Review periodically. Once a year, run the breach scan, check the passkey directory for new support, and rotate the few accounts that have aged into "still using a password from 2019" territory.

For supporting tools during this migration: Password Generator for fresh credentials, Password Strength Checker for entropy analysis and HIBP lookup, Passkey Generator for WebAuthn testing, TOTP Generator for TOTP experimentation, Hash Generator for hash verification, HMAC Generator for keyed-hash operations, UUID Generator for recovery tokens and session IDs, and Bcrypt Hash Generator for storing password verifiers server-side.

Related guides

For deeper coverage of the cryptographic primitives behind passwords and sessions, see The Science Behind Password Strength and JWT Security Deep Dive. For the full security-tools walkthrough, see The Best Free Security Tools Online.

FAQ

What is the biggest change in NIST SP 800-63B Revision 4?

Composition complexity rules and forced periodic rotations are now formally prohibited. Verifiers SHALL NOT impose them. The guidance shifts to length (15-character minimum when a password is the only authenticator) and breach-database screening.

Are passkeys actually safer than passwords?

Significantly. Passkeys resist phishing by binding to the origin, cannot be leaked from a server breach (only public keys are stored), and do not require a user-chosen secret that can be weak. Microsoft data shows 98 percent login success for passkeys vs 32 percent for passwords, and over 1 billion passkeys have been activated as of early 2026.

How does Have I Been Pwned check passwords without seeing them?

You send only the first 5 hex characters of the SHA-1 hash of your password. The API returns ~400-600 matching hash suffixes. You check locally whether your full hash matches. The server cannot distinguish which of the ~2^140 possible passwords in the prefix bucket you asked about.

What is the right minimum password length in 2026?

15 characters when the password is the only authenticator (per NIST rev 4), 8 when combined with WebAuthn or equivalent. For personal accounts, 16-20 characters from a password manager is the pragmatic floor. That puts you well above the brute-force threshold for any realistic attacker.

Which MFA method is strongest?

Hardware-backed WebAuthn (security keys, platform passkeys) because it is phishing-resistant by design. TOTP apps are solid for day-to-day. Push-based is usable with number-matching. SMS is the weakest — better than nothing, but vulnerable to SIM swap and SS7 interception.

Should enterprises still force password rotations?

No. NIST rev 4 forbids it, and the empirical evidence shows forced rotations produce weaker passwords because users fall into predictable patterns. Rotate only on evidence of compromise (breach hit, suspected account takeover).

Closing thought

Password security in 2026 looks different from 2019. Composition rules are gone. Forced rotations are gone. The 8-character minimum is gone. In their place: length, breach screening, and a hard push toward passkeys. The good news is that the new rules are both more secure and less annoying for end users. Adopt them, delete the old policy documents, and spend the freed-up attention on the threats that actually matter — session theft, infostealer malware, and the long tail of legacy systems that have not caught up yet.