Password Policy

Setting a Password Policy

The password policy sets the rules a password must meet before the platform will accept it: how long it must be, whether it needs particular kinds of character, and which obvious choices are refused. It applies to local accounts, the ones whose password the platform holds. People who sign in through Active Directory, Azure AD, SAML or a social provider are governed by that provider's rules instead.

Where to find it

Architect Panel → Configuration:

• Site Settings — the Password Policy group, with its own Save Settings button

Architect Panel → Security:

• Security Check-up — the Password policy section, which shows the policy in force and assesses it

The settings

• Minimum Password Length: the fewest characters a password may have. Ships at 8. Counted in characters, so an accented passphrase is measured fairly.
• Maximum Password Length: a ceiling, so an enormous input cannot be used to tie up the server. Ships at 128. Do not raise it above 128: the platform's password hashing refuses anything longer, so a higher value would accept a password that then fails to save.
• Require A Capital Letter, Require A Lower-case Letter, Require A Number and Require A Symbol: composition rules. All four ship off.
• Block Common Passwords: refuses a short list of the passwords people choose when they do not care, such as password or 12345678. Ships on. It is a short list by design, not a list of every breached password, so do not describe it as one in an audit.
• Block Passwords Containing The Username: refuses a password that contains the username, checked without regard to case and only when the username is at least four characters long. Ships on.
• Previous Passwords To Remember and Password Expires After (Days): reuse and expiry, covered in Password Expiry and Reuse. Both ship at 0, which means off.

The shipped values match what the platform allowed before the policy existed, so switching to a release with these settings changes nobody's experience until you change them.

Setting a policy

1. Open Site Settings and find the Password Policy group.
2. Set Minimum Password Length. Twelve is the figure Cyber Essentials expects when you have no multi-factor authentication; eight is accepted alongside multi-factor authentication or common-password blocking.
3. Leave Block Common Passwords and Block Passwords Containing The Username on.
4. Switch on composition rules only if a contract or procurement requires them.
5. Click Save Settings for the group.
6. Open Security Check-up and confirm the Password policy section shows the new values.
7. Change your own password to one that breaks a rule, and check the message you are shown.

Why length rather than composition

The NCSC and NIST both advise raising the minimum length rather than demanding capitals and symbols. Composition rules push people towards predictable patterns, such as a capital at the start and a number and symbol at the end, and away from the long passphrases that are genuinely hard to guess. The Security Check-up says so in its note on composition rules, and an assessor will usually accept a length-only policy with that reasoning.

Where it is enforced

Every place a local password is set: a person changing their own password on their account page, self-registration, the administrator's user editor, the forgotten-password flow, vendor sign-up, the installer and any form with a password field. Restoring an old version of an account from its audit history cannot bring back an old password. The rules apply when a password is set or changed; existing passwords are not re-checked, so a stricter minimum takes effect as people change their passwords.

Somebody changing their own password must also enter their current one, so a person who finds an unlocked, signed-in browser cannot take the account over.

What people see

A refused password produces one message saying what is wrong and nothing else, for example "Your password must be at least 12 characters long.", "Your password must contain a number.", "That password is too easily guessed. Please choose another." or "Your password must not contain your username."

What goes wrong

• The new rule is not applied. Check you clicked Save Settings for the Password Policy group, not another group on the same screen.
• Site Settings shows a configuration inconsistency for a Password Policy setting. The setting is missing from the server's configuration file. Your hosting administrator needs to add it before the group can be saved.
• Single sign-on users are not affected. That is correct: their password is held by their identity provider.

Worked example

A training provider's Security Check-up shows Minimum length: 8 characters, assessed as Review, with no multi-factor authentication in force yet. The administrator raises the minimum to 12, leaves composition rules off, keeps both blocking rules on and saves the group. The check-up now shows OK for length. A test change to "Spring2026" is refused as too short, and the help desk's script is updated with the new message.

Recommendations

• Raise the minimum length before reaching for composition rules.
• Keep both blocking rules on.
• Never set the maximum above 128.
• Tell users before tightening the policy, and say what the new rule is.
• Pair the policy with a second factor; a good password is still a single factor.

Password Expiry and Reuse

Two password policy settings deal with time rather than content: one stops people reusing a recent password, and one makes passwords expire after a set number of days. Both ship switched off. This article explains what each does, who it affects and when switching it on is worth it.

Where to find it

Architect Panel → Configuration:

• Site Settings — Previous Passwords To Remember and Password Expires After (Days), in the Password Policy group

Architect Panel → Security:

• Security Check-up — the Previous passwords remembered and Password expiry rows

Previous Passwords To Remember

How many of a person's previous passwords they may not use again. 0 turns the check off. It counts passwords, not days: set to 5, somebody cannot reuse any of their last five.

• It is checked whenever a local password is set, including through the forgotten-password flow, and the new password is added to the history at the same time.
• A refused password tells the person they have used it before and asks them to choose another.
• The check compares against stored, scrambled copies of old passwords, never readable ones.

Reuse prevention is worth switching on, particularly with password resets enabled. Without it, a person locked out of their account can reset to the same password that was just guessed or leaked.

Password Expires After (Days)

When set above 0, a person whose password is older than this many days is sent to the change-password screen when they next sign in, and cannot use the rest of the site until they choose a new one. The new password must meet the whole policy, including the reuse rule.

• It applies to local accounts only. A password held by Active Directory, Azure AD, SAML or a social provider is never expired here, because the person could not change it here.
• The age is measured from the newest entry in the person's password history. When the feature arrived, every existing password was stamped as set at that moment, so switching expiry on cannot lock anybody out straight away.
• An account with no password history is never treated as expired.
• It takes effect at sign-in. Somebody already signed in carries on until their next sign-in.

Should you switch expiry on?

Usually not. The current NCSC and NIST position is that forced rotation makes passwords worse: people respond with predictable increments, such as Autumn2026 becoming Winter2026, which an attacker who has seen one can guess. The Security Check-up describes expiry off as deliberate and assesses it as information, not a gap.

Switch it on when a contract, a regulator or an assessor requires it and will not accept the reasoning above. If you do, pair it with Previous Passwords To Remember, or expiry achieves nothing: people will simply set the old password again.

Switching them on

1. Open Site Settings and find the Password Policy group.
2. Set Previous Passwords To Remember, for example to 5.
3. If required, set Password Expires After (Days), for example to 365. Avoid short periods such as 30 days, which produce the most predictable passwords.
4. Click Save Settings for the group.
5. Tell your users before the first expiry date arrives, so the change-password screen at sign-in is expected.
6. Check the Password policy section of the Security Check-up shows the new values.

What goes wrong

• Nobody has been asked to change their password yet. Expect this: ages start from the point the feature was installed or the password was last set, not from when the account was created.
• A single sign-on user asks why they were never prompted. Expiry does not apply to them; their identity provider sets their rules.
• Help desk calls the morning after. Expiry falls due at sign-in, so a period chosen without notice produces a cluster of calls. Announce it first.

Worked example

A local authority's assessor insists on annual password changes. The administrator sets Password Expires After (Days) to 365 and Previous Passwords To Remember to 5, and records in the audit file that expiry was enabled at the assessor's request against NCSC guidance. Because existing passwords were stamped when the feature arrived, the first prompts arrive a year later rather than on day one, and the help desk is briefed a fortnight before.

Recommendations

• Switch on reuse prevention; it costs users little.
• Leave expiry off unless somebody with authority requires it.
• Never use expiry without reuse prevention.
• Choose long periods, such as a year, if you must expire passwords.
• Announce expiry in advance, so the prompt at sign-in is no surprise.