When Recovery Is the Way In

For years, all it took to reset a password was a hire date and a manager's name.

A locked-out user called the service desk, confirmed both, and got a new password. If they did not want to call, they could answer their own security questions online.

Both felt reasonable. Both depended on facts that are not secret. Anyone inside the company can look up a manager's name in the directory, and a hire date is often on a public profile. Security answers can be researched or phished.

What the desk was doing on those calls was identity proofing, and in my book I make the point that proofing is not a one-time event. We prove who someone is when they join. Every locked-out account asks us to prove it again, and that second moment is under far heavier attack than the first.

Strong authentication does not help if the way back in is weaker. Attackers rarely break MFA. They call the service desk, say they are locked out, and ask for a reset.

So we changed the recovery path. Users got self-service password reset. When someone called, the desk sent a link to the personal email or phone the user had registered, or the user proved who they were through their authenticator app. The desk stopped deciding who someone was from facts anyone could look up. The proof came from something the user had.

A change like that covers what sits behind single sign-on. Most organizations also have applications that are not connected, each with its own local passwords and its own way to reset them, like an administrator who emails a temporary password. Each one is another way back in.

AI makes the old way riskier. A cloned voice can sound like the employee on the phone, and the answers to the old questions are a search away.

The leader's part starts with one question: how does someone get back in when they are locked out?

Look at what your service desk and your self-service tools accept as proof. If it is something someone else could find, change it. The strength of the proof should match what the account can reach.

Move the proof to something the person has, and let the desk send a link instead of making the call on who someone is.

Include the applications that are not connected. For each one, know how a password gets reset and who can do it, starting with the few that matter most.

Decide what happens when someone has lost the device the link would go to, before that call comes in.

And back your service desk. Give them stronger proof to lean on, and stand behind them when a refused reset turns into an angry escalation.

I would look at the way back in before spending more on the front door.

Related

• Series 3 Post 1: LinkedIn post
• Series 3 Post 3: LinkedIn post