The moment that changed my mind on social engineering verification

Something made me pause. Not any single red flag — the caller knew enough about the client’s systems to sound completely legitimate. It was more a general unease about the combination of factors: an unfamiliar voice, an unusual channel, an out-of-hours request, and a destination email address that had nothing to do with the client’s domain.

I told him I wasn’t comfortable proceeding without verification from someone at the client I already knew, and that I would try to reach them. He wasn’t happy about it. He explained again how urgently he needed access, how his whole morning shift depended on it.

I reached out to one of the client’s senior contacts anyway. Within a few minutes, I had confirmation: the request was legitimate, the person was who he said he was, and the reset could go ahead.

In this case, the caller was genuine. But the process I followed was exactly right — and the outcome would have been catastrophic if he hadn’t been.

Why social engineering identity verification matters more than ever

Social engineering has always been the most effective attack vector against IT systems, because it doesn’t require any technical sophistication at all. It requires only that someone trust the wrong person at the right moment.

What’s changed is how convincing the wrong person can be. AI voice cloning can now reproduce someone’s voice from a short audio sample. Deepfake technology is accessible enough that a bad actor can impersonate a known contact with alarming accuracy. The caller who sounds like your client’s IT manager, in their voice, using real names — may not be.

In the MSP world, this matters in a specific and underappreciated way. We hold access to our clients’ environments that most of their own staff don’t have. A VPN token reset, an account unlock, a password change, a new user provisioned to the wrong access level — any of these, executed for the wrong person, could give an attacker everything they need.

The identity verification burden falls on us, every time. And that burden is precisely why managed cyber security must go beyond technical controls — it has to account for the human moment at the end of the phone line.

The pressure tactics to watch for in standby security calls

Social engineering attacks against service desk and standby engineers almost always involve the same toolkit:

• Urgency. The request cannot wait. Business operations depend on it. Every minute of delay costs the client something.
• Isolation. The usual channels are unavailable. Email is down. Colleagues are unreachable. The normal verification path is blocked by coincidence.
• Authority. The caller invokes a name, a process, a relationship, or a role that suggests the request is legitimate. Sometimes they’re right — which is exactly what makes this hard.
• Emotional pressure. The caller is frustrated, stressed, or apologetic. They’re not threatening you. They’re just someone who needs help, and you’re the person who can provide it.
• None of these tactics, individually, is proof of an attack. But any combination of them in an out-of-hours or unusual-channel context should slow you down, not speed you up.

The verification process that protects MSP engineers and clients

What I’ve learned — and what I’d recommend to any engineer who handles standby calls — is that verification has to be unconditional. Not conditional on how convincing the caller sounds. Not conditional on how urgent the situation is. Not conditional on how well you know the client.

The threshold for acting on any account-related request over the phone should be: can I confirm this person’s identity through a second channel I initiate? Not a channel they gave me. A channel I already know is legitimate.

In practice, that means: if someone calls asking for a token reset, I send a message to a number or email I already have on file for the client, and I wait for confirmation. If no confirmation comes, no action happens. If the situation is genuinely urgent and the person is genuinely legitimate, they will find a way to confirm it.

The caller who loses patience with that process is not necessarily an attacker. But an attacker will always lose patience with that process — because they can’t verify themselves through a channel they don’t control.

This is where Trusted Response Centre discipline becomes operational rather than theoretical — because consistent process, applied at 6am on a bank holiday, is the difference between a near-miss and a breach.

The honest truth about MSP standby security

Good engineers want to help. That instinct is what makes great service. But it’s also the precise quality that social engineers exploit. The call at 6am succeeded in applying pressure because the request came from someone who sounded like they needed help, and the desire to resolve it quickly was completely natural.

The protection isn’t suspicion. It’s process. A consistent verification step applied every time — regardless of how well-reasoned the exception seems — removes the decision entirely. There is no situation urgent enough to skip it, because if the verification genuinely cannot happen, the action genuinely cannot happen.

When that’s the policy, it protects the engineer as much as the client. You’re not being difficult. You’re following the procedure that exists for exactly this reason.

And in a world where the voice on the other end of the phone might not be who it claims to be, that procedure is the most important security control you have.

The attacker who can clone a voice, replicate a name, and manufacture urgency in real time cannot replicate a second-channel verification step — because they don’t control the channels you already trust. Process is not a bureaucratic obstacle. It is the security control.

If you’re evaluating whether your organisation’s security posture extends to how your MSP handles out-of-hours calls, we’re happy to discuss your needs and walk through what a structured verification process looks like in practice.