Password Resets

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.

E-mail or SMS

Reset links go by e-mail or by SMS. The choice decides what somebody needs in order to recover an account.

Where to find it

Architect Panel → Configuration:

• Site Settings — Password Reset Method, and the account, template or sender name

Architect Panel → Activity:

• E-mail Log — delivery of reset e-mails
• SMS Log — delivery of reset texts

E-mail

The default and the right choice for most installations. Free, universal, and it works wherever somebody has their mail.

Its weakness is that account recovery becomes exactly as strong as the mailbox. Someone with access to a person's e-mail can reset their password here, and often elsewhere too.

SMS

Requires a verified mobile number on the account, which many populations do not have. It costs per message, and it is vulnerable to SIM swapping — the reason not to use it for administrators.

Its advantage is independence: recovery does not depend on a mailbox that may itself be compromised, which matters if e-mail is the thing you are worried about.

Think about the combination

This is the part usually missed. If somebody's second factor is an SMS code and their password reset also goes by SMS, then control of the phone alone gives complete account takeover — the two factors have collapsed into one.

The same is true of e-mail reset alongside an e-mail-based factor. Where you can, use different channels for authentication and for recovery.

Administrators should not rely on either

For privileged accounts, prefer a passkey and a supported recovery process with a real identity check, rather than self-service reset by any channel.

Test delivery before relying on it

Reset messages are the ones that must arrive. Confirm your sending domain is properly configured and send test resets to the mail providers your users actually use — corporate filters are the usual obstacle, and a reset that never arrives looks to the user like a broken service.

For SMS, check the sender name is recognisable and the message reads clearly on a lock screen.

Watch the logs

When somebody says a reset never arrived, the e-mail or SMS log settles it in seconds: sent successfully to a wrong address, sent successfully and filtered at the far end, or never sent at all. Each has a different answer.

Keep the message plain

A reset e-mail should be recognisable, short, and free of anything that makes it look like marketing. Users are increasingly cautious about clicking links, and a reset message that looks like a phishing attempt does not get used.

Worked example

A service uses e-mail reset for its public users and requires passkeys with a supported, identity-checked recovery process for its dozen administrators. Users who have chosen SMS as their second factor still reset by e-mail, so no single device gives both factors.

Recommendations

• Use different channels for the second factor and for recovery.
• Do not give administrators self-service reset.
• Test delivery to the mail providers your users use.
• Keep the message plain and obviously transactional.

The Reset Message

The reset message is one of the few your users are guaranteed to read, and it arrives at a moment of mild frustration. It is worth getting right.

Where to find it

Architect Panel → Configuration:

• Site Settings — the e-mail account and template used for resets

Architect Panel → Layout & Pages:

• E-mail Templates — the template itself
• E-mail Designs — its appearance

What it must contain

• Who it is from, unmistakably.
• What it is for — a password reset somebody requested.
• The link, prominent and obvious.
• How long the link is valid.
• What to do if they did not request it.

State the expiry

People do not act immediately. Saying the link is valid for twenty minutes sets the expectation and prevents the commonest support call — somebody clicking an expired link and concluding the system is broken.

Say what to do if they did not ask

An unrequested reset message means somebody is trying to get into that account. Tell the recipient plainly: ignore the message, their password is unchanged, and contact you if it keeps happening.

That last part matters — repeated unrequested resets are an early warning of a targeted account, and the recipient is the only person who knows they are happening.

Do not include the password

Obvious, and still worth stating. The message carries a link to set a new one; it never carries a password.

Keep it plain

Heavy design, marketing content and multiple links all make the message look less trustworthy and more like phishing. A short, plain, clearly branded message gets used; an elaborate one gets reported as suspicious.

It also survives better in text-only clients and screen readers, which matters for a message that must work for everybody.

Make the link a link

Some clients do not render buttons well, and some users copy the address rather than clicking. Include the link in a form that can be copied, and do not rely on a styled button alone.

Send from a recognisable address

An address at your own domain, matching what users expect. A reset from an unfamiliar third-party sending domain is exactly what a phishing attempt looks like, and cautious users will not click it.

Check it in real clients

Send it to yourself in the mail clients your users actually use — including a phone — and read it as somebody who is slightly annoyed and in a hurry. That is the real test.

Worked example

A team rewrites their reset e-mail to four short lines: what it is, the link, "this link expires in 20 minutes", and "if you did not request this, ignore this message — your password has not changed". Reset-related support enquiries fall away, and two users later report repeated unrequested resets, which turns out to be a targeted account.

Recommendations

• State the expiry in the message.
• Tell people what to do if they did not request it.
• Keep it plain and send from your own domain.
• Test it on a phone before shipping it.