Verifying a caller

Identity Verification lets you prove who is on the phone before you act on what they ask for. You start a verification from a panel on the call and ticket screens, or from a card in the browser extension, and the caller finishes it on their own device. This page covers what you do as the technician, what the caller sees and what each result means.

Before you start: the Identity Verification module is on for your organisation, the caller's client has identity verification turned on, and you are signed in so that the screen can tell who is starting the verification. What that takes depends on where you start it:

• On Taking a call, sign in with an account that can open that screen: Administrator, Service Desk Manager, Dispatcher or Technician.
• On the dashboards embedded in HaloPSA, sign in to the embed.
• In the browser extension, and on the override and credential forms, sign in as an Administrator, Identity Verification Admin, Service Desk Manager, Dispatcher or Technician.

White-label partner accounts cannot start verifications.

Find the verification controls

The controls appear when the call or ticket names a caller with an e-mail address and the caller's client has identity verification on. When the client has it off, the screen says Identity verification off for this client. Clients and per-client policy explains how a client's method and assurance level are set.

The panel records who started each verification, so it needs to know who you are. On the call screen, if the screen cannot tell who you are, it shows Verify identity unavailable in place of the panel. On the dashboards embedded in HaloPSA the same situation shows Verify identity: sign in to this embed. Hover over either message to see the reason.

Verify a caller from the panel

1. Select Verify ID. The Identity Verification dialog opens. At the top it shows who you are being asked to prove: the caller's name, e-mail address and ticket number, and a photo when the directory has one. Check that this is the person the ticket names.
2. Wait while the panel checks what the caller can be verified with.
3. Select Verify Identity. The panel uses the method the client's policy picks, so you do not choose a method in the normal case.
4. Follow the steps for the method in Verify with Microsoft Entra Verified ID or Verify with Authenticator step-up.
5. Read the result in Read the result.

Closing the dialog does not cancel a live request. The caller may be partway through signing in, and you can reopen the dialog to the same state.

Each client has an assurance floor of Basic, Substantial or High. The default is Substantial. A method that cannot reach the floor is never used: the panel refuses it instead of quietly lowering the bar.

Two notices can appear before you start:

• A recency warning: This caller's authentication method was registered very recently. A newly enrolled Authenticator is the usual next step after an account takeover, so confirm through another channel before you act.
• A registration notice: The Microsoft registration report shows no Authenticator for this caller. Treat it as advice, not a verdict. The report can be up to 36 hours out of date in both directions, and the panel prints its age (Microsoft registration data as of and a date) so you can weigh it.

Choose a different method

Verify a different way appears only when more than one method can reach the client's assurance floor.

1. Select Verify a different way. The panel lists the methods, strongest first, each tagged with the highest assurance it reaches, for example up to High.
2. Select Use this method on the one you want.

The list only offers methods that meet the floor, so you can raise assurance but never lower it. Methods that cannot be used are listed with the reason, for example This method can only reach Basic assurance, and this client requires Substantial. The most common reason for a newly added client is that their Microsoft administrator has not given consent yet. You cannot fix that from the panel: an Identity Verification administrator sends the consent link from the setup guide, described in Setting up identity verification.

Verify with Microsoft Entra Verified ID

The caller needs a credential issued to them in advance. See Issuing credentials and supervised overrides if they have none.

1. After you select Verify Identity, the panel shows a QR code.
2. Ask the caller to scan it with Microsoft Entra Verified ID in their Microsoft Authenticator wallet.
3. Watch the status line. It reads Waiting for the caller to respond. and changes to The caller has opened the request. Waiting for them to approve it.
4. If the caller cannot scan the code, select Copy link and send them the link. Forwarding it to anyone else proves nothing, because the check is bound to the credential in the caller's own wallet.

The panel shows when the request expires (Expires at and a time). Select Cancel verification to close it early.

Verify with Authenticator step-up

Authenticator step-up is available when it is enabled for your organisation. The caller signs in on their own phone and approves the sign-in in Microsoft Authenticator. SMS is not available.

