Resetting Someone’s Password

An administrator can reset somebody's password. The mechanics take seconds; the verification is the part that matters.

Where to find it

Architect Panel → Security:

• Disabled User Accounts — accounts closed administratively
• Blocked User Accounts — accounts banned after failed sign-ins
• Permissions — what a group grants
• Passkeys — the stronger alternative

Architect Panel → Configuration:

• Site Settings — the self-service route

Architect Panel → Activity:

• Activity Log — the record of the reset

This is the attack

Somebody telephoning to ask for a password reset is exactly what an attacker does, and it is the route round every control you have — a passkey cannot be phished, and a service desk can be talked to.

The reset is not the risk. The lack of a verification step is.

Verify with something they cannot easily obtain

Not a name, a date of birth, or an address — all of which are widely known or discoverable. Something specific: a callback to a number already on record, confirmation from their manager, a code sent to a channel they already control, or an in-person check.

Write down what your check is, so it does not depend on who happens to answer the telephone.

Prefer self-service

A reset link to a verified address is a stronger check than a hurried human conversation, and it leaves a cleaner record. Unless you have a rigorous, tested identity process, self-service is the better default and administrator resets should be the exception.

Send a link, never a password

The same rule as account creation. A password you choose and communicate is known to two people and sits in a mailbox.

Ask why they are locked out

Before resetting anything:

• Forgotten — reset, or point them at self-service.
• Recently changed it — something else is probably still using the old one.
• They were not trying — somebody else was. That is an incident, not a reset.

The third answer changes everything, and you only get it by asking.

Check what is actually wrong

A reset does nothing for an account that is disabled, banned after failed attempts, or blocked by address. Check those before resetting — it is the commonest reason a reset "does not work".

Record it

Who asked, how you verified them, and what you did. That is the record that matters if the request turns out not to have been genuine, and it takes a sentence.

Repeated resets are a signal

The same account needing frequent resets is usually a stale credential in some client retrying, or somebody being targeted. Investigate the third occurrence rather than performing it again.

Worked example

A caller asks for a reset. The administrator calls back on the number held on record, confirms, sends a set-password link rather than a password, and notes the verification in the ticket. On another occasion the same check found the caller could not receive the callback — which turned out to be somebody attempting to take over the account.

Recommendations

• Verify with something not publicly known.
• Prefer self-service to an administrator reset.
• Check for disabled, banned or blocked first.
• Record who asked and how you checked.