Pretexting: the made-up story behind most successful scams

A good con artist never opens with the ask. They open with a story — a believable reason that makes the request that follows feel completely normal. In security, that story is called a pretext, and building one is called pretexting. It is the quiet first move behind most scams that succeed against small businesses.

What pretexting actually is

Pretexting is the invented scenario an attacker uses to justify their request and lower your guard. The request itself might be simple — send a file, reset a password, approve a payment. On its own, that request might raise an eyebrow. Wrapped in the right story, it sails through.

"Hi, this is Dave from the IT company you use — we're doing a migration this weekend and I need to confirm your login." The ask (your login) is outrageous in isolation. The pretext (a routine migration, a familiar vendor, a helpful technician) makes it feel ordinary. That's the entire trick: the story does the work the request can't do on its own.

The pretexts that show up again and again

Attackers reuse a small set of scenarios because they keep working:

• The IT helper. Someone claiming to be from your IT provider or "Microsoft support," calling to fix a problem you didn't know you had — and needing access to do it.
• The vendor with new bank details. An email from a real-sounding supplier saying their account has changed, please update it before the next payment. This one drains real money.
• The new executive or auditor. A person with authority you can't easily question, who needs sensitive information quickly and discreetly.
• The delivery or service provider. A courier, a utility, a software renewal — anything routine enough that you wouldn't think twice.
• The colleague in a bind. "It's me, I'm locked out and traveling, can you help me get back in?"

What makes these dangerous is the homework behind them. Attackers read your website, your LinkedIn, your out-of-office replies, and your press mentions. They learn your suppliers' names, your software, your org chart. A pretext built on real details is very hard to doubt in the moment.

Why it beats your filters

Pretexting often involves no malware and no malicious link at all. The "IT contractor" call is just a phone call. The "updated bank details" email is just text. There's nothing for an antivirus or spam filter to catch, because nothing about the message is technically dangerous. The danger is entirely in the human interaction. That's exactly why attackers favor it.

How to take the story apart

The defense isn't to become suspicious of everyone. It's to build one calm habit: verify the person through a channel they didn't choose. The attacker controls the email they sent or the number they called from. They do not control the contact details you already have on file.

A few practical rules that close most pretext attacks:

1. Any change to payment or bank details gets confirmed by a phone call to a number you already had — never a number from the email requesting the change.
2. Real IT and real banks don't need your password. A request for one is the tell, no matter how convincing the story.
3. Authority plus urgency plus secrecy is the danger combination. When a request leans on all three — "I'm the CFO, this is urgent, keep it between us" — treat it as suspect until proven otherwise.
4. Make verifying the norm, not an insult. A team that routinely double-checks unusual requests isn't paranoid; it's protected. The person asking, if legitimate, will understand.

Pretexting works on trust, so the antidote is a workplace where checking is expected and nobody gets in trouble for it.

The technical side still matters, because it limits how much a convincing story can actually achieve. Tenant Strike reviews your Microsoft 365 and Azure settings to show where a successful pretext would do the most damage — an account without enforced multi-factor authentication, an app that one person could approve too much access for, a forwarding rule that could quietly siphon mail. It's a five-minute, read-only check that turns "what could go wrong" into a specific, fixable list.