Fake tech-support scam calls work because they turn a normal device problem into an urgent conversation. A caller may claim to be from the help desk, software provider, internet company or security team and say that an employee’s computer is infected, an account is under attack or a licence must be renewed. This 2026 guide gives organisations a practical training plan for verifying support calls, protecting devices and reporting before a stranger gains remote access.
TL;DR
- Treat an unexpected technical-support call as unverified, even when the caller knows the employee’s name, device or company.
- Never provide a password, MFA code, recovery code or remote-access permission because a caller demands it.
- End the call and contact IT through the organisation’s known support route.
- Require approval before installing software, changing security settings or allowing remote control.
- Practise the response with security awareness training and phishing simulations, then measure reports and time to escalation.
Why fake support calls work
Technical problems create pressure. A frozen screen, suspicious pop-up or failed login already makes the employee want help, and a confident caller can appear to offer an immediate solution. The caller may use a familiar company name, a local-looking number or information gathered from a public profile. Caller ID and a professional tone do not prove identity.
The requested action is usually the important clue. The caller may ask the employee to install remote-access software, read out a one-time code, open a command window, move money to a “safe” account or disable a security control. Even if the original problem is genuine, the person on the phone must still follow the organisation’s support and approval process.
Training should make the safe choice easy: pause, end the call, use the known help channel and report the request. Employees should not be expected to diagnose the caller’s technology. They need permission to refuse an urgent request without fear of being blamed for delaying a fix.
What the training needs
- The organisation’s approved service-desk number, portal and escalation route.
- A list of support providers and the actions they are authorised to request.
- A rule that staff never share passwords, one-time codes or recovery codes by phone.
- Approval requirements for remote access, software installation and security-setting changes.
- A clean-device response plan if remote software or credentials were exposed.
- A reporting route that accepts the caller’s number, message and time without asking for secrets.
The steps
1. Define the legitimate support workflow
Document how employees request help, how the service desk identifies them and when a technician may use remote access. State which phone numbers, portals and chat channels are approved. Explain how an external provider is introduced and how a scheduled maintenance call is announced.
Make the workflow visible in the employee hub and onboarding material. A person should find the official support route without searching an unexpected email, pop-up or caller’s text message.
Expected outcome: every employee knows how to start a support request and how to verify an unsolicited one. Common mistake: assuming the help-desk number is known because it appears in an old policy document.
2. Teach the red flags that matter
Give staff a short set of signals they can recognise during a live call:
- The caller contacted them without a support request or scheduled appointment.
- The caller creates urgency by threatening account closure, data loss or immediate infection.
- The caller asks for a password, MFA approval, one-time code or recovery code.
- The caller wants remote control, a new application, a command-line action or a security setting disabled.
- The caller asks the employee to keep the conversation secret or avoid the normal service desk.
- The caller’s number, name or company does not match the organisation’s records.
A real technician can wait while the employee calls back through a known number. The lesson is about requested access and process, not the caller’s accent, confidence or technical vocabulary.
Expected outcome: staff can pause a suspicious call within seconds. Common mistake: teaching people to trust a caller who knows a device model or internal team name.
3. Use a safe verification script
Give employees words they can use without debating the caller: “I do not approve support changes on an unsolicited call. I will contact the service desk through the approved channel.” They should end the call, record the time and report it. They should not call back on the number that appeared on the screen or use a link sent during the call.
If the caller claims to be from a supplier, contact the supplier through the contract record or approved account owner. If the issue is genuine, the service desk can confirm it in the official ticketing system. A short verification delay is a normal control.
Expected outcome: employees can refuse the request and reach a trusted support person without revealing information.
4. Control remote access and software changes
Remote support is not automatically unsafe, but it must be initiated or approved through the normal process. Record which tools the organisation permits, who can authorise a session and how the session ends. Do not let a caller choose an unfamiliar tool because it is “faster”.
Teach staff not to install browser extensions, executable files, mobile-management profiles or “security updates” during an unexpected call. They should not open a command prompt, run a script or disable endpoint protection because someone on the phone says it is required. Technical staff need the same rule when a request arrives outside a ticket.
Expected outcome: an unverified caller cannot gain control of a device through pressure alone. Common mistake: approving remote access first and trying to verify the person after the session starts.
5. Practise the response after access is given
If an employee shared a credential, approved an MFA prompt, installed remote software or allowed a caller to control the device, the first action is to stop and report. Do not continue the conversation, delete the tool or attempt to “watch” what the caller is doing. Preserve the caller’s number, messages, software name and time of access.
The response team should isolate the device according to the incident plan, secure the email and identity account, reset exposed credentials from a clean device, revoke active sessions and review connected applications. Check for new users, changed recovery details, unusual files, browser extensions, payment activity and messages sent from the account.
If the caller requested a transfer or personal information, notify finance and the relevant response owner immediately.
Expected outcome: the service desk hears about the event before the attacker can move from the device to other accounts. Common mistake: waiting for a pop-up, missing file or financial loss before escalating.
6. Run a safe simulation and measure behaviour
Use a fictional scenario such as an unexpected account-infection call, a fake software-renewal call or a pretend technician asking for remote access. Do not request real credentials, run software or make staff change device settings. The exercise should test whether the employee ends the call, uses the known support route and reports the event.
Measure completion, report rate, time to first report, remote-access approval attempts and the number of people who used the approved contact. Review results by role because executives, field staff, finance approvers and technical teams receive different pretexts.
Use human risk reporting to track the lesson, simulation outcomes and follow-up actions. Repeat with a different scenario later in 2026 so staff practise the process rather than memorise one caller script.
Troubleshooting
The caller knows the employee’s name and manager. Treat those details as unverified. End the call and use the known support route.
A real pop-up appears while the caller is on the phone. Do not follow the caller’s instructions. Capture the details if safe, close the conversation and contact IT through the approved channel.
The employee worries that ending the call will delay a repair. Make the verification script part of the service culture. A genuine technician can wait for a callback through the recorded support route.
A supplier needs to provide urgent remote help. Confirm the request with the internal account owner, create or reference a ticket and use only the approved tool and session controls.
Someone installed remote-access software. Treat it as an incident. Isolate the device as directed, secure accounts, preserve evidence and notify the service desk without blame.
Staff report too many legitimate support calls. Include real scheduled examples in the next lesson and show how the approved workflow identifies them. The goal is independent verification, not refusal of all assistance.
A practical 30-day rollout
In week one, publish the service-desk route, approved providers and remote-access rules. In week two, practise the refusal script and ask staff to find the official support portal. In week three, run a safe call scenario without requesting real access. In week four, review report rate, response time and any process that makes verification difficult.
Use a cyber security gap assessment to record unclear support ownership, stale provider access and untested device-isolation steps. If comparing awareness providers, use compare security awareness platforms after defining the role-based training, simulation and reporting requirements.
FAQ
How can staff recognise a fake tech-support call?
Be cautious when the call is unsolicited, urgent or asks for a password, code, remote access, software installation or disabled security control. End the call and contact IT through a known route.
Should staff let a caller control the device to prove the problem?
Not on an unsolicited call. Remote access should be initiated or approved through the organisation’s service-desk process using an approved tool and a named technician.
What should happen after remote access is granted?
Stop the session, report it, preserve the software and event details, isolate the device as directed, secure exposed accounts and review sessions, applications and account changes.
How often should fake-support-call training run in 2026?
Run an initial lesson, a safe scenario within 30 days and a varied refresher after a service-desk, remote-access or software-provider change. Include new starters before they receive device access.
What should managers measure?
Track completion, report rate, time to first report, unexpected remote-access approvals and whether staff used the approved support route. Compare similar scenarios by role.
One last thing
A support call is legitimate because the organisation can verify it, not because the caller sounds technical. Give staff a script, a known callback route and permission to pause. That turns an urgent voice on the phone into a controlled support request instead of a device takeover.