Follow any automated resolution use case to the point where it actually changes something, and you arrive at the same question.
Password reset: is this the account owner? License assignment: is this person authorized to spend? Mailbox permission grant: who approved delegated access to the CFO’s mail? Group membership, MFA re-enrollment, account unlock, distribution list changes — every one of them terminates at is this person who they claim to be, and are they allowed to ask for this.
That question is the gate. Everything upstream of it — classification, prioritization, routing, diagnosis, documentation retrieval — is comparatively easy, and it’s where the entire industry has concentrated, because it’s the part you can automate without ever answering the hard question.
The reason most MSPs are still doing triage automation in 2026 rather than resolution automation isn’t model capability. It’s that identity verification was never solved at the service desk, and automation makes an unsolved problem impossible to keep ignoring.
What the service desk has been doing instead
Here is the verification procedure at a large share of MSPs, stated honestly:
The caller’s number matches a contact in the PSA. They know the name of their company. They sound reasonable, and they sound annoyed. The technician resets the password.
Nobody wrote that procedure down, and if you asked the technician they’d tell you they verify identity. What they mean is that they formed a judgment from a set of weak signals: familiarity, plausibility, tone, context. Sometimes the technician genuinely knows the caller’s voice, and at a small MSP serving twenty clients that’s a real control. At an MSP serving two hundred clients with forty rotating technicians, it isn’t a control at all. It’s a habit that scales badly and fails silently.
The weak signals in that stack, in descending order of how much they’re trusted versus how much they’re worth:
- Caller ID. Trusted most, worth least. Caller ID is routing metadata, not an authentication factor, and it is straightforwardly forgeable. Every telecom fraud advisory of the last decade says the same thing. It tells you which number the call claims to come from — a claim the caller controls.
- Knowledge of the company and colleagues’ names. Available on LinkedIn and your client’s own website.
- Email address in the from-field. Meaningful only if the mailbox itself is uncompromised, which is precisely what’s in question when someone reports being locked out.
- Sounding legitimate. Not a control. Confidence is the one thing a social engineer reliably has.
None of these are useless as signals. All of them are inadequate as gates. The distinction matters enormously once software is making the decision.
Why the MSP help desk is the target
It’s worth being clear-eyed about the threat model, because it explains why this stopped being a theoretical concern.
Attackers moved to the help desk because it’s the cheapest path through an otherwise well-defended environment. An organization can deploy MFA everywhere, enforce conditional access, and buy every endpoint tool on the market — and still be compromised by a phone call to the people whose job is to help locked-out users regain access. The service desk exists to remove access barriers. That’s the function, and it’s the vulnerability.
Several of the most consequential breaches of recent years began exactly this way: a convincing caller, a help desk technician following a verification procedure built for a lower-threat era, and credential or MFA reset granted to the wrong person. The technique isn’t sophisticated. It doesn’t need to be.
For an MSP, the exposure multiplies. Your help desk holds privileged access into every client tenant you manage. One successful pretext doesn’t compromise one company — it potentially compromises whichever of your clients the attacker chose, and it does so through a path your client’s own security investments can’t see. You are the shared identity boundary for every business you serve, and your verification procedure is the wall.
This is also why “we’ll tighten verification later, once automation is working” is exactly backwards. Automation applies your procedure consistently, at volume, without the human intuition that has been quietly compensating for the procedure’s weakness. If the procedure is weak, automating it industrializes the weakness.
The verification ladder
The way out is to stop treating verification as binary and start treating it as evidence of varying strength, matched to actions of varying risk.
Ranked from strongest to weakest:
- Cryptographic proof from an enrolled device. A push approval or passkey assertion against a device already registered to the identity. The user proves possession of something bound to their account. This is real authentication and it belongs at the top.
- A one-time credential delivered out of band to a pre-registered channel. A code to the mobile number on record in the identity provider — not the number the caller is calling from, and not a number they supply during the call. The distinction between on record and provided now is the entire security value.
- Callback to the number of record. Hang up and call the number in the directory. Ancient, low-tech, and genuinely effective, because it moves the channel from one the attacker chose to one you chose.
- Attestation by a verified third party. The client’s designated approver — office manager, IT champion, direct manager — confirms the request through a channel you’ve already verified. Strong for authorization, and useful for identity when the approver personally knows the requester.
- Corroborating account signals. Recent sign-in from a known device or location, an open ticket describing the issue, a matching alert from the RMM. Supporting evidence, never sufficient alone.
- Shared knowledge. Employee ID, a detail from a recent ticket, information from the client’s HR record. Better than nothing and vulnerable to research.
- Caller ID and plausibility. Context, not verification.
The design rule follows directly: the strength of verification required should be a function of the blast radius of the action, not the confidence of the requester.
Reading a ticket status needs nothing. Creating a ticket needs almost nothing. Resetting a standard user’s password needs tier 1, 2, or 3. Resetting an administrator’s password, re-enrolling MFA, or granting mailbox delegation needs tier 1 plus explicit authorization from someone other than the requester. Bulk anything escalates to a human by design.
Notice that this ladder makes some tickets more automatable, not less. A user who can complete a push approval on their enrolled device has authenticated more strongly than any conversation with a technician could achieve. The automated path is the secure path — which is the argument that turns identity verification from an obstacle into the thing that makes resolution automation defensible.
The lockout paradox, and how to get around it
The obvious objection: the user is locked out. That’s why they’re calling. Half the ladder assumes access to an account they can’t reach.
This is real, and it’s where most verification designs collapse into “just ask them some questions.” The way through is to recognize that being locked out of one factor is not the same as having no provable relationship to the identity.
- Account lockout is not device loss. A user who forgot their password usually still has their enrolled phone. Push approval works fine — the factor they lost and the factor you’re checking are different.
- A temporary access pass is a designed answer to exactly this. Microsoft Entra supports issuing a time-limited, single-use credential that lets a user re-establish their own authentication. It converts “reset their password for them” into “let them prove possession and reset it themselves,” which is both more secure and more automatable.
- The out-of-band channel doesn’t have to be the broken one. SMS or a voice call to the number on record works when the mailbox is inaccessible.
- When someone has genuinely lost everything — new phone, no access, travelling — that’s the case that should reach a human, with third-party attestation. It’s a small fraction of volume and it’s the fraction where judgment earns its keep.
The mistake is designing your whole verification flow around the hardest 5% and then applying that weak, human-judgment-dependent flow to the other 95%.
What this means for automation sequencing
A practical consequence worth stating plainly.
Read-only automation — triage, classification, diagnosis, documentation retrieval, drafting a resolution for a human to execute — does not need identity infrastructure. Deploy it now. The worst case is a bad suggestion.
Write automation against identity systems needs the ladder in place first. Not “on the roadmap.” In place, tested, with an audit trail that records which tier of evidence was collected for every action taken.
That ordering is why we held our own resolution agent behind a flag rather than shipping it on the strength of a working password-reset API call. Getting M365 to reset a password is trivially easy. Knowing you should is the product. An agent that can execute identity actions but can’t prove why it believed the requester is not a feature — it’s an unaudited privileged account with a friendly interface.
FAQ
Isn’t caller ID matching good enough for low-risk tickets?
For non-privileged actions, yes — creating a ticket, checking status, logging a request. Caller ID is a reasonable convenience signal there. It should never be the sole basis for an action that changes access, credentials, or spend.
Doesn’t strong verification slow down the service desk?
It’s faster in the automated path than the manual one. A push approval resolves in seconds; a technician’s improvised verification conversation takes minutes and produces a weaker result. The friction people fear comes from bolting verification onto a human workflow, not from designing it into an automated one.
What if the client refuses to enforce MFA?
Then their tickets stay on the human path with third-party attestation, and you should be explicit with them that this is a security decision they’ve made, documented in writing. Some clients will accept the risk. The important thing is that it’s a recorded exception rather than an invisible default.
How do we prove we verified someone?
Log the evidence tier, the method, and the identifiers involved on the ticket itself — automatically, at the moment of the action. If your verification exists only in a technician’s memory of the call, you cannot demonstrate it to an auditor, an insurer, or a client after an incident.
That’s the bet Mizo made
Mizo’s Phone Agent treats caller ID as context and flags every ticket with whether the caller was verified and how — because a downstream agent needs to know the difference between an unverified claim and a confirmed identity. The Resolution Agent gates identity actions on the evidence tier collected, records that evidence on the ticket, and escalates to a human when the required tier can’t be met.
We shipped triage, dispatch, and diagnosis long before we shipped identity actions. That wasn’t caution for its own sake. It’s that the hard part of automated resolution was never the execution — it was earning the right to execute.
Where to start on Monday
- Write down your current verification procedure, exactly as your technicians actually perform it. Not the policy — the practice. The gap between the two is your exposure.
- List every action your service desk takes that changes credentials, access, or MFA state. That’s your privileged action inventory.
- Map each action to a required evidence tier using the ladder above. Most MSPs discover their highest-risk actions have their weakest gates.
- Check what your clients’ identity providers already support — push approval, temporary access passes, verified phone on record. Most of the ladder is available and unused.
- Start logging verification evidence on tickets now, before you automate anything. You’ll need the audit trail regardless, and building the habit while humans do the work makes the automated version straightforward.
Built by a former MSP operator. The scariest sentence in this business is “he sounded like he knew what he was talking about.”