Issuing credentials and supervised overrides

Two small forms support a verification during a call. Issue Credential enrols a caller in Microsoft Entra Verified ID so that you can verify them. Proceed without verification records a decision to go ahead when nothing can verify the caller. Technicians can use both, unlike the administrator-only screens of Identity Verification.

Before you start: the Identity Verification module is on for your organisation and you are signed in as an Administrator, Identity Verification Admin, Service Desk Manager, Dispatcher or Technician. White-label partner accounts cannot open either form. Each form also answers at the same path under /admin, /settings/verifiedid and /admin/verifiedid.

Issue a credential

Use this when the client verifies callers with Microsoft Entra Verified ID and the caller has never been enrolled. Enrolling callers one at a time during live calls is slow, so treat it as the fallback. Issuance campaigns enrol callers in advance and in bulk. A client that only uses Authenticator step-up needs no credentials, so this form is not for them.

1. Open /settings/identity-verification/issue in a new browser tab. The address can carry ?client= and &email= with their values to start with those two fields filled in.
2. Enter the Client ID, the identifier of the client organisation the caller belongs to. It is required. No technician screen shows it. An Identity Verification administrator can read it: on the Client Onboarding screen, select Configure for the client, and the address of the page that opens ends with the client's identifier. The administrator can also open this form for you with the client and the caller's e-mail address already filled in, by adding ?client= and &email= with their values to the address. Clients and per-client policy describes the screen.
3. Enter the User Email of the caller. It is required.
4. Optionally enter a Display Name. It appears on the credential card.
5. Select Issue Credential. The button reads Issuing... while it works.
6. In the Issuance QR Code card, ask the caller to scan the QR code with Microsoft Authenticator. The card confirms that credential issuance has started.
7. If the caller cannot scan the code, select Copy Link and send them the link, or select Open in Browser to open the link yourself.

If something is wrong, a red message appears under the button, for example that the Client ID is not valid, User email is required., or the reason the service could not create the request. The Help button starts a guided tour of the form.

Once the caller has scanned the code and their wallet has stored the credential, it is listed on the Credentials tab described in Credentials and the verification log. You can then start a Verified ID verification from the panel as described in Verifying a caller.

When you are done, close the tab. The arrow at the top of the form opens the Identity Verification screen, which only administrators can open.

Know when an override is appropriate

An override records a decision. It does not verify anyone, and it does not make a risky request safe. Use your out-of-band identification procedure first. Record an override only when:

• nothing can verify the caller, for example no method reaches the client's assurance floor, the client's Microsoft administrator has not consented yet, the caller has no authenticator registered, or the request expired and a new one would not help; and
• you have to proceed on this call; and
• a second person agrees that you should.

Refuse the request instead when the caller declined the prompt, when a different account answered the challenge, or when you cancelled a verification because you were suspicious. The verification panel does not offer the override after those results, because proceeding would turn the override into the attacker's way through. If you would not carry out the request for a caller you could not verify, refuse it.

Record a supervised override

1. Select Record a supervised override in the verification panel or in the extension's Caller verification card. Verifying a caller says when each one offers it. The form opens in a new tab with the client, ticket and caller already filled in. Open it from the panel or the card, not by typing the address, because without that context the form cannot record anything.
2. Check the details at the top: Client, Caller claims to be, Ticket and Requesting technician. A Failed attempt reference appears when the override follows a verification that did not complete.
3. Under Why can this caller not be verified?, write what was tried, what failed and why proceeding is the right call. The counter shows the characters you have written against the minimum of 10. Write what you would want to read if this call turns out to have been an attacker.
4. Under Who approved it?, select the approver. The list names the agents whose Agent role is SDM Primary or SDM Secondary when your instance has any, and never includes you. Otherwise it lists the other active technicians. You set the Agent role in Team Management under Edit details (see Inviting people, roles and agent links).
5. Tick the confirmation: I confirm the approver named above reviewed this call with me and approved proceeding without verification.
6. Select Record supervised override. The button stays disabled until the reason is long enough, an approver is selected and the confirmation is ticked.
7. The page shows Override recorded, with the chain position, how many overrides you have used in the current window, and a Reference you can quote if you need to escalate. The caller was not verified.

Select Cancel to leave without recording anything. The tab closes, or shows Nothing was recorded if your browser does not allow it.

What the record says

• It is an override, never a pass. The log shows it as Override granted, and no screen shows the caller as verified. Reports count overrides apart from passes.
• The approver does not sign in. The record is your attestation that the named person approved, not their signature. Naming someone who did not approve is a false statement in a tamper-evident record, made under your own sign-in.
• It sits in the same tamper-evident log as real verifications. The verification log lists each override as Override granted with its time, caller and ticket. The CSV export adds the technician and the recorded statement, which holds the reason and the approver.
• The form does not write to the ticket. Add your own note to the HaloPSA ticket so that the next technician can see what was agreed.

Stay inside the limit

Each technician can record 3 overrides in any 24 hours by default. The confirmation shows how many you have used, for example This is 1 of 3 allowed in the current window. When you reach the limit the form refuses the next one with Override limit reached — escalate instead and says how many you have recorded. Escalate to a manager instead of recording another.

When the form will not record

Related

• Verifying a caller explains the panel, the extension card and what each result means.
• Credentials and the verification log shows issued credentials and every recorded override.
• Issuance campaigns enrol callers before they call.