How should organisations verify vendors and employees when fraudsters can spoof emails, calls, and text messages?

Why trusted callbacks beat email, call, and text-message trust

When fraudsters can spoof channels, the control problem is not “who sounded legitimate” but “what channel or possession can be verified independently of the inbound message.” A trusted callback to a pre-enrolled number, device, or cryptographic factor breaks the attacker’s ability to steer the conversation through a fake inbox, caller ID, or text thread.

That matters because payment redirection, banking changes, payroll edits, and vendor master-data updates are all designed to happen under time pressure. A verification step that reuses the same compromised channel usually confirms only that the attacker can keep talking, not that the requester is genuine.

What a stronger verification flow actually checks

The best verification flow confirms the relationship, not just the message. For employees, that can mean a known device, a pre-registered authenticator, or a verified return call to a number taken from an internal directory or prior enrollment record. For vendors, it means using contact data established before the request, not the revised details inside the email thread.

Static knowledge questions, email reply chains, and caller-ID trust are weak because they rely on information or channels that an impersonator can already observe, spoof, or socially engineer. A better check uses a second trust anchor that was bound earlier and is harder to redirect at the moment of fraud.

Where available, organisations should prefer stronger possession-based verification such as a cryptographic authenticator, because it is less exposed to SIM swap, mailbox compromise, and voice spoofing than channel-based trust alone. That is the practical reason many teams move toward phishing-resistant verification paths rather than ad hoc callback habits.

How to operationalise verification without creating friction leaks

Verification should be designed into the transaction workflow, not added as an afterthought once a suspicious request arrives. The right place to verify is before a bank account changes, before a vendor master record is amended, and before an exception is approved under urgency.

Good practice is to separate the request channel from the approval channel, and to require that the approval channel be pre-enrolled and independent. That reduces the chance that one compromised message can carry both the instruction and the proof.

Practitioners should also define who owns the callback directory, how changes to that directory are validated, and what happens when the trusted number or device is itself outdated. If the fallback path is easier to spoof than the primary path, the control degrades quickly under real fraud pressure.

Risk and Threat Considerations

Fraudsters often win by exploiting urgency, familiarity, and channel trust. If an organisation verifies people only through the same mailbox, phone number, or text thread used to send the request, an attacker who can spoof or intercept that channel can redirect payments, alter employee data, or impersonate a supplier with very little resistance.

Failure mechanism: The control fails when the organisation treats inbound contact details as proof of identity, rather than verifying against a pre-established trust anchor that is outside the spoofed conversation.

Impact: The likely result is payment diversion, account or payroll manipulation, unauthorised data changes, and delayed detection because the request appears to have come through a familiar channel.

Practitioner Guidance

What to prioritise: Treat high-value changes differently from routine correspondence. Payment redirection, bank detail changes, and payroll updates deserve a stronger verification path than ordinary vendor or employee queries.

What to verify: Verify against a contact point enrolled before the transaction starts, not one supplied in the request. If the request arrives by email, confirm it through a trusted number, device, or cryptographic possession that is already on file.

Common mistake: Teams often document a callback process but still let the requester influence the callback destination. That turns the control into a rubber stamp and leaves the organisation exposed to channel spoofing and social engineering.

Practitioner takeaway: The security gain comes from independent verification, not from simply using a second communication channel. If the second step can also be redirected by the attacker, it is not a real control.

Related resources from NHI Mgmt Group

• Why do organisations need to extend redaction beyond text-based messages in SaaS collaboration and support tools?
• What breaks when employees are not trained to verify unusual requests across email, text, and voice channels?
• How should organisations verify participants in high-risk video calls to reduce impersonation and deepfake fraud?
• How should organisations verify help desk callers before employees share codes or approve prompts?