Verification is straightforward in a portal. The user is already authenticated, the session carries proof, and stepping up to a second factor is a button.
On a phone call, every one of those assumptions is gone. There’s no session. There’s no authenticated context. There’s a stranger’s voice, a channel you don’t control, and — the constraint that breaks most designs — a human being listening to silence while you figure it out.
The phone is simultaneously the weakest identity channel and the one where resolution has the most value, because the person is right there and wants it fixed now. Getting verification right on a live call is the specific engineering problem standing between “AI answers your phone” and “AI resolves your ticket.”
Here’s how to build it.
The dead air constraint
Start with the thing that isn’t about security at all.
A portal flow can take forty seconds to complete a verification round trip and nobody notices. On a call, four seconds of silence feels like a dropped connection and the caller says “hello? are you still there?” Ten seconds and they hang up.
This constraint shapes everything. It means verification on a call has to be narrated, and the narration has to be honest about what’s happening:
“I’m sending an approval request to your phone now — you should see it in a few seconds. Let me know when it comes through.”
That sentence does three jobs. It sets expectations, it converts dead air into a shared wait, and it hands the caller a task, which stops them from filling the silence. It is not a UX nicety. A verification flow that’s technically sound and conversationally silent will get abandoned before it completes, and abandoned verifications become human escalations, which was the thing you were trying to avoid.
The corollary: anything that takes longer than about fifteen seconds needs a different pattern, usually a callback rather than a hold.
Push approval is the workhorse
For most calls, the right primary method is a push approval to the device already enrolled against the caller’s identity.
It fits the channel almost perfectly. It’s fast enough to complete inside a conversation. It requires no reading of codes over the phone. It proves possession of an enrolled device rather than knowledge of researchable facts. And critically, it works during a lockout, because the factor the user lost — their password — is not the factor being checked.
Two implementation details that matter more than they look:
- Send to the enrolled device, never to a number the caller provides. If the caller can nominate the destination, you’ve built a verification system that verifies whoever is on the phone. This sounds obvious and it is the single most common way these flows are subtly broken.
- Never read the approval number out loud. Number-matching push exists to defeat approval-fatigue attacks — the user reads the number from your screen context and enters it on their device. If your agent speaks the number, an attacker who has triggered a push on the real user’s device now has the number they need. The caller reads it to you, not the other way round.
When push isn’t available
A meaningful minority of calls can’t complete a push. The user has a new phone, hasn’t enrolled, is somewhere without data, or the client never deployed MFA. The design question is what happens next, and the wrong answer — the one nearly every human service desk uses — is to fall back to knowledge questions.
Better fallbacks, in order:
Callback to the number of record. Take the request, end the call, and call back the number in the identity provider or PSA. It’s slow, it’s unglamorous, and it’s genuinely strong, because it moves the conversation onto a channel the attacker doesn’t control. For high-risk actions it’s often the correct answer even when push is available. Automate it: the agent schedules and places the callback rather than queuing a human to remember.
One-time code to the registered mobile. Weaker than push and still decent, provided the number comes from the identity provider record rather than the conversation. Keep the code short-lived and single-use.
Approver attestation. Route to the client’s designated approver, who confirms through an already-verified channel. Slower, and the strongest option when the requester genuinely has no factors. This doubles as the authorization step for actions that need one.
Human escalation with evidence attached. The floor, and it should be a real floor rather than a failure. The agent hands the technician everything it collected — what was claimed, what was checked, what failed — so the human starts from a position of knowledge.
What shouldn’t be in that list: employee ID, date of birth, manager’s name, last four of anything, or details from recent tickets. These feel like verification and function as a research checklist. If your fallback is knowledge-based, your fallback is the attack path.
Failing without teaching
A subtle point that separates thoughtful implementations from naive ones.
When verification fails, the agent’s response should not explain what specifically went wrong. “That code was incorrect” is fine. “There’s no mobile number registered for that account” tells a caller probing your system exactly which accounts are soft targets. “That user is disabled” confirms an employee’s status to someone who shouldn’t have it.
The pattern is a generic outcome and a consistent next step: verification couldn’t be completed, here’s the path to a human. Same message regardless of the underlying reason. Log the real reason internally where your team can see it.
Two related controls worth building in from the start:
- Rate limit by identity, not by call. Three failed verification attempts against the same account in a short window is a signal, whether it came from one call or six. Flag it and route to a human who knows why.
- Timing consistency. If a lookup that finds no account returns instantly while a real account takes two seconds, you’ve built a way to enumerate valid accounts. Normalize the response time.
Neither of these is exotic. Both are routinely missing.
Record what you checked, on the ticket
Every verification attempt should write structured evidence to the ticket at the moment it happens: the method attempted, the outcome, the evidence tier achieved, the identifiers involved, and the timestamp. Not prose in a note — fields that downstream automation can read and an auditor can review.
This matters for three separate reasons.
The downstream agents need it. A resolution agent deciding whether it may act needs to know the caller reached tier one via push approval, not that a note says “verified.” Free text is not a gate.
Your audit posture needs it. After an incident, “the technician verified the caller” is not a defensible statement. “Push approval completed against enrolled device ending 4471 at 14:22:08” is.
And your tuning needs it. The distribution of which verification methods succeed and fail, per client, tells you exactly where to invest — usually that one client’s enrollment coverage is terrible and it’s generating a third of your escalations.
The volume argument
The reason to build all this is not compliance theater. It’s that verification is the throttle on how much of your phone volume can resolve without a human.
Work it through. If the only verification your voice agent can perform is caller ID matching, then every action that touches credentials, access, or spend has to escalate — which is most of the reason people call a service desk. Your voice agent becomes a very sophisticated intake form. Real, but limited.
If the agent can complete strong verification during the call, the set of tickets it can carry to completion expands dramatically: password resets, account unlocks, group membership, license assignment, mailbox permissions. The same call, the same caller, no callback, no queue.
Verification isn’t the tax you pay for automated resolution. It’s the mechanism that makes automated resolution possible at all — and it’s why a voice agent’s identity design tells you more about its ceiling than its voice quality does.
That’s the bet Mizo made
Mizo’s Phone Agent runs step-up verification inside the call: narrated push approval against the enrolled device, callback and approver-attestation fallbacks when it isn’t available, generic failure messaging, and structured verification evidence written to the ticket rather than described in a note.
That evidence is what lets the Resolution Agent act on a phone-originated ticket at all. The two are designed as one path, because a verification result that can’t be read by the system deciding whether to act is a conversation, not a control.
Where to start on Monday
- Call your own service desk and ask for a password reset. Write down exactly what you were asked. Score it against the ladder in Caller ID Is Not Authentication.
- Check MFA enrollment coverage per client. The clients with poor coverage are the ones where voice automation will escalate constantly, and that’s a client conversation, not a product gap.
- Confirm your identity provider supports number-matching push, and that nobody in your process reads the number aloud.
- Write your failure message once, generically, and make every failure path use it.
- Decide today where verification evidence gets stored on a ticket. Structured fields, not notes — you’ll regret the notes.
Built by a former MSP operator. If your verification questions could be answered from a LinkedIn profile, they aren’t verification questions.