How Mizo Verifies End Users Before Any Account Change

An agent that can reset a password is only as trustworthy as its answer to one question: how does it know who’s asking? Caller ID isn’t authentication, and neither is a confident voice on the phone. Here’s what Mizo actually does instead, step by step.

The flow, in order

Request arrives. A ticket lands from phone, email, or portal. Before anything happens to an account, the agent resolves the requester against the contact record already on file in your PSA — not against whatever the requester just typed.

A challenge goes out — to the device or address already on record. Depending on what the client has deployed, that’s a Microsoft 365 / Entra MFA push, a Duo push, or — when no MFA provider is enrolled — a single-use, time-limited verification link. Every one of these goes to a channel that was registered before this request existed, never to a number or address supplied during the conversation. That distinction between “on record” and “provided now” is the entire point.

The requester confirms. An approval on an enrolled device, or a click on the link. Typically done in under thirty seconds, with no technician in the loop and no security questions asked — because knowledge-based questions are researchable, not provable.

The result is logged as evidence, not a note. Method, outcome, and timestamp get written to the ticket as structured fields. That’s what lets the Resolution Agent gate a sensitive action on the evidence actually collected, rather than trusting a technician’s memory of a phone call. Unverified requests escalate to a human with everything the agent gathered attached — the technician starts from what’s known, not from zero.

Locked out isn’t the same as unverifiable

The objection every verification design runs into: the user is locked out, that’s why they’re calling. Losing one factor doesn’t mean losing all of them. Someone who forgot their password almost always still has the phone their Authenticator app or Duo is enrolled on — the factor being checked and the factor they lost aren’t the same thing, so the push still goes through normally. It’s the most common case, not the exception.

Retry matters here too: an MFA push expires after roughly a minute, so a requester who’s slow to notice the notification needs a clean way to trigger another one rather than getting stuck.

Matched to the client’s stack, not a parallel system

Mizo doesn’t stand up its own identity system to check against. M365 shops get MFA push through Entra; Duo shops get verification through Duo, honoring whatever enrollment and policy already exists there. Clients with no MFA deployed yet fall back to the one-time link — which still beats caller ID or security questions, while making the gap visible rather than papering over it.

Where this starts, and where it’s headed

Today, the flow is mandatory ahead of the highest-stakes action on the desk: password resets. From there it extends to the other places a technician currently makes a judgment call — account unlocks, MFA re-enrollment, access grants — with the same design principle carried through: the strength of verification required should scale with the blast radius of the action, not with how convincing the caller sounds.

The audit trail is the point

“We verified the caller” isn’t evidence if it only exists in someone’s memory of a phone call. Because the method, device, and outcome are written to the ticket automatically, an MSP can show a client, an auditor, or a cyber insurer exactly what evidence was collected for a specific action at a specific time — which matters well beyond the moment the ticket closes. That’s the same principle behind why MSPs need observability and audit trails for their AI agents more broadly.

👉 See identity verification run against your own tenant. Book a demo.

FAQ

What happens if the requester can’t complete verification?

The request escalates to a human with what was claimed, what was attempted, and what failed — all attached. No identity action proceeds on an unverified request.

Does this work for a user locked out of their account?

Yes, and it’s the most common case. Losing a password doesn’t mean losing an enrolled device, so the MFA or Duo push still completes normally.

What if a client hasn’t deployed MFA at all?

They fall back to a single-use, time-limited verification link sent only to the address or number already on the contact record — no security questions, ever.

Where does the verification result get stored?

On the ticket itself, as structured fields — not a technician’s note — so downstream agents can gate actions on it and the MSP can produce it as evidence later.