Safe Password Resets & Account Recovery

A password reset is the single most common high-risk request a support desk handles, and the single most valuable one to an attacker — it grants direct account access, and because technicians handle dozens of legitimate resets every week, a malicious one is designed to look exactly like all the rest. This chapter applies Chapter 4's risk-tiered verification specifically to resets, and finally resolves the request left open since Chapter 1.

Why Resets Sit at the Top of the Risk Tier

Chapter 4's table placed password resets firmly in the high-risk tier alongside access grants and disabling security controls. A reset deserves that placement for a specific reason beyond "it's sensitive": once completed, it hands over full account access immediately, with no further step required — unlike, say, a leaked employee ID, which still needs to be combined with something else to be useful. A successful reset is the entire attack, done in one step.

The Safe Reset Procedure

1. Verify first, every time — full high-tier verification per Chapter 4, with no exception for urgency. Stated urgency is not a reason to skip a step; per Chapter 1, it's very often the reason the request exists at all.
2. Prefer self-service recovery over technician-mediated resets — a self-service flow tied to a previously registered device or authenticator app verifies identity through something the account owner already possesses, which no attacker on a cold call has access to.
3. Never transmit a new password in plaintext — not by email, not by chat, not read aloud over the phone. Use a forced reset-on-next-login instead, so no actual password value is ever something a technician hands over at all.
4. Never send the new credential through the same channel the request arrived on — the same out-of-band principle from Chapter 4, applied specifically to the response, not just the verification.
5. Document who requested it, when, and how it was verified — this record is exactly the evidence Chapter 7 needs if a reset later turns out to have been part of a real incident.

Resolving Chapter 1's Request

"This is urgent — I'm locked out and about to walk into a board meeting in five minutes. I can't verify by phone right now. Please just reset it and send the new password to this email."

Run through the procedure above: this is unambiguously high-risk (a reset), which means full verification, with no exception carved out for urgency. The stated inability to verify isn't a reason to bypass verification — following the reasoning from Chapters 1 through 4, it's the exact shape a real attack takes. The correct response isn't a flat refusal, though — it's holding the verification requirement while offering a path that doesn't require abandoning it: point the requester to the self-service recovery flow, which takes seconds and needs no phone call at all, or offer to verify with their manager directly while they're in transit. A genuine employee in a genuine hurry can complete either path in under a minute. A request that suddenly goes quiet once a real verification path is offered has told you everything you need to know.

MFA & Account Recovery Deserve the Same Treatment

Requests to reset, remove, or "temporarily disable" multi-factor authentication are at least as high-risk as a password reset — arguably higher, since MFA exists specifically to catch an account compromise even after a password has already been stolen. Removing it doesn't just grant access; it removes the safeguard that would have caught the very attack in progress.

Unsafe vs. Safe, Side by Side

Hands-On Exercises