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
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.