An up-to-date password policy asks for length instead of complexity: a minimum of 15 characters where the password is the only factor, at least 64 accepted, no mandatory composition rules, no periodic expiry — a forced change only on evidence of compromise — and screening against lists of already-breached passwords. That is revision 4 of NIST SP 800-63B, published in 2025. And above all of it: multi-factor authentication.
The three rules to delete from your policy
Most policies in circulation inherit recommendations from the early 2000s that later evidence dismantled. These three do the most harm, and all three are now expressly ruled out in NIST SP 800-63B-4:
The guidance is blunt: verifiers shall not require periodic changes, and shall force a change only where there is evidence of compromise. The reason is not cryptographic, it is behavioural: anyone forced to change every few months produces predictable variations of the previous one — the month, the year, a digit at the end — writes it down, or reuses the same pattern everywhere. The net balance makes security worse.
Verifiers shall not impose composition rules. All they achieve is forcing predictable transformations — a capital at the start, a "1" and an exclamation mark at the end — that add very little real entropy and a lot of friction. A long phrase of ordinary words is stronger and easier to remember than "P4ssw0rd!" and satisfies any sensible rule.
No more "the name of your first pet": the guidance expressly prohibits verifiers from prompting for knowledge-based authentication. The answers tend to be public information, are repeated across services and can be guessed from social media. Nor is it acceptable to store a password hint that an unauthenticated claimant can reach.
If your corporate directory still enforces mandatory expiry, removing it is one of the few security decisions that improves protection and people's lives at the same time. With one caveat: removing it without adding breach screening and multi-factor authentication would be swapping a bad practice for a gap.
What the reference guidance actually asks for in 2026
NIST published revision 4 of SP 800-63B in July 2025. It is the technical reference almost everyone ends up citing when the "how" that European law leaves open has to be made concrete. Here is what matters for drafting a policy, with the force of each statement:
| Requirement | What it says | Force |
|---|---|---|
| Minimum length | 15 characters if the password is the only factor; 8 if it is part of a multi-factor scheme | SHALL |
| Maximum length | Permit at least 64 characters | SHOULD |
| Composition rules | Do not impose them | SHALL NOT |
| Periodic expiry | Do not require it; force a change only on evidence of compromise | SHALL NOT |
| Blocklist screening | Compare the chosen password against a list of common, expected or compromised passwords | SHALL |
| Accepted characters | All printing ASCII characters, the space character and Unicode | SHOULD |
| Paste and display | Allow pasting from the clipboard and offer an option to display the typed password | SHOULD |
| Hints and questions | No hints reachable without authenticating, and no knowledge-based authentication | SHALL NOT |
| Storage | Salted and hashed with a suitable scheme; salt of at least 32 bits | SHALL |
Two details are usually overlooked and both matter. First: allowing paste is not a concession to convenience, it is what makes a password manager usable; forms that block pasting push people straight towards memorable, weak keys. Second: screening against breach lists beats complexity rules, because it does not block good passwords, it blocks exactly the ones an attacker would try first. And it can be done without sending the full password anywhere, using hash prefix lookup.
And in Europe: what actually binds you
European law sets no lengths and no deadlines. It sets outcomes, and leaves the technical measures to you. This is what you will be asked to demonstrate:
Technical and organisational measures appropriate to the risk, with express mention of encryption and of the ability to ensure confidentiality on an ongoing basis. A documented, applied authentication policy is part of the answer; without one, the risk assessment is left open.
"Authentication information": it covers how it is generated, allocated, distributed, used and revoked. Watch the distribution part, which is the one that most often fails: handing the credential over through a secure channel and not transmitting it in the clear. We cover it in why you should not send passwords by email.
The UK National Cyber Security Centre reached the same conclusions years before NIST formalised them: drop forced expiry, drop complexity requirements, use blocklists, and design the system so people are not pushed into insecure workarounds. If you operate in the UK, this is the guidance an assessor is most likely to quote at you.
It expressly includes multi-factor or continuous authentication, cryptography policies and secure communications among the risk management measures required of in-scope entities. Of everything cited here, it is the one that pushes you towards multi-factor most directly. We cover it in what NIS2 requires of your company.
Practical summary: Europe tells you what you have to achieve, NIST and the NCSC give you a defensible how. Citing SP 800-63B-4 in your policy is the quickest way to justify removing periodic expiry when someone challenges it in an audit.
What matters more than the policy: passwords are not cracked, they are stolen
It helps to keep perspective. Almost no real attack starts with someone trying combinations until they guess a 12-character key. It starts with a phishing email, with a program that harvests what the browser stored, or with a reused credential that was already in somebody else's breach. Against that, length does nothing.
The Verizon DBIR 2026 puts credential abuse in 39% of all breaches at some point in the attack chain — the most pervasive technique in the report — even though as an initial access vector it fell to 13% from 22% the year before, overtaken by vulnerability exploitation (31%). Put differently: credentials remain the fuel of the attack even when they are no longer always the lock it comes through.
That gives you the order of priorities worth defending to the board:
- Phishing-resistant multi-factor authentication on everything facing the internet: VPN, email, systems administration, remote access.
- Screening against breached password lists at enrolment and on every change.
- Minimum length plus a corporate password manager so that length is bearable.
- A secure handover channel for credentials, which is where what the policy does not look at leaks out.
- Removing obsolete rules: expiry, composition, security questions.
And the deeper goal, wherever you can reach it: no password at all. Passkeys remove the shared secret and with it credential phishing; SSO with multi-factor authentication cuts the number of passwords each person has to handle from dozens to one.
The blind spot: how a credential is handed over
Almost every password policy describes in detail what the password must look like, and not one line about how it is handed over. And that is exactly where everything gained is lost: the engineer who needs the FTP password this afternoon, the client who needs the certificate PIN, the person starting tomorrow who needs their first-day access.
Written into an email or a chat, that credential stays copied indefinitely in the recipient's mailbox, on their phone, in the histories and in the backups, with no expiry and with no way of knowing who has seen it. It is exactly what control A.5.17 asks you to avoid, and it is the part of the policy almost nobody drafts.
The right way is a one-time secret: the content travels encrypted, is shown once and is deleted from the database, with an expiry even if nobody opens it, recipient verification through a code or passphrase, a read receipt and a record of the handover. The full story is in sending passwords by email: why it still happens and how to stop.
Template: your password policy on one page
Ten clauses you can copy, adjust to your organisation and approve. A policy that does not fit on one page is a policy nobody reads, and a policy nobody reads is a policy nobody follows.
- Length. Minimum 15 characters where the password is the only factor; minimum 12 where a second factor is present. The system accepts at least 64 and allows spaces and accented characters.
- No composition rules. No uppercase, digits or symbols are required. A long phrase of several words is recommended.
- No periodic expiry. Passwords are changed on evidence of compromise, when they appear in a known breach, or at the user's request.
- Mandatory screening. At enrolment and on every change, the password is checked against a list of common and breached passwords and rejected if it appears.
- Multi-factor authentication. Mandatory on every internet-facing service and on every account with administrative privileges. Phishing-resistant wherever possible.
- Password manager. Corporate, mandatory for shared team credentials. Storing work credentials in spreadsheets, documents or phone notes is prohibited.
- No reuse. No work password may match a personal one or be repeated across corporate services.
- Handover. Credentials are always handed over through a one-time channel with expiry and logging. Writing them into emails, chats, tickets or shared documents is prohibited.
- Privileged and service accounts. Unique credentials, named wherever possible, held in the manager, rotated when the person or supplier leaves, and reviewed every six months.
- Leavers and incidents. When a person or supplier leaves, their access is revoked the same day and the shared credentials they could reach are rotated. Every repeated failed attempt and every lockout is logged and reviewed.
If you run an ISO 27001 management system, clauses 1 to 7 answer control A.5.17 on the generation and use side, clause 8 on the distribution side — the one usually forgotten — and clauses 9 and 10 connect to joiner/leaver management and to event logging.
Frequently asked questions
Should people be forced to change their password every 90 days?+
No, and since revision 4 of NIST SP 800-63B it is expressly ruled out: verifiers SHALL NOT require periodic password changes, and SHALL force a change only where there is evidence of compromise. The reason is behavioural: when people are forced to change every few months they produce predictable variations of the previous password, write it down, or reuse the same pattern everywhere. The net result is worse than leaving one long, unique password alone and watching for it in breach data.
What is the recommended minimum length in 2026?+
NIST SP 800-63B-4 requires a minimum of 15 characters where the password is the only authentication factor, and allows 8 where it is part of a multi-factor scheme. It also recommends permitting at least 64 characters, accepting all printing ASCII characters, the space character and Unicode, and allowing paste so that password managers work.
Do complexity rules with uppercase, numbers and symbols still make sense?+
No. NIST SP 800-63B-4 states that verifiers SHALL NOT impose composition rules of that kind. They force predictable transformations (a capital at the start, a digit and an exclamation mark at the end) that add very little real entropy and badly hurt usability. What you should do instead is compare the chosen password against a blocklist of common, expected or compromised passwords and reject it if it appears.
What is breached password screening?+
It means comparing the password a user wants to set against a list of keys known to appear in public breaches, dictionaries or the most-used lists, and rejecting it if it matches. It replaces complexity rules with a clear advantage: it does not block good passwords, it blocks exactly the ones an attacker would try first. NIST requires it, and the check can be done without sending the full password anywhere, using hash prefix lookup.
Are security questions still valid for account recovery?+
No. NIST SP 800-63B-4 expressly prohibits verifiers from prompting for knowledge-based authentication, of the "name of your first pet" kind. The answers tend to be public information or easy to find on social media, and they are shared across services. It also prohibits password hints that are accessible to an unauthenticated claimant.
What does European law require about passwords?+
European law does not set lengths. Article 32 of the GDPR requires technical measures appropriate to the risk, control A.5.17 of ISO/IEC 27001:2022 governs the management and distribution of authentication information, and the NIS2 Directive lists multi-factor authentication and cryptography policies among its risk management measures. Concrete technical guidance, such as NIST SP 800-63B or the UK NCSC's password collection, is the usual reference for filling in the "how".
What matters more, the password policy or multi-factor authentication?+
Multi-factor, by a long way. A password stolen through phishing or by an infostealer is just as stolen whether it was 8 or 20 characters. So the sensible order of priority is: phishing-resistant multi-factor authentication on everything exposed to the internet first, then breached password screening, then length, and last of all stopping the practices that are no longer recommended. Where possible, the goal is to take the password out of the picture altogether with passkeys and SSO.
How do you hand a password over without breaking the policy?+
By never typing it into the channel you send it through. The right way is a one-time link: the content travels encrypted, is shown once and is deleted, with an expiry, recipient verification and a record of the handover. Typing it into an email or a chat leaves permanent copies in mailboxes, phones and backups, which is exactly what control A.5.17 of ISO 27001 asks you to avoid.
Sources
- NIST SP 800-63B-4, Digital Identity Guidelines: Authentication and Authenticator Management (final version, July 2025): section 3.1.1, requirements on length, composition, expiry, blocklist screening, accepted characters, hints and storage.
- NCSC: password administration for system owners.
- Regulation (EU) 2016/679 (GDPR): Article 32, security of processing.
- ISO/IEC 27001:2022: control A.5.17, authentication information.
- Directive (EU) 2022/2555 (NIS2): Article 21, including multi-factor authentication.
- Verizon Data Breach Investigations Report 2026: credential abuse appears in 39% of breaches somewhere in the chain; as an initial access vector it drops to 13% from 22% the year before, overtaken by vulnerability exploitation (31%).
The clause almost nobody writes is the one most often broken
Book 20 minutes and we will go through the credential handover part of your policy together: how they are handed out today, what leaves a trace, and how to set up the one-time channel with logging and a certificate. No commitment.