Loading

Enabling Password Resets

Self-service password reset lets somebody recover their own account without contacting anybody. It removes a great deal of support work and introduces a route into every account, so it is worth configuring deliberately.

Where to find it

Architect Panel → Configuration:

  • Site Settings — Enable Password Resets, Password Reset Time Limit, Method, e-mail account and template, and the Password Policy group

Architect Panel → Security:

  • Security Check-up — the Self-service password reset row, which shows whether resets are on and how long a link lasts

Architect Panel → Activity:

  • E-mail Log — whether a reset message was sent
  • SMS Log — reset codes sent by text

The settings

  • Enable Password Resets: ships on.
  • Password Reset Time Limit: how many minutes the link stays valid. Ships at 60.
  • Password Reset Method: e-mail or SMS. Ships as e-mail.
  • E-mail account and template, or an SMS sender name.

The reset path is a way into every account

This is the framing that matters. Whatever you do to protect sign-in (strong passwords, a second factor, passkeys), the reset process is an alternative route to the same place.

An attacker who cannot phish a passkey will try the reset flow, and if that flow depends only on access to a mailbox, the account is only as strong as that mailbox. Design accordingly.

Shorten the time limit

Sixty minutes is generous for something a user requested and is waiting for. A reset link works for whoever holds it: anybody with it can set the password. An hour is a long time for it to sit in an inbox, a forwarded message or a mail archive.

Fifteen to thirty minutes is ample for somebody actually resetting their password, and materially reduces the window.

A reset must still meet the password policy

A password chosen through the reset flow is checked against the same password policy as any other: minimum length, the common-password and username checks, any composition rules, and the reuse rule. The new password is recorded in the person's password history, so Previous Passwords To Remember stops somebody resetting straight back to the password that was just guessed or leaked.

Earlier releases had separate password-expiry and unique-password settings in the user account settings. Nothing ever read them, so they were never enforced, and they have been removed. Reuse and expiry are now set in the Password Policy group of Site Settings, where they are enforced.

Rate limiting still applies

Account and address banning apply to reset attempts as they do to sign-in, so repeated abuse of the reset form is caught by the same controls. Do not treat that as sufficient on its own, but it is a useful floor.

Watch for enumeration

Consider what the reset form tells somebody who enters an address that does not exist. If it responds differently, it discloses which addresses are registered. That is the same consideration as the login page mode, and worth checking against the same standard.

Do not disable it and rely on the service desk

Turning off self-service reset moves every reset to a person, and a hurried human is a weaker check than a link to a verified address. Unless you have a rigorous, tested identity process, self-service is the stronger option.

Worked example

An organisation keeps self-service reset enabled and shortens the link validity from sixty minutes to twenty. In the Password Policy group it sets Previous Passwords To Remember to 5 and leaves Password Expires After (Days) at 0. A test reset to the account's current password is refused, and the Security Check-up confirms reset links now expire after 20 minutes. Reset volume is unchanged; the exposure window is a third of what it was.

Recommendations

  • Shorten the link validity to 15 to 30 minutes.
  • Switch on reuse prevention in the Password Policy group; leave expiry off unless required.
  • Treat the reset path as an authentication route and protect it accordingly.
  • Check the form for address enumeration.