Change your password every three months. At least one uppercase letter, one number, one special character. Must not appear in a dictionary. And god help you if it resembles any of the last ten passwords.

We all know these rules. They were hammered into us for years — by Active Directory policies, compliance checklists, and the well-meaning security guy from IT. The problem: they're wrong. Not "maybe not optimal anymore" wrong, but "provably leads to weaker passwords" wrong.

NIST figured this out in 2017 and doubled down in 2024. BSI followed. OWASP never bought into the old rules in the first place. This article distills what the three most important authorities recommend today — and what you should change in your password policy. With the bitcalc Password Generator you can implement the recommendations right now.

The deadly sins of the old password policy

Before we get to the recommendations, a quick look back. Why was all of this wrong?

1. Complexity rules ("at least one special character")

The idea was: more character types, more possible combinations. Theoretically sound. In practice it produces Password123! — the single most popular "compliant" password in every company. Humans are not random number generators. When you force a special character, they append an exclamation mark. That doesn't increase security. It makes passwords predictable.

Real-world data A 2016 Microsoft Research study showed: complexity rules increase the Shannon entropy of the average user password by about 2 bits. Randomly increasing password length by two characters adds 13 bits. Length beats complexity — by a factor of 6.

2. Mandatory password rotation ("every 90 days")

This made sense when passwords traveled over unencrypted lines and offline brute-force took months. Today the opposite is true: forcing people to change passwords every three months makes them pick weaker passwords. Or write them on sticky notes. Or increment a number — Password123! becomes Password124!. Nobody, absolutely nobody, dreams up a completely new strong password every 90 days.

3. Password hints and "security questions"

"Favorite color?" — Blue. "First pet's name?" — It's on Instagram. "Mother's maiden name?" — Public record. Security questions are a backdoor into every account, and one that opens with OSINT research instead of computing power.

What NIST SP 800-63B requires today

The National Institute of Standards and Technology ended the old policy era with revision 800-63B in 2017 and confirmed it with the fourth update in 2024. Core requirements:

  1. Minimum length: 8 characters for user-generated passwords, 15 characters for system-generated ones (e.g. service accounts). The verifier MUST accept longer passwords, at least 64 characters.
  2. NO complexity rules. No forced upper/lower/digits/specials. The user SHOULD be allowed to use all printable ASCII characters plus Unicode.
  3. NO mandatory password rotation. Only change on suspicion of compromise.
  4. Password blacklist. The verifier MUST check the password against a list of known compromised passwords (Have I Been Pwned API, or at minimum the top 100,000).
  5. No password hints. No security questions. No knowledge-based authentication.
  6. Allow copy-paste. The verifier SHOULD permit pasting into the password field.
Entropy table: password length vs. character set vs. cracking time
Entropy in bits: 60+ bits is considered secure. An 8-character password with special characters (52 bits) is weaker than a 12-character lowercase-only password (56 bits).

BSI: the German perspective

The German Federal Office for Information Security has updated its IT-Grundschutz. BSI recommendations largely align with NIST but have their own emphasis:

  • Minimum 8 characters, with an explicit recommendation for longer passwords (12+).
  • No complexity rules. The bitcalc password generator follows exactly this logic: you set the length, everything else is optional.
  • Two-factor authentication is recommended as a supplement, not a replacement for weak passwords.
  • No forced rotation.
  • Special focus on service accounts: system passwords must be at least 24 characters and managed in a secrets manager.

OWASP: the developer's perspective

The Open Web Application Security Project delivers the most pragmatic checklist with its Application Security Verification Standard (ASVS). OWASP distinguishes three levels:

Level Min. Length Blacklist Credential Recovery
ASVS L1 (Basic)8 charsTop 10,000Rate limiting
ASVS L2 (Standard)8 charsTop 100k + HIBPMulti-factor required
ASVS L3 (High)12+ chars or MFAHIBP + custom watchlistMFA + physical token

OWASP goes further than NIST on credential recovery: even at Level 1, rate limiting is required (max 10 failed attempts per hour). At Level 2, multi-factor authentication is mandatory. At Level 3, a physical token or FIDO2 key is required.

NIST vs. BSI vs. OWASP recommendations compared
NIST, BSI, and OWASP compared directly. The core message is the same everywhere: length > complexity, no forced rotation, password blacklist.

Passkeys: the end of the password?

Passkeys (FIDO2/WebAuthn) are the elephant in the room everyone talks about but few implement. The idea: instead of a shared secret (password), use a public-key pair. The private key never leaves the device. Login happens via biometrics or PIN — locally, not on the server.

BSI has explicitly recommended passkeys since 2024. Google, Apple, and Microsoft support them. Yet they're still rare in enterprise environments — because Active Directory has no native FIDO2 support (Azure AD / Entra ID does), because legacy applications lack WebAuthn endpoints, and because rolling out to 5,000 devices isn't a weekend project.

For public web services, passkeys are the best thing to happen to authentication since OAuth. For internal environments: it depends. If your identity platform supports FIDO2, do it. If not, implement a solid password policy and supplement it with TOTP or hardware tokens. A bad password plus TOTP is still a bad password.

The bitcalc Password Generator: policy-compliant in one click

I built the Password Generator to map one-to-one to NIST recommendations:

  • Default: 20 characters, no forced character types — but you can toggle them on optionally
  • Every password is generated client-side, nothing leaves the browser
  • The entropy value updates live as you change options
  • Copy-paste is of course allowed (thank you, NIST)
Practical tip A 20-character lowercase-only password has 94 bits of entropy. That keeps even a massive GPU cluster busy for millions of years. No special characters needed. Someone who still types "P@ssw0rd!" won't be saved by any policy.

What I've rolled out in real environments

  1. Flipped the Active Directory password policy. "Passwords must meet complexity requirements" → disabled. Minimum length set to 12. Helpdesk calls for forgotten passwords dropped 40% because people can now remember passwords they came up with themselves.
  2. Integrated Have I Been Pwned at onboarding. The identity provider checks every new password against the HIBP database. That blocks "Summer2026!" and all its relatives.
  3. Password manager for everyone. The company licensed Bitwarden for every employee. Suddenly 30-character random passwords became the standard — because nobody has to remember them.

Your new password policy — the short version

If you change only three things, make it these:

  1. Set minimum length to 12 characters, drop complexity rules.
  2. Only rotate passwords on suspicion of compromise.
  3. Use a password blacklist (HIBP API, at least top 100,000).

Everything else — MFA, passkeys, hardware tokens — are addons that build on this foundation. Without this foundation, the addons aren't worth much either.