Security belongs in the support workflow

When a user is locked out, a support agent is under pressure to help quickly. An attacker can exploit that urgency by asking the agent to reset a password, replace a second factor or change credentials using a route that bypasses the normal account owner.

Support should assist recovery, not replace proof

Write down which actions support can take, which evidence they need, and when they must escalate. Support staff should not receive a broad shortcut that silently overrides the assurance required for the account. Actions must be limited by role, and every sensitive change should leave an auditable record.

Make recovery a defined ceremony

Recovery has different assumptions from a routine profile change or credential enrollment. A recovery policy may require designated recovery credentials, additional verification, notification, a temporary lock or the revocation of existing keys. The policy should be explicit so support actions cannot accidentally create a weaker path.

Test the bad day

• A caller has convincing personal details but no valid recovery proof.
• A session may be hijacked and is used to enroll a new credential.
• A privileged account requests recovery.
• A support agent makes a mistake and the team must determine what changed.

For each scenario, define the permitted action, the required evidence, the notification path and how to investigate afterwards. The goal is not to block legitimate recovery; it is to make the process reliable even under pressure.

What the permission change does to the attack

The usual response to help desk social engineering is better training and a stricter verification script. Both help, and both decay: scripts get skipped under load, and the one call that matters is made by someone unusually convincing.

Changing the permission changes the shape of the attack rather than the odds of spotting it. If support can only add a recovery credential, the legitimate owner keeps working credentials, is not locked out, and has no reason to stay quiet. They receive a notification about something that has not yet cost them anything, which is the ideal moment to get one.

What should follow a completed recovery

Recovery is a signal that something may already have gone wrong, so the sensible default is to treat it that way: optionally delete older credentials, lock the account briefly, and revoke the API keys the account held. A recovered account that silently keeps issuing valid tokens from before the incident is a gap worth closing.

Recovery should also be its own ceremony with its own credentials, rather than something satisfiable by assembling part of a user’s normal set. If the same factors work for both, recovery is not a separate path — it is a second front door.