The Password Reset Is the Hardest Easy Ticket

Open any MSP automation roadmap and password reset is item one. It’s the highest-volume L1 ticket, the most repetitive, the most obviously mechanical. The API call is four lines of code. Every vendor demos it.

And it is, by a wide margin, the most dangerous thing on the list.

The execution is trivial. What surrounds the execution is not, and the gap between those two facts is where most automated resolution projects quietly stall — usually about six weeks after someone successfully resets a password in a demo tenant and everyone agrees this is going to be easy.

Three sub-problems sit inside the “simple” password reset. None of them are about resetting passwords.

Sub-problem one: is this the account owner?

Covered at length in Caller ID Is Not Authentication, so briefly: the request arrives from someone claiming to be locked out, and the claim is unverifiable by the channel it arrived on. An email from the user’s address means nothing when the account may be compromised. A call from their number means nothing because caller ID is a claim, not a proof.

The specific trap in password reset is that the ticket is self-attesting. Every other ticket type carries some external corroboration — an RMM alert, a device, a colleague who also noticed. A password reset request is one person asserting a fact about themselves that only they can see. There’s nothing to check it against unless you deliberately build something.

What makes this tractable is that the locked-out user usually retains a factor: their enrolled phone. The password is what they lost; possession of the device is what they still have. Design around that and the majority of resets verify strongly and automatically. Design around knowledge questions and you’ve built a system that a determined caller with a LinkedIn account can defeat.

Sub-problem two: which procedure applies?

This is the one nobody anticipates, and it’s the one that generates the awkward client conversation.

“Reset a password” is not one procedure. It’s a family of procedures that varies by client, by user, and by circumstance:

• Some clients require approval from a named person before any credential change, full stop.
• Some require approval only for privileged accounts, and the definition of privileged is theirs, not yours.
• Some have regulatory obligations — a finance or healthcare client whose auditors expect documented authorization on every identity action.
• Some accounts are shared service accounts where a reset breaks an integration, and the correct answer is to refuse and escalate.
• Some users are disabled rather than locked, and a reset is the wrong action on an account that was deliberately turned off. As covered in Disabled Doesn’t Mean Gone, the reason an account is disabled almost never lives in a structured field.

An agent that treats all of these as the same operation will be right most of the time and catastrophically wrong occasionally, which is the worst available distribution. The failure won’t be a security breach — it’ll be resetting the credentials on a service account at 2am and taking down a client’s line-of-business integration, or bypassing an approval requirement that exists because of a regulator.

Execution is uniform. Policy is not. The policy has to be readable by the thing doing the executing.

Which means the prerequisite for automating password resets isn’t an identity integration. It’s having written down, per client, who may authorize a credential change and for which accounts. Most MSPs have never written that down for any client.

Sub-problem three: how does the credential reach the user?

The delivery problem is the most concrete and the most consistently underestimated.

You’ve verified the requester and confirmed the procedure. Now you have to get a new credential to a person who, by definition, cannot access their primary account. The obvious channels are all compromised or unsafe:

• Email to their work address. They can’t reach it. That’s the ticket.
• Email to a personal address on file. Now the corporate credential is sitting in a consumer mailbox with unknown security, and it’s in an inbox permanently.
• Reading it aloud on the call. No record, no expiry, transcribed into a call recording, and typically written on a sticky note within ten seconds.
• Putting it in the ticket. A plaintext credential in your PSA, visible to every technician, retained for the life of your data retention policy. This is common and it is genuinely bad.
• SMS. Better, if it goes to the number in the identity provider rather than a number supplied during the call, and if the credential is single-use and short-lived.

The framing that resolves this: stop delivering passwords.

The modern answer is to never transmit a credential at all. Issue a time-limited, single-use pass that allows the user to authenticate once and set their own password directly with the identity provider. Microsoft Entra’s Temporary Access Pass does exactly this; other providers have equivalents. The MSP never knows the password, never transmits it, and never stores it. The user’s new credential exists only between them and their identity provider.

That single design change eliminates the delivery problem, the storage problem, and the “who else saw this password” problem simultaneously. It also, not incidentally, makes the flow far easier to automate — because the risky artifact no longer exists.

This is why the trust question a thoughtful client asks isn’t can your AI reset passwords. It’s how are my credentials handled. An answer of “we don’t handle them” is the only one that fully satisfies. Any vendor whose automated reset flow ends with a password sitting in a ticket or an inbox has moved your risk around rather than reduced it.

Why it’s the right place to finish

Given all of that, the reasonable reaction is to move password reset down the roadmap. That’s correct, and it shouldn’t be read as don’t do it.

Password reset is the right capstone for automated resolution, for the same reason it’s the wrong opener. Solving it means you’ve built the three things every subsequent identity action requires: a verification ladder, machine-readable per-client authorization policy, and a credential handling model that doesn’t put secrets in transit.

Once those exist, the next use cases are comparatively cheap. Account unlock is the same flow minus the credential. MFA re-enrollment is the same verification with a higher evidence tier. License assignment reuses the authorization policy. Group membership changes reuse all three. You’re not building a password reset feature — you’re building the identity foundation, and password reset is just the first thing it’s strong enough to carry.

Teams that reverse this order end up with a password reset that works in the demo tenant and can’t be enabled in production, because every real client surfaces an approval requirement, a service account, or a compliance obligation the flow can’t express.

A defensible flow, end to end

What this looks like when it’s built properly:

1. Request arrives by phone, email, or portal, with the channel’s verification state recorded explicitly.
2. Account resolved in the client’s identity provider. The agent checks whether it’s a standard user, a privileged account, or a service account — and stops on the last two.
3. Client policy checked for authorization requirements on credential changes for this account class.
4. Verification stepped up to the tier the action requires, typically push approval to the enrolled device.
5. Authorization obtained if policy demands it, from the named approver, through a verified channel.
6. Temporary access pass issued rather than a password set. Time-limited, single-use.
7. Evidence logged on the ticket: verification method, tier achieved, approver if any, pass issuance, and the completion event.
8. Anything unmet escalates to a human with the collected evidence attached, so the technician starts from what’s known rather than from zero.

Step eight is the one that determines whether the whole thing is trustworthy. An agent that can gracefully decline and hand over is far more valuable than one that always completes.

That’s the bet Mizo made

Mizo’s Resolution Agent treats credential actions as policy-gated rather than capability-gated: the question isn’t whether it can call the API, it’s whether the evidence tier and client authorization policy permit it. Verification evidence is written to the ticket automatically, and unmet conditions escalate with context rather than failing silently.

We deliberately shipped this after triage, dispatch, diagnosis, and documentation — not because password reset is technically difficult, but because doing it defensibly requires the identity foundation underneath it, and shipping the easy version first would have been the fastest possible way to lose a client’s tenant.

Where to start on Monday

1. Pull last month’s password reset tickets and count them. That’s the prize, and it’s usually larger than people guess.
2. For your top five clients, write down who is authorized to approve a credential change, and for which account classes. If nobody knows, that’s the project.
3. Inventory your service accounts. Any automated reset flow needs to refuse them, which means it needs to recognize them.
4. Check whether your clients’ tenants support temporary access passes. Most Entra tenants do and have never enabled the feature.
5. Audit where passwords currently end up — tickets, emails, chat threads. Fix that before automating anything, because automation will do it faster and more consistently.

Built by a former MSP operator. If your reset procedure ends with a password in a ticket note, you don’t have a reset procedure — you have a data retention problem.