Most security investment goes toward stopping attacks on technology: firewalls, endpoint protection, patching, multi-factor authentication. Those controls work well against automated, opportunistic threats. What they don’t cover is a well-briefed attacker who picks up the phone, calls your help desk, and talks their way in.
The service desk exists to unblock people fast. Reset a forgotten password, unlock an account, set up a new starter, help someone whose phone died over the weekend. Being helpful and quick is the whole role, and that is precisely what a skilled social engineer relies on. It has made support staff one of the most reliably exploited routes into the enterprise.
Why the Help Desk Became a Target
The value of the help desk to an attacker is what it can do to everyone else’s access. A support agent can reset credentials, unlock accounts, elevate permissions, and in many setups re-enroll multi-factor authentication to a new device. That last capability is the prize. An attacker who convinces an agent to move MFA to a phone they control has defeated MFA completely, because their device is now the trusted factor. There is no malware involved and no vulnerability to patch.
The group commonly tracked as Scattered Spider has built much of its activity around this method. In a joint advisory updated in July 2025, CISA and its international partners described how the group impersonates company employees or IT staff, using phishing, push bombing, and SIM swap attacks to obtain credentials, install remote access tools, and bypass MFA. The same advisory notes that the group targets large companies and their help desks specifically. Our breakdown of the ShinyHunters and Okta vishing incident shows the technique playing out against a named organization. It is a repeatable playbook, and it has affected airlines, retailers, insurers, and healthcare providers.
Persuasion also scales in a way that technical exploitation does not. The 2025 Verizon Data Breach Investigations Report found that the human element featured in around 60% of breaches, whether through error, manipulation, or misuse. A trained agent who wants to help is a more predictable target than a hardened server.
Start With the Process Controls
The heart of this problem is identity verification, so that’s where defense starts. When an attacker calls in, everything rests on whether the agent can confirm the caller is who they claim to be, and on what the agent is allowed to do once that trust is established. A few controls carry most of the weight:
- Verify callers with something they can’t look up. Employee ID, manager’s name, and date of birth are all discoverable. Effective verification uses a callback to a number already on record or confirmation through a separate channel.
- Require a second sign-off for sensitive actions. Password resets, MFA re-enrollment, mailbox delegation, and role changes shouldn’t rest with one agent under pressure.
- Move privileged accounts to phishing-resistant MFA. FIDO2 security keys and passkeys remove the phishable codes and push prompts these attacks depend on.
- Alert on the identity actions themselves. New authenticator enrollment, recovery-method changes, and role escalation are the events an attacker triggers, so they’re the events to watch.
These live in your identity provider and your help-desk playbook rather than in any one product, and they are the frontline. Tooling supports them, but the discipline is what stops the call from succeeding.
Cut the Standing Privilege
Strong caller verification stops most fraudulent requests. The next question is what an attacker gains on the occasions one gets through, and that comes down to how much privilege the help desk carries.
Support agents are often given broad, permanent administrative rights, on the reasoning that they need that access to do the job. Standing local admin across the fleet, sometimes membership in Domain Admins, available all day whether it’s in use or not. When a support account carries permanent privilege, a single compromised or socially-engineered agent hands the attacker that same sweeping access in one step, and the reach of one manipulated call extends to everything the agent could touch.
Removing the standing privilege changes the math. The same compromise buys the attacker far less, because there is nothing waiting to be inherited. This is least privilege applied to the people targeted most often precisely because of their access.
How Support Assist Handles It
The Support Assist feature in Admin By Request EPM is built for help desks made up of non-admin staff, so the principle of least privilege applies to support agents as well as end users. It lets an agent help a user complete a task that needs elevation, without either person holding standing admin rights.
The sequence is straightforward. A user requests help and an agent picks up the task, connecting to the machine through Remote Support (part of our Secure Remote Access solution). The agent starts the assist session and enters their own credentials at a UAC prompt. From there they work with less restrictive settings than the user has, while the user watches the whole time. When the task is done, either person can close the session, or it expires on its own.
Two design choices make this safe. First, the agent is bound by their own Admin By Request EPM settings during the session. If an agent isn’t permitted to start a full admin session in normal use, they can’t do it through Support Assist either, because the UAC prompt checks their actual privileges. If someone outside the help desk finds the button and clicks it, nothing happens, since it only ever applies the clicker’s own rights. Where MFA is enabled, the agent has to authenticate before the session starts.
Second, every session is joint-logged. The audit trail records that the user requested the change and the agent executed it, tied to a single trace reference. If a session later turns out to be fraudulent, you can see what was done, under whose credentials, on whose machine, and when. That attribution is what makes social-engineering abuse possible to detect and reconstruct, instead of leaving it buried in a shared admin account nobody can trace.
The result is a help desk that still unblocks users quickly without carrying the standing privilege that makes a manipulated agent so costly.
Bringing the Layers Together
Securing the service desk against social engineering comes down to hardening the process first, then closing off the privilege an attacker inherits if a request slips through:
- Verify callers with methods an attacker can’t research, and confirm sensitive requests out of band.
- Require secondary approval for password resets, MFA re-enrollment, and role changes.
- Move privileged and support accounts to phishing-resistant MFA.
- Alert on identity events such as new MFA enrollment and recovery-method changes.
- Remove standing admin rights from help-desk accounts and grant elevation just-in-time.
- Make every elevated action attributable to a named individual through joint logging.
The first four are identity and process discipline. The last two are where Admin By Request EPM contributes directly, through Support Assist and least-privilege elevation for the staff attackers go after most.
Want to see how least privilege for your help desk works in practice? Book a free demo, or sign up for our lifetime free plan and try it across up to 25 endpoints, free, forever.
Frequently Asked Questions
Why do attackers target the help desk?
Support agents hold power over everyone else’s access. They can reset credentials, unlock accounts, elevate permissions, and in many setups re-enroll multi-factor authentication to a new device. An attacker who talks an agent into moving MFA to a phone they control defeats MFA outright, with no malware or exploit involved.
What is help desk vishing?
Vishing (voice phishing) is a phone-based social engineering attack. The caller impersonates an employee or IT staff member, claims to be locked out or to have a new device, and pressures the agent into a password reset or MFA re-enrollment. It works by exploiting the help desk’s core job of unblocking people quickly.
Can multi-factor authentication stop these attacks?
Not on its own. Attackers bypass MFA by convincing an agent to enroll a new device, or by guiding a victim through a fake login page in real time. Phishing-resistant methods like FIDO2 security keys and passkeys hold up far better than push notifications or one-time codes.
How do you verify a caller to the help desk?
Use something the caller can’t look up. Employee ID, manager’s name, and date of birth are all discoverable, so effective verification relies on a callback to a number already on record, or confirmation through a separate channel. Sensitive actions should also require a second sign-off rather than resting with one agent.
Should help desk staff have permanent admin rights?
No. Standing admin rights mean a single compromised or socially-engineered agent hands an attacker sweeping access in one step. Granting elevation just-in-time, only when a task needs it, keeps that access from sitting around waiting to be abused.
What is Support Assist?
Support Assist is a feature in Admin By Request EPM that lets a non-admin help desk agent help a user complete a task requiring elevation, without either person holding standing admin rights. The agent connects through Remote Support, enters their own credentials, and works within their own permission settings while the user watches.
How does Support Assist keep help desk actions accountable?
Every session is joint-logged. The audit trail records that the user requested the change and the agent executed it, tied to a single trace reference. If a session later turns out to be fraudulent, you can see what was done, under whose credentials, on whose machine, and when.
Does Support Assist stop social engineering by itself?
No, and no single tool does. Caller verification, secondary approval, and phishing-resistant MFA are the frontline defenses at the identity layer. Support Assist addresses a specific piece: removing standing admin from help desk accounts and making every elevated action attributable.
