A Practical Guide to IT Caller Verification
How to check that employees can verify support callers—and know what to do when verification fails.
Telling employees to verify IT is easy. Ask someone to show you how they would do it during an unexpected support call, without help from the person calling.
Can they find the right app? Do they know what a completed check looks like? Where do they go if it fails?
Those are the questions I would bring into a support review. They test whether the organization has given employees a usable process, not just a warning.
Microsoft's 2026 Digital Defense Report, pages 46–47, describes Teams attackers increasingly using personal-looking names rather than obvious helpdesk labels. In successful interactions, callers can persuade employees to grant remote access, followed by reconnaissance and malicious downloads. The reason to test is not whether employees can recognize every disguise. It is whether the required check still happens when the conversation sounds routine.
Start with a legitimate support call
Have a genuine support agent make an approved test call about a harmless, fictional issue. Use test accounts where appropriate, set a stop condition, and agree the scope with security and support leadership. Do not collect passwords, change authenticators, install software, or grant production remote access for the exercise.
Explain that the review is intended to improve the process. It is not a contest to embarrass employees.
Begin with the successful path. If an employee cannot verify genuine IT without coaching, fix that before increasing the difficulty.
Check whether employees can find the verification process
The agent asks the employee to use the organization's established verification process, but does not send its link or narrate every click.
Observe where the employee goes first. Can they find the configured company app or published support destination independently? Is it available on the device they actually use? Do new starters and remote workers have the access the procedure assumes?
Record an unavailable app, missing access, or unclear instruction as a process problem. Someone who knows verification is required but cannot reach it needs a usable route, not another reminder to be careful.
Our Teams support impersonation article explains why the destination should not depend solely on the caller. This check establishes whether employees can find that destination in practice.
Check whether employees recognize completion
With Fctr Verify, an IT caller meets organizational policy and creates a request in Fctr Portal. The employee independently opens Fctr in their configured Teams or Outlook app, reviews the pending caller and reason, selects the phrase spoken by the caller, and submits. They wait for verification to complete without reading the choices back.
Observe whether the employee reviews the request rather than treating its arrival as proof. Can they distinguish a pending check from a completed one? Do they pause the sensitive work until completion?
In a separate controlled case, have the tester say a phrase that does not match. The expected response is rejection and escalation, not choosing the nearest option. This tests understanding of the workflow, not whether the employee finds the caller convincing.
Check what happens when verification cannot complete
Run a case with no matching request, or use a tabletop scenario in which the approved app is unavailable. The employee should stop the sensitive interaction and reach support through independently known details.
The important follow-up is what support does next. Who receives the escalation? Can they help without telling the employee to ignore the check? Is the safe route available outside normal office hours?
A process has not passed merely because the employee refused. They also need a practical way to obtain legitimate help.
Record the outcome and fix the obstacle
For each case, record whether the employee found the trusted destination, checked the request, waited for completion, and used the approved escalation route when needed. Note where assistance was required and assign an owner to fix that obstacle. Retest after the change.
Keep identity separate from permission: a verified caller still cannot authorize prohibited remote access or software installation. Maintain collaboration restrictions, approved support tools, strong authentication, and endpoint monitoring alongside the check. Microsoft's Teams hardening guidance covers complementary controls for external access and screen control.
We built Fctr to give employees a concrete way to verify support callers. The useful evaluation is whether that check works in your team's daily process, including when it cannot complete.
Ask us to walk through both outcomes: a genuine IT caller who verifies, and a request the employee must stop. That is more useful than a demonstration where every check succeeds.