Pretexting: the story that makes an unusual request feel ordinary

A request can be suspicious in isolation and reasonable inside a story. Send this document. Approve this prompt. Let this person through. Change this payment detail. The action may barely change; the explanation around it does.

That is the useful starting point for understanding pretexting: a constructed situation gives someone an apparently legitimate reason to ask for information, access or action. The purpose is not necessarily to make every detail false. A few true details can make the unsupported part easier to accept.

A story is not an identity check

The Canadian Centre for Cyber Security’s social-engineering guidance describes manipulation used to obtain information or actions, including impersonation and plausible scenarios. For readers, the practical distinction is between a narrative that fits and evidence that establishes authority.

Imagine an illustrative workplace situation. A person says they are helping a colleague who cannot access a document before a deadline. They know the colleague’s name, the project and the meeting time. Those facts make the explanation coherent. They do not establish that the person is entitled to receive the document.

This is not a demand to distrust every helpful interaction. It is a way to identify the exact point where ordinary cooperation crosses into a consequential action. The friendly tone and the access decision belong to different categories of evidence.

Follow the trust chain

A trust chain is our editorial shorthand for the sequence of assumptions that makes a request acceptable. A familiar name leads to a familiar role. The role suggests a legitimate task. The task makes an unusual action seem necessary. If each step feels small, the final action may receive less scrutiny than it would on its own.

You can examine that chain without adopting an attacker’s perspective. Ask what the person knows, what they claim, what authority the role would actually carry, and how that authority can be checked. The purpose is to find unsupported transitions, not to rehearse a convincing deception.

A request can contain correct information at one layer and fail at another. Authenticating a person’s identity does not automatically authorize every action they request. Likewise, a real project does not authenticate the sender of every message about it.

Why familiar processes are attractive disguises

Most people do not decide from scratch how to respond to every email. They rely on patterns: invoices go to finance, support fixes access, managers assign work, and delivery messages concern packages. That reliance is necessary for ordinary life to function.

The problem appears when the process has an unexamined exception. Perhaps a payment change can be approved inside the same email thread that requests it. Perhaps an identity reset relies on details widely available in a staff directory. Perhaps urgency lets a requester bypass the only independent check.

The NCSC’s phishing guidance advocates layered defenses rather than expecting people to detect every deceptive message. For this article, the important implication is structural: a workflow should not require perfect suspicion from the person handling it.

Verification must leave the requester’s route

Asking the same person for more convincing evidence can become a loop. They provide a badge, a reference number or another contact who confirms the story. If all of it comes from the original requester, the process may never leave the unverified channel.

An independent route is one established outside that interaction: a saved contact, a staff directory, an official app, a known support portal or an existing vendor record. It is not simply a different app suggested by the requester. Moving from email to a chat account they supply can preserve the same dependency.

The appropriate check depends on the action. Sharing a public brochure and changing a supplier’s bank details should not need identical procedures. The check should become stronger as the consequence increases, and it should be clear enough that a busy person can perform it.

The best question may be about the action

“Are you really from support?” invites an identity performance. “I will reopen this through our normal support portal before granting access” establishes a process. The second statement does not require an argument about the caller’s character.

This distinction is especially useful when the requester seems friendly or technically knowledgeable. Competence is not authorization. Someone may accurately explain a software setting while lacking any legitimate reason to change it on your account.

At work, a good process should also make this boundary socially acceptable. If managers routinely punish delay or ask for exceptions through informal messages, employees receive mixed instructions. A poster saying “verify unusual requests” cannot compensate for leadership behavior that makes verification feel disloyal.

Three illustrative situations, three different controls

A colleague asks for a confidential file. Check whether the request matches their role and the usual sharing system. A real account can be compromised; access should still follow the document’s intended audience. Forwarding the file to a new personal address is a different action from granting access inside an established workspace.

A support caller asks for an account reset. Use the approved support route and recovery policy. Knowing an employee’s biography should not be treated as possession of an authenticator. Our help-desk identity guide explores why exceptions need ownership rather than improvisation.

A familiar voice requests an urgent payment. Confirm the request through a previously established contact route and normal payment approval. The voice may be genuine, synthetic or misattributed; a familiar sound does not resolve authorization. See the verification guide for voice and video.

These examples are constructed to illustrate decision boundaries. They are not accounts of named incidents, and they do not imply that one control can eliminate every possible deception.

What a good explanation should not do

An explanation of pretexting can accidentally become a list of magic persuasion tricks. That framing overstates the predictability of people and understates the role of context. Individuals differ, institutions differ, and a plausible request may be rejected because a routine control works as intended.

It can also slip into victim blame. Saying a person was “too trusting” may describe nothing useful about the decision. Which identity claim was accepted? Which permission was missing? Which workflow let the action occur? Those questions produce changes that can be tested.

Finally, do not treat a technical label as a diagnosis. Phishing, pretexting, impersonation and business-email compromise can overlap. A label is useful when it clarifies the sequence, not when it replaces a description of what happened.

A small framework to keep

For a consequential request, write four short answers: Who is asking? What action changes something? Why now? How can I confirm it outside this exchange? If the fourth answer depends entirely on the requester, the verification is not yet independent.

For teams, test whether the answer is available during a busy shift, outside normal hours and when the person’s usual account is unavailable. A control that only works in an ideal situation leaves the hardest decisions to improvisation.

Continue with manufactured urgency to examine how time pressure changes this process, or reporting without blame to consider what happens when someone notices the problem after acting. Understanding the story is useful; building a route out of it is what makes the understanding practical.