Skip to main content

Identity Verification

Identity verification lets one person confirm, in real time, that another person is who they claim to be — most often a help desk agent and an employee, before a password reset, an access grant, or any other sensitive action.

It exists because a voice on a call proves nothing. An attacker who knows an employee's name, manager and start date can pass a knowledge-based check; they cannot produce a code from a device your organization issued to that employee.

How it works​

Each person taking part uses a sensor — a device registered to them and signed in with their corporate identity. There are three:

  • the browser extension, installed in Chrome
  • the iOS app, installed on their phone
  • the web app, a SlashID-hosted page reached through a link, for people who cannot install anything

Every sensor shows a six-digit code that changes every 30 seconds. Verification is the act of reading a code out and having the other side confirm it, which proves the speaker is holding a device that only that person should have.

The strongest form is mutual: both sides prove themselves to each other. That matters more than it first appears — help desk impersonation runs in both directions, and an employee has no way to know that the person who called them claiming to be IT support really is.

The verification methods​

Six methods exist. Which are available depends on your configuration; see Settings.

Person to person​

Applies toBrowser extensioniOS appWeb app

Two employees who each have a sensor verify each other. One starts it by entering the other's email address; both then see their own code and a field for the other's. Each reads their code out and types in what the other reads back.

There is no turn-taking: it is one screen, and either person can go first.

Nobody can verify themselves — the person you name has to be someone else.

Success looks like: both sides show the verification as complete.

Help desk, one-way​

Applies toSlashID Console

What happens when mutual help desk verification is switched off. The agent opens the caller's row in the Console and types in the code the caller reads out.

danger

Only the caller proves who they are. The agent proves nothing, so the caller has no protection against someone impersonating your help desk. Turning on mutual verification closes that gap — see Settings.

Success looks like: the Console confirms the code was correct.

Help desk, mutual​

Applies toSlashID Console

A real session between the agent and the caller's device, lasting two minutes. The agent has no sensor of their own; SlashID generates a code for them for the duration of the session.

It runs as two steps, in an order your organization sets:

  • End user goes first — the caller reads their code to the agent, then the agent reads theirs back.
  • Helpdesk goes first — the agent proves themselves before asking the caller for anything. Useful when your policy is that support staff identify themselves first.

Success looks like: both steps complete inside the two-minute window. One step alone leaves the session partially complete, which is not a verification.

Delegated, using a device​

Applies toSlashID Console

For someone who has no device of their own. Instead of verifying them directly, the agent runs a mutual verification with a stand-in who vouches for them. When it completes, the person being vouched for is recorded as verified.

Who may act as a stand-in is set by your organization, and any combination of these can be allowed:

  • Approved delegates list — a fixed set of email addresses.
  • Line manager — resolved from your HR data.
  • Any eligible user — the agent picks from the people who have a device.

The stand-in cannot be the person being verified, and the agent cannot nominate themselves.

Success looks like: the session completes, and the person being vouched for shows as verified even though they took no part.

Email code to the person​

Applies toSlashID Console

A one-time code sent to the person's own email address. They read it back and the agent types it in. No device is involved.

The Console shows the recipient address masked, so the agent can confirm it looks right without seeing it in full.

Success looks like: the code is accepted before it expires.

note

This method proves control of a mailbox, not possession of a device your organization issued. It is the weakest of the six and is intended as a fallback.

Email code to a stand-in​

Applies toSlashID Console

The same, except the code goes to someone vouching for the person. The Console offers recipients in a deliberate order — their line manager first, then an approved delegate, and the person themselves only as a last resort.

Success looks like: as above, with the record showing who vouched.

In this section​

  • Entra setup — register a SlashID application in Microsoft Entra ID so your users can sign in from a sensor, and enter the resulting credentials in the SlashID Console.
  • Troubleshooting — every state a sensor can be in and what to do about it, what each verification method looks like from both sides, and what each setting decides. Written for help desk agents handling a call and for the admins who configure them.

Installing the sensors themselves is covered under Browser Extension.