Agent verification: proving your help desk is really your help desk

Agent verification reverses the usual direction of a help desk identity check. Rather than the agent confirming that the employee on the line is genuine, the employee confirms that the agent is genuine, before sharing a code, approving a prompt, or installing anything. It exists because attackers work both directions of that call, and most organizations have a control for only one.

CISA documents both directions. Most controls cover one.

The federal advisory on Scattered Spider is specific about the inbound direction, and the wording is worth reading rather than paraphrasing. According to public reporting, the group has:

“Posed as company IT and/or helpdesk staff using phone calls or SMS messages to obtain credentials from employees and gain access to the network.”

“Posed as company IT and/or helpdesk staff to direct employees to run commercial remote access tools enabling initial access.”

“Posed as IT staff to convince employees to share their one-time password (OTP), an MFA authentication code.”

CISA, advisory AA23-320A

The same advisory, updated in July 2025, documents the opposite direction as well: posing as employees to convince help desk staff to reset a password and transfer MFA to a device the attacker controls. MITRE tracks the technique as Impersonation (T1656).

So the attack is symmetrical, while the investment has been almost entirely one-sided. Organizations have spent a decade hardening the question is this caller really our employee and have left is this caller really our IT department to a line in an awareness deck.

The advisory also notes the supporting infrastructure: registered domains such as targetsname-helpdesk[.]com and targetsname-sso[.]com, where the organization’s own name is appended with -helpdesk or an SSO product name to add credibility. The impersonation is prepared well in advance.

Why the employee has nothing to check

Put yourself on the receiving end. Your phone rings during a working day. The caller knows your name, your manager’s name, the ticketing system, and that you recently had a laptop issue. None of which is hard to assemble from a professional network profile and a data broker. They say there is a security problem with your account and they need to walk you through a fix.

The employee’s options are all bad.

Caller ID proves nothing. Number spoofing is trivial and cheap. Google Threat Intelligence tracked UNC6671 using spoofed help desk phone numbers against financial services organizations, with $10.69 million in ransoms traced (Google Threat Intelligence, August 2026).

“Hang up and call back” is sound advice that rarely survives contact. It requires the employee to be rude to someone who might be a colleague, to know the correct internal number, and to accept a delay while being told the problem is urgent. It also fails when the employee looks up the number on a page the attacker prepared.

Voice is not evidence. McAfee researchers produced a clone with an 85% voice match from three seconds of audio in one test (McAfee Labs, 2023). If your IT lead has ever spoken on a webinar, a conference panel, or a company video, the sample exists.

Familiarity offers no help either. In larger organizations the employee has never met anyone in IT, so there is no baseline to deviate from.

The employee is being asked to make a security judgment with no information. Then, predictably, they are blamed for getting it wrong.

What a working control has to do

Four properties separate agent verification that holds up from a procedure that adds friction without adding assurance.

It must be per-call, not per-agent. A shared department password or a standing phrase leaks once and then protects nothing. An attacker who has already socially engineered one employee has the secret.

The employee must initiate the lookup. If verification happens on a link, page, or number the caller supplies, the caller controls the verification. That is the same failure as the prepared lookalike domain: the check has to run somewhere the employee reaches independently.

It must be simple enough to survive a real call. Any control that requires the employee to remember a multi-step procedure under pressure from a confident stranger will be skipped. The ask has to be one sentence.

It must fail closed, by policy. If the caller cannot produce a valid code, the call ends and gets reported. Without that written down, “couldn’t verify” turns into “seemed fine, carried on,” and the control becomes optional exactly when it matters.

How Agent Verify works

Agent Verify is Trusona’s implementation, and it is patent pending. The flow has three steps.

The employee asks for the code. Employees are trained to ask any caller claiming to be from the IT help desk for a Verify Code. The code is unique to both the agent and that specific call.

The employee verifies it. They navigate to a dedicated internal company page, enter the code, and the agent’s identity is confirmed. The employee reaches that page independently, which is the property the whole control rests on.

They proceed, or they do not. Once the agent is verified, the employee continues with confidence. If the agent cannot produce a verifiable code, the call ends and the incident is reported.

Verify codes are single-use and time-limited, which is what makes the per-call property real rather than nominal. A code observed on one call does not authorize the next one.

The training burden is one sentence long: ask for the Verify Code. That is the reason it works in practice. Awareness programs fail when they ask employees to detect sophistication. This asks them to request a token, which is a task rather than a judgment.

Your customers have the same problem, and less to work with

Everything above describes employees, but the outbound impersonation call is at least as common against customers, and the customer is in a weaker position than the employee.

An employee at least has an internal directory, a colleague to ask, and a security team to report to. A customer receiving a call from someone claiming to be their bank, their health system, their airline, or their utility has none of that. They have a phone number they cannot verify and a caller who knows their account details, because those details were in a breach.

The scripts follow the same shape. There is a problem with your account. We need to confirm a transaction. Read me the code we just sent so I can verify you. That third line gives it away: a legitimate organization has no reason to ask a customer to read back a one-time passcode, and the attacker is using it to complete a login or a reset elsewhere.

Reversing the check works the same way here. The customer asks the caller to verify themselves before anything else happens, and gets a result rather than a hunch. It also protects the organization’s outbound calling in general, which otherwise degrades as customers learn, correctly, that they should not trust inbound calls. That erosion has a cost: once customers stop answering, legitimate fraud alerts and service calls stop landing.

Trusona covers this direction through ATO Protect for Customers.

The same problem one level up

Executives face a version of this that skips the help desk entirely. A call or video conference arrives from someone with authority, asking for a wire release, a confidential document, or an urgent approval, and the request is plausible because that person really could ask for it.

In the 2024 Arup case, a finance employee joined a video call on which the CFO and every other participant was synthetic, and approved roughly $25 million across 15 transfers (CNN / FT, May 2024). Nobody in that meeting was real except the victim.

Exec Verify covers this peer-to-peer direction: one executive verifying another before money moves or sensitive information changes hands. The principle is identical: the person receiving the request gets a way to check, rather than being asked to trust their ear.

Both sit in the ATO Protect Suite alongside the inbound check, where the agent verifies the caller. Running one direction and not the other leaves the documented attack path open.

What it does not do

Agent verification confirms that the caller is a legitimate agent of your organization. It does not establish that a legitimate agent is making a reasonable request, and it does not address a genuine insider. Those are different controls.

It also does not replace verification in the other direction. An employee confirming the agent is real does not tell the agent that the employee is real. Both checks are needed because both are attacked, and the advisory above describes each of them.

What it removes is the specific gap where an employee is asked to authenticate an organization with nothing to authenticate it against.

Getting it deployed

• Write the rule as one sentence and put it where employees already look. Any IT caller must provide a Verify Code before you share anything or click anything.
• Give the failure case an explicit, blameless procedure. Ending a call on a real colleague has to be the correct outcome, or nobody will do it.
• Cover the channels attackers actually use. CISA lists phone calls and SMS, so the rule cannot be phone-only.
• Include contractors and third-party service desks. The advisory specifically notes Scattered Spider targets contracted IT help desks and abuses those trusted relationships.
• Track how often codes are requested. Low volume means the rule has not landed, not that nobody is calling.

Employees have been asked to spot impersonation for years without being given anything to check. Agent Verify (patent pending) gives them a code to ask for and a page to check it on, and ends the call when it does not check out. See Agent Verify or the wider ATO Protect use cases.

Frequently asked questions

What is agent verification? Agent verification is the process by which an employee or customer confirms that a person contacting them from the IT help desk or support team is genuinely who they claim to be, before sharing credentials, reading out a code, approving a prompt, or installing software. It reverses the usual direction, in which the agent verifies the caller.

How do I know if an IT support caller is real? Ask the caller for a per-call verification code and check it yourself on an internal page you navigate to independently. Do not rely on caller ID, which is easily spoofed, and do not use a link or phone number the caller provides. If the caller cannot produce a code that checks out, end the call and report it.

Do attackers really call employees pretending to be IT? Yes, and it is federally documented. CISA advisory AA23-320A records Scattered Spider posing as company IT or help desk staff by phone and SMS to obtain credentials, to direct employees to install remote access tools, and to convince employees to share one-time passcodes. MITRE tracks the technique as Impersonation (T1656).

Why is caller ID not enough? Phone number spoofing is inexpensive and widely available. Google Threat Intelligence documented UNC6671 using spoofed help desk numbers against financial services organizations in 2026.

Can I just tell employees to hang up and call back? It is reasonable advice and it is not sufficient on its own. It depends on the employee knowing the correct internal number, being willing to interrupt someone who may be a colleague, and resisting stated urgency. Attackers also register lookalike help desk domains so a searched-for number can lead back to them.

How does Agent Verify work? The employee asks the caller for a Verify Code that is unique to that agent and that call. The employee enters it on a dedicated internal company page and the agent’s identity is confirmed. Codes are single-use and time-limited. If no valid code is produced, the call ends and the incident is reported.

Is Agent Verify patented? Agent Verify is patent pending.

What is the difference between Agent Verify and Exec Verify? Agent Verify lets an employee or customer confirm that a support agent contacting them is legitimate. Exec Verify covers the peer-to-peer case, where one executive confirms another’s identity before approving a wire transfer or a confidential request.

Your employees have been told for years to be suspicious of callers claiming to be IT. Suspicion is not a control. A code they can check is.