IT help desks are designed to remove friction. That makes them valuable to attackers who want a password reset, a new authentication method or access to a privileged account. This guide shows how to train help desk staff to slow down the right requests, verify identity consistently and still give legitimate employees a fast, respectful service.
TL;DR
- Treat every reset, MFA change and privileged-access request as an identity decision, not a routine ticket.
- Use one published verification path that does not rely on information an attacker can read from a directory or social profile.
- Give analysts short scripts for urgency, executive pressure, remote workers and lost devices.
- Separate emergency handling from normal handling, and log who approved any exception.
- Practise realistic voice, chat and ticket scenarios without collecting real credentials.
- Measure verification quality, exception rate, reports and repeat mistakes instead of rewarding speed alone.
Why this matters
A help-desk analyst may be the final person standing between an impersonator and a valid account. The request can arrive as a phone call, a chat message, an email or a ticket that appears to come from a manager. The attacker does not need to defeat the identity provider if the analyst can be persuaded to reset the credential first.
The Australian Signals Directorate’s Annual Cyber Threat Report 2024–25 describes social engineering as a way to direct people into opening attachments, visiting websites, revealing credentials, disclosing information or transferring funds. It also advises people who suspect an attempt not to engage, to preserve the communication and to report it. The help desk needs the same discipline: pause the request, preserve the evidence and use the approved escalation route.
Training should not turn analysts into suspicious people who frustrate every employee. It should give them a repeatable way to distinguish a normal request from a request that changes access, authentication or recovery information.
1. Map the requests that can change identity
Start with the help desk queue, not a generic social-engineering module. List every action an analyst can take that changes how a person or service authenticates. Include password resets, MFA device replacement, recovery email changes, new device enrolment, account unlocks, privileged-group changes, remote-access approval and temporary access for contractors.
For each action, record the required evidence, the person who can approve an exception, the system of record and the maximum time the request can remain open. A reset of a standard account should not have the same path as a change to a domain administrator or a finance approver.
The result is a risk-ranked request map. Use it to create role-based training: frontline analysts practise standard resets, senior analysts practise privileged changes and team leaders practise escalation decisions.
2. Make verification independent of the request
The Australian Cyber Security Centre’s system-hardening guidance says that, before credentials are set, including after a reset request, users should provide sufficient evidence to verify their identity. Its examples include physically presenting themselves and their pass to a service desk, answering challenge-response questions or demonstrating control of a linked mobile device, followed by secure delivery of randomly generated credentials. Adapt the evidence to the organisation’s policy, but keep the principle intact: the request itself is not proof.
Train analysts to use a known channel that was not supplied by the caller. For example, an analyst may call a number already held in the directory or ask the user to start a session through the company’s approved identity portal. Do not use a phone number, manager name or recovery address introduced in the suspicious request.
Write the verification steps where analysts work. A policy hidden in a long handbook will lose to a caller who says the board meeting starts in five minutes.
3. Give analysts words they can use
Most unsafe exceptions start as a conversation problem. The analyst wants to be helpful, the caller sounds credible and the request feels urgent. Give the team language that protects the process without accusing the person.
Useful phrases include:
- ‘I can help with that, but I need to complete the standard verification first.’
- ‘I cannot change the recovery method from this channel. I will give you the approved route.’
- ‘The request needs a second approver because it affects privileged access.’
- ‘I will record this request and have the service owner contact you through the known number.’
Practise saying these lines without adding clues about which check failed. An analyst should not tell a caller that the manager’s name was correct but the device check failed. That information helps an attacker tune the next attempt.
4. Separate normal, urgent and emergency handling
Urgency is not evidence. Define three service levels so analysts do not invent an exception during pressure:
- Normal: complete the standard identity checks, record the evidence and deliver the reset through the approved secure method.
- Urgent: use the same checks, but notify the on-call lead and set a service target for review.
- Emergency: use a documented break-glass process with two-person approval, a short expiry and a post-event review.
An emergency route should not be a shortcut around identity verification. It is a controlled way to limit harm when a critical service is at risk. Record who declared the emergency, what access was granted, when it expires and which evidence was retained.
Train managers and executives on the same rule. A senior title can explain why a request is important; it cannot replace the required proof.
5. Cover the channels attackers choose
A classroom example about a suspicious email is not enough. Build short scenarios for the channels your desk actually uses:
- A phone caller says their device was stolen and asks for MFA to be moved to a personal number.
- A chat user claims to be a new executive and asks for a password reset before a customer call.
- A ticket arrives from a familiar name but asks for a recovery email change and a new administrator.
- A contractor asks for access after hours and says the project owner is unavailable.
- A real employee reports that someone has already contacted the desk using their name.
Let the analyst choose the safe next step, then explain why. Include a report-only scenario where the right outcome is preserving the message and escalating it rather than replying. Cyber Aware’s phishing training can support the wider programme, while help-desk practice should stay tied to the service-management workflow.
6. Practise without creating new risk
Use simulations that record the decision and the report, not real passwords or security answers. A safe exercise can present an inbound call script to a trainer, a mock chat transcript, a test ticket or a controlled voice message. The exercise should stop before an actual reset, MFA change or access grant.
Tell analysts when the exercise is complete, identify the pressure cue and show the correct route. Do not publish a league table of individual failures. A private coaching conversation is more likely to improve the next decision than public embarrassment.
Repeat the practice after 30 to 60 days and change one variable at a time: the channel, the urgency, the requested action or the apparent authority. Repeating the same script only tests memory.
7. Measure quality, not just speed
Track the number of identity-changing requests, the percentage that followed the required verification path, exception rate, second-approver use, escalation time, suspicious-request reports and repeat errors. Keep service metrics such as first-response time and resolution time alongside the control metrics.
A fast reset is not a success if the verification was skipped. A slower ticket may be the correct outcome when the request is high risk. Review a sample of completed tickets each month with the service owner and security lead. Look for missing evidence, unclear scripts and workflows that encourage analysts to bypass controls.
Use human risk reporting to combine training completion, quiz results and phishing behaviour when the organisation’s data-handling rules permit it. For the help desk, add ticket-quality evidence so the report reflects the decisions that matter.
Troubleshooting
Analysts say the process is too slow
Measure the time spent on ordinary requests and high-risk requests separately. Remove duplicate fields and make the approved evidence easy to find, but do not remove the check that protects the account.
Executives demand an exception
Give executives a fast, pre-agreed path with the same identity proof and an on-call approver. Record any emergency access and its expiry. A title is not an authentication factor.
Remote employees cannot complete the normal check
Provide an approved remote route before an incident occurs. Test it with staff in different locations and document what happens when a device is lost. Do not improvise a weaker check during a live request.
The same analyst keeps bypassing verification
Review the workflow and coaching first. If the control is clear and supported but bypassing continues, move the analyst away from identity-changing actions until the risk is addressed.
Tools and resources
- Start with security awareness training for the shared language and role-based learning plan.
- Use a cyber security gap assessment to document recovery, access and approval gaps around the help desk.
- Use the Cyber Aware comparison page to compare verification, reporting and multi-tenant requirements when selecting a platform.
- Read ASD’s Guidelines for system hardening for guidance on identity verification and credential handling.
- Review the Annual Cyber Threat Report 2024–25 for Australian threat context and reporting advice.
FAQ
What should help desk staff verify before resetting a password?
They should follow the organisation’s approved identity-verification procedure and obtain sufficient evidence independent of the request. The evidence and delivery method should match the risk of the account, with stronger checks and additional approval for privileged access.
Can help desk staff reset a password over the phone?
They can only do so when the organisation’s approved process supports it and the caller completes the required verification. A familiar voice, caller ID or urgent explanation is not proof of identity.
How do you train help desk staff against social engineering?
Map the identity-changing actions they perform, teach a consistent verification workflow, provide scripts for pressure situations and practise phone, chat and ticket scenarios. Review real ticket quality without exposing individual results unnecessarily.
Should executives have a different help-desk verification process?
They may have a faster service route, but the identity evidence should not be weaker. Seniority explains urgency; it does not authenticate the request.
How often should help desk social-engineering training be repeated?
Run a baseline exercise, coach the team and repeat a comparable scenario after 30 to 60 days. Set the ongoing cadence from ticket risk, repeat errors and changes to the identity or access workflow.
One last thing
The help desk cannot compensate for a recovery process that makes the unsafe path easier. Give analysts a known verification channel, a clear escalation route and permission to pause a request without being punished for protecting the account.
What to do next
Write the three highest-risk identity-changing requests into the service desk runbook, assign an approver for each and practise one phone, one chat and one ticket scenario before the next access review.
Sources
- Guidelines for system hardening, ASD’s Australian Cyber Security Centre guidance on identity verification and credential handling, accessed August 2026.
- Annual Cyber Threat Report 2024–2025, ASD’s ACSC report covering FY2024–25, published 14 October 2025.