Loading

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.