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

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.
• 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 is a bearer token: anybody holding 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.

Password expiry and reuse

Two related settings sit alongside: Password Expiry with a maximum age, and Require Unique Password, which prevents reusing a previous one.

Expiry ships off, and that is the modern consensus — forced rotation produces predictable variations rather than better passwords. Preventing reuse is worth enabling; forced expiry usually is not, unless a standard obliges you.

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 — 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, shortens the link validity from sixty minutes to twenty, enables the unique-password requirement and leaves expiry off. Reset volume is unchanged; the exposure window is a third of what it was.

Recommendations

• Shorten the link validity to 15–30 minutes.
• Enable unique-password enforcement; leave expiry off.
• Treat the reset path as an authentication route and protect it accordingly.
• Check the form for address enumeration.