Verifying Identity Before Acting on a Request

Security Basics for Support Technicians

Chapter 4 · Verifying Identity Before Acting on a Request

Chapter 3 established the principle: a claim can only be verified through a channel the claimant doesn't control. This chapter turns that principle into a practical, repeatable process — and, just as important, one that scales with how risky the request actually is. Not every request needs the same amount of scrutiny, and treating a low-stakes question with the same suspicion as a password reset just trains people to route around your process rather than follow it.

Match Verification Effort to Risk, Not to Suspicion

Verification isn't a single on/off switch — it scales with what's actually being asked for:

Risk tier	Example request	Appropriate verification
Low	"How do I connect to the guest Wi-Fi?"	None needed — no sensitive access or data is at stake
Medium	"What's the status of my ticket #4821?"	A basic check — matching name/employee ID against the ticket itself
High	Password reset, access grant, disabling a security control	Independent callback, out-of-band confirmation, or manager sign-off — not skipped for any amount of urgency

The Chapter 1 reset request and Chapter 3's badge-reader call both sit firmly in the high tier — which is exactly why neither could be resolved on the spot in the chapters that introduced them.

Callback Verification, Done Properly

Chapter 3 established the core rule; here's what it looks like in practice. Never call back a number the requester provided — not the number they're calling from, not a number they read out over chat. Instead:

End or pause the current contact
Independently look up the person or department's number — an internal directory, an intranet page, a previously saved contact — never anything supplied in this specific conversation
Call that number and confirm the request directly

Applied to Chapter 3's badge-reader call: rather than acting on the caller's claim, or even calling back whatever number showed on caller ID, the technician looks up Facilities' own listed extension and calls that instead. If the person who actually answers has no idea what "delivery emergency" is being referred to, the original call is confirmed as fabricated — without ever having disabled anything.

Out-of-Band Confirmation

A close relative of callback verification, used when a phone call isn't the channel in question. If a request arrives over chat, confirm it through a different channel entirely — a known email address, an in-person check, or a separate messaging platform the requester doesn't control the identity behind. The principle is the same: never confirm a claim using only the same channel the claim arrived on, since that channel may itself be compromised or spoofed.

Why "Security Questions" Are Weaker Than They Feel

Information the requester provides about themselves isn't proof

An employee ID, a date of birth, a "mother's maiden name" — these feel like verification because they're personal, but they're often guessable, previously leaked in an unrelated breach, or simply findable through the pretexting techniques Chapter 3 covered. None of it is proof of identity on its own; it only proves the requester knows a fact, which an attacker who's done their homework may also know.

Knowledge-based checks like these are fine as one layer among several for medium-risk requests — they should never be the only check standing in front of a high-risk one.

Worked Example: Applying the Tiers

A chat message arrives: "Hey, it's Dana from Accounting, can you tell me what my temp password is? I'm locked out and have a deadline in ten minutes." This is a high-risk request (a credential) wearing a low-risk tone (a casual, friendly chat message). The risk tier is set by what's being asked for, not by how the request is phrased — so it gets high-tier verification regardless of how routine or friendly it sounds: an out-of-band callback to a number looked up independently, not a reply in the same chat thread.

Tone is not a risk signal — the request itself is

A casual, friendly, or even mildly impatient tone tells you nothing about whether a request is legitimate. Judge the risk tier from what's actually being requested, and let that — not how it's phrased — decide how much verification it gets.

Hands-On Exercises

Exercise 1

Explain why treating every request with the same level of scrutiny, regardless of risk tier, is described as counterproductive rather than simply "extra safe."

📄 View solution

Exercise 2

Using the Dana from Accounting example, explain why the request is classified as high-risk even though its tone is casual and friendly.

📄 View solution

Exercise 3

Explain why knowledge-based checks like "mother's maiden name" are described as proving only "that the requester knows a fact," not that they are who they claim to be.

📄 View solution

Chapter 4 Quick Reference

Verification effort scales with the risk of the request, not with how suspicious it feels
Callback verification: always an independently-looked-up number, never one the requester supplied
Out-of-band confirmation: confirm through a different channel than the one the request arrived on
Knowledge-based checks (employee ID, birthdate) prove only that the requester knows a fact — not who they are
Judge risk from what's being asked for, never from how the request is phrased or how urgent it sounds
Next: Chapter 5, applying this directly to the Chapter 1 password-reset request