1. After you select Verify Identity, the panel sends a sign-in link to the caller's e-mail address on file in the directory. It tells you where the link went, for example Sent to the address on file, ending …@contoso.com.
2. Ask the caller to check their e-mail and open the link on their phone. What the caller sees describes the message.
3. Wait. The panel reads Waiting for the caller to complete the sign-in on their own phone. and changes to The caller has opened the sign-in. Waiting for them to finish it.
4. If the message did not arrive, select Send it again. It re-sends the same link to the same address. You cannot send it anywhere else.

The panel never shows you the link, on purpose. A link you can read is a link you can be talked into forwarding: a social engineer could pass it to the real account holder, who signs in, and the attacker's session would be the one marked verified.

The panel repeats the safety rule in a red notice: The prompt appears only on the caller's phone. Never read a number to the caller, and never tell the caller what to approve. Do not describe what the prompt will look like either. What the caller sees depends on their phone and how they opened the link.

Read the result

Only the first two rows are proof. Everything else, including an override, is a call you are taking without it.

The reason under Not verified is one of these:

• The credential the caller presented was revoked or is not valid.
• The client requires an active Verified ID credential and the caller has none.
• The caller finished the sign-in without multi-factor authentication, or reused an older sign-in instead of signing in again.
• The sign-in link had already been used, had expired, or was replaced by a newer request.
• No e-mail address or mobile number for the caller is on file in the directory, or the message could not be delivered, so nothing was sent to the caller. The panel tells you to use your out-of-band identification procedure.
• Authenticator verification is not fully set up for your organisation. Tell an Identity Verification administrator.

Select Try again after a failure to start over. The panel checks the available methods again, which helps when something changed during the call, such as a client giving consent.

The Verify ID button changes with the state of the verification: Verified, Verifying..., Waiting..., Wrong account, Declined, Not verified, Expired, Cancelled, Override and Unavailable. Next to it the screen keeps a line, Caller verified with a time or Caller NOT verified, until you leave or reload the screen. The validity badge, described below, survives a reload.

Cancel a verification or start another

• Select Cancel verification to close a live request. Only the technician who started it can cancel it, and only while it is live. If the server does not accept the cancellation the panel says so.
• Starting a new Authenticator step-up for the same caller cancels the earlier live one, so a caller never has two live links.

Know the limits on starting verifications

Authenticator step-up has hourly limits so that nobody can use it to flood a person's phone. In any rolling hour the defaults are 5 prompts to one caller, 20 started by one technician and 200 across your organisation. When a limit is reached the panel refuses the start and says which one. Do not keep retrying. Use your out-of-band identification procedure, or record a supervised override if you have to proceed. A sandbox rehearsal does not use up anyone's allowance.

The panel can also refuse a start because the caller could not be matched to a single directory account, so there is nothing to bind a verification to. Confirm the contact on the ticket, then use your out-of-band procedure. If your session has no verified technician identity, sign in and try again.

Check how long a verification counts

Beside the panel, a small badge answers a question the panel cannot: has this caller already been verified, and does that still count? It appears once the caller has a successful verification on record.

• It reads Verified by and the technician's name, then counts down the time left. The countdown ticks while you work and survives a page reload.
• It goes green, then amber when less than 40 percent of the window is left, then red. When the time is up it reads Last verified, a time and the technician's name, followed by re-verify before acting.
• It always says what the verification was for. If it was for another ticket, or for no ticket, the badge says does not cover this one. A colleague's pass on a different ticket is not a verification of your call.
• The window is at most five minutes, and shorter when the client's Verification Validity (Minutes) is set below that. It exists so that a caller who is still on the line is not prompted twice.

Starting a verification again on the same ticket, as the same technician, inside the window shows Carried over from an earlier verification instead of prompting the caller again. A different ticket or a different technician always starts a fresh challenge.

The badge only displays. Nothing on it starts or extends a verification. Rehearsals from the sandbox never appear on it.

What the caller sees with Authenticator step-up

The caller needs no QuantumOps account. Step-up e-mail goes out only after TechPulse has set up a sending domain for your instance. Until then the panel shows Not verified with a reason and nothing is sent, so use your out-of-band procedure.

1. The caller receives an e-mail with the subject Confirm your identity for your IT support request. The sender name is the brand name set for your organisation, or for the white-label partner when the caller belongs to one. When no brand name is set it is IT Support. The first line names the sender and the ticket, for example IT Support • Ticket #4821.
2. The e-mail says someone contacted IT support and asks the caller to open the link on their phone and sign in. They approve the sign-in in Microsoft Authenticator.
3. The link works once and expires in about three minutes by default.
4. The caller sees a plain page titled Identity check. It says Thanks — your identity has been confirmed. You can close this window. when it worked. Otherwise it says This link has expired or has already been used., The sign-in was not completed. or We could not confirm your identity from this sign-in.

The page never says why a sign-in failed. In particular it does not tell the person which account the desk expected. The e-mail also tells anyone who did not contact IT support not to open the link, not to approve any prompt and to report it to their IT team.

Verify from the browser extension

The Caller verification section on the Ticket tab, the User tab and the Call tab does the same job as the panel, with the same roles and the same assurance rules. The section is hidden when caller verification is not enabled for the extension on your instance, or when your account is not one of the roles that can start verifications. When the Identity Verification module is off, not yet set up, or off for the caller's client, the section stays collapsed and shows the reason instead of a Verify caller button. The browser extension page covers installing and signing in.

1. Open Caller verification. A tag at the top shows Verified or Not verified. The rows underneath show Caller, Email, Last verified (who, how long ago and on which ticket), Assurance and Valid until.
2. Select Verify caller. The card shows Assurance floor for this client: and lists the methods, each with the assurance it reaches. The methods are named VerifiedId for Microsoft Entra Verified ID and AuthenticatorPush for Authenticator step-up.
3. Check the tags on each method. Below the floor. means it cannot reach the client's floor, and the server does not accept a choice that would verify below it. Used recently. means the same method was used recently for this caller, and the card warns This method was used recently for this caller. Consider a stronger one. Unavailable methods are greyed out with the reason.
4. Select Send challenge, then confirm with Send. The confirmation lists what will happen, including the ticket the request is recorded against.
5. Watch the tag at the top. It shows the live state: waiting, opened, verified, failed, cancelled, expired, denied, mismatch or override. Read mismatch as a different account answering and denied as the caller declining, as in the table above.

For Verified ID the card shows the QR code, the link as text you can read out or copy, and when the request expires. For step-up it shows Challenge sent to and the masked address, and never the link. While a request is live you can select Resend or Cancel, and each asks you to confirm first. Only the technician who started a request can cancel it. When it has finished, select Start another. History lists the earlier requests for this ticket or caller. A request in progress survives a reload of the side panel.

The card does not repeat the safety rule from the panel, but it applies in the same way: never read a number to the caller and never tell them what to approve.

When nothing can verify the caller

Sometimes there is nothing to offer: the client's Microsoft administrator has not consented, the caller has no authenticator registered, or no method reaches the floor. The supervised override is the recorded way through. It needs a written reason and a named second approver, and it is logged as an override, never as a pass.

• In the panel, Record a supervised override appears when no method is available, the request expired, the start was refused or the verification failed. It does not appear after The caller declined the prompt, Verification cancelled or Not verified — a different account answered. Those are signs to treat the call as unverified, not reasons to proceed.
• In the extension, Record a supervised override appears after any finished result other than a pass or an override, and after a start the server refused. That includes results for which the panel does not offer it, so the same rule applies: do not record an override after the caller declined the prompt, after a different account answered, or after you cancelled a verification because you were suspicious.

Both open the override form in a new tab, with the client, ticket and caller already filled in. Issuing credentials and supervised overrides walks through the form and explains when to refuse the request instead.

Related

• Issuing credentials and supervised overrides covers the override form and issuing a credential during a call.
• Taking a call describes the call screen where the panel sits.
• Ticket tab and Call tab cover the extension tabs that show the card.
• Clients and per-client policy explains why a client offers the methods it does.
• Identity verification is the overview of the two modes and the assurance floor.