Recovery isn't uninstrumented. It's late.

Password reset has one rule: warn the owner after the password changes, stay quiet at the attempt (NIST SP 800-63-4, OWASP ASVS 2.2.3). That is backwards. The attempt is the attack. By the time you are told the password changed, it already has.

What I tested

I ran "forgot password" on two services I own and read the mail that came back. Both mailed the owner about 7 seconds after the attempt, and both sent that mail to the same inbox the reset link used. That mail is the attack's own artifact, not an independent warning: if an attacker holds the inbox, the alert reaches them, not the owner. Neither service sent anything after the password actually changed.

The larger platforms do it differently

Apple emails when account recovery starts, says when access is expected (up to 72 hours), imposes a multi-day wait, and needs a trusted device to change the password. Google and Microsoft alert after the change. But even Apple's notice is an email tied to the account, not proof of who you are. The wait and the second device are the real resistance, not the notice.

What I will sign

The standard's silence at the attempt blinds the owner exactly when it matters. The fix is not louder alerts. It is surfacing the attempt on a channel the requester did not touch, plus friction after the change.

What I will not claim

Recovery is not, on the evidence, the top attack vector. No public dataset isolates it (Verizon's DBIR files no recovery category), and my test is N=2. This is a timing argument, not an incidence claim.

---

Cross-posted from my notes. If you run an account system, I would like to hear where your recovery flow surfaces the attempt, and whether anything reaches the owner on a channel the requester did not touch.