Password reset automation: who is really asking?

A call comes in to the service desk late on a Friday. The caller says he works in finance, he’s at an airport, and he’s locked out before a board meeting on Monday. He knows his manager’s name and his start date. The analyst resets the password and reads the temporary one out over the phone. The caller doesn’t work in finance.

Most resets are far more ordinary. Someone forgot a password over a holiday, or an old phone with a saved password locked the account again. Each one is the same few minutes of work, and there are a lot of them.

Password resets and lockouts are the second stage of the IT service desk. For most IT teams they’re the obvious first thing to automate, and the identity check decides whether automating them is safe.

What is password reset automation?

Password reset automation lets people reset a password or clear a lockout themselves, from Slack, Teams or the login page, after confirming who they are with a second factor they already enrolled. The reset runs in the identity provider, such as Okta or Azure Active Directory. It sends a one-time link instead of a password, and records how identity was confirmed.

Why resets go wrong

1. Identity is checked with facts anyone can find. A manager’s name, a start date and an employee ID are on LinkedIn, in an org chart or in an old email.
2. Passwords travel in chat. A temporary password pasted into Slack stays in the history for years.
3. Admin accounts take the same path. The account that can change everything is reset the same way as everyone else’s.
4. Lockouts are cleared and forgotten. Someone locked out every Monday has a saved password on an old device, and repeated lockouts from a new location are a warning sign. Clearing the lockout fixes neither.
5. The only route is a ticket. If self-service means raising a ticket, IT still does the work.
6. Nobody records how identity was confirmed. When security asks who reset an account and how, the answer is a guess.

What it costs

Each reset is a few minutes, and the minutes add up. Resets interrupt the people who could be fixing harder problems, and they arrive at the worst times: Monday mornings, the day after a holiday, and weekends when nobody is on call.

The bigger cost is the one reset that goes to the wrong person. Attackers call help desks for exactly this reason. A convincing caller with a name and a manager’s name can often get a password, and with it everything that password opens.

What to fix first

1. Size the problem. Count resets, lockouts and multi-factor tickets per week, and find the people who had more than three in a month. They have a problem a reset won’t fix.
2. Take the request where people are. Add a “Can’t log in” action in Slack and Teams, and a link from the login page for anyone locked out of chat too.
3. Confirm identity with a factor they already have. Send a push to the authenticator app or a code to a phone number on record, and never rely on facts someone can look up.
4. Send a one-time link, never a password. Make it expire in minutes.
5. Send admin accounts to a person. However good the check, an account with admin rights doesn’t reset itself.
6. Record every reset. Log who, when, how identity was confirmed and what changed, so a run of resets from new locations shows up as the warning it is.

The guide to building self-service password reset has the prompts for each step.

What it looks like at Apollo

One Saturday night, a director at Apollo was locked out of his laptop. Apollo’s IT agent, built on Tray.ai, had him back in within seconds, with nobody from IT on call. The agent handles routine fixes like that one, and escalates to a person when it can’t solve the problem.

Where it fits

Resets are usually the first job an AI support agent takes on, because the check and the action are the same every time. They depend on triage recognizing a lockout when someone writes “I can’t get into anything”. They also depend on knowing which accounts hold admin rights, which is something access requests should record when access is granted.

For all six stages, see the IT service desk process.