Urgent, Plausible, and Fake: Rethinking Identity Verification When a Request Cannot Wait
Identity verification is difficult for a simple reason: the information a genuine requester uses to prove who they are is usually information an attacker could find or infer from publicly available sources. Names, roles, reporting lines, travel plans, and current projects appear on company websites, social profiles, conference agendas, and out-of-office replies.
That is why service desk identity verification, and verification across finance, HR, and every other team that acts on requests, has become one of the most heavily targeted parts of any organization Attackers no longer need to break in when someone will open the door for them.
The two scenarios below target different people through different channels. On the surface they look nothing alike. Underneath, they use the same strategies.
Scenario One: The Payment That Cannot Wait
The request
The CFO takes a call from the CEO. The voice is right. The mannerisms are right. They are saying an acquisition already under internal discussion is moving faster than expected. A deposit needs to clear today and the details will follow by text. It should stay between the two of them until the announcement.
Why it is difficult to refuse
Until recently, recognizing a voice was a reasonable check. Now, deepfake vishing, or voice phishing, scams use AI to clone a real person’s voice and has taken that option away. A usable clone can be produced from any public recording: conference talks, webinars, podcast appearances, and earnings calls are all raw material. Senior executives are the most recorded people in any organization, so seniority increases exposure rather than reducing it.
The request is also constructed to disable the normal checks rather than to evade them. Confidentiality removes the option to seek a second opinion. Urgency removes the timeline to take a moment to pause and think. Plausibility, drawn from something genuinely under discussion, removes the instinct to question it at all.
What defeats it
Two things stop this attack: a second channel the caller did not choose, and an authorization rule that binds everyone, regardless of seniority.
Verification must run against the contact details you already hold, not the number that called and not the number that follows by text. A callback to the CEO’s directory number settles the questions in under a minute. The awkwardness of making that call is precisely the cost the attacker is counting on you not wanting to pay.
The structural control is dual authorization that no single person can complete, and that includes the CFO and the CEO. A control with an exemption for the most senior people provides no assurance over the transactions that matter most, because those are precisely the transactions senior people authorize. If one call to finance is enough to move money, then one call is the level of assurance the organization has.
A recognized voice is no longer evidence of identity. Any process that treats it as authentication has already failed, policy should say so explicitly rather than assume people will infer it. While payment authority sits alongside access to financial systems, it still belongs inside the same access control framework as everything else.
Scenario Two: The Regulator That Is Not
The request
An email is sent to a marketing manager from notice@compliance-gov.com. The message reads as follows.
“Good morning business owner,
This message is to inform you that we have received a complaint against your handling of personal data. Your organisatin is now under investigation by the Information Commissioner’s Office.
Your cooperation during this process is essential to determine your compliance. Click the link to register in our administrative system so that the investigation can begin. Please do so within 48-hours or you may face additional penalties. [REGISTER]
As a reminder, if the investigation proves that your organization is out of compliance, you may be subject to penalties per Article 82 of the GDPR (EUR 20,000,000 or 4% of your annual turn-over, whichever is greater).”
Why it is difficult to refuse
The recipient has probably never dealt with a regulator and has no reference point for what a genuine notice looks like. The message is engineered so the cost of ignoring it appears far higher than the cost of clicking. It invokes an authority nobody wants to challenge, attaches a deadline with consequences if missed, and asks for an action that sounds administrative rather than consequential.
What defeats it
When an unexpected message is received from someone outside your firm, the first step is to verify it through the sender’s published contact route, not the link in the message. No regulator requires registration in an “administrative system” to begin an investigation, and a single phone call to the genuine office would confirm that.
This email is also unusually instructive, because the warning signs do not require a security background to spot:
- The sending domain is not a government domain
- The salutation is generic
- There is a spelling error in the second sentence
- The deadline is short and the consequence is financial, a standard pressure pattern
The legal detail gives it away too. Article 82 of the GDPR concerns compensation for individuals who have suffered damage. The penalty figures quoted come from Article 83. A genuine UK notice would also cite sterling amounts under UK GDPR rather than euros. Attackers copy the numbers without understanding the source, and that is often the detail that exposes them.
Phishing emails are becoming more convincing, and attackers are betting that busy professionals will act quickly on anything urgent. An unexpected or unusual request should always prompt a closer look before any action.
What the Two Have in Common
Different targets, different channels, one shared design. Each request arrives with a deadline attached, invokes an authority the recipient does not want to challenge, and asks for an action that feels administrative rather than consequential.
The same pattern drives the most familiar version of this attack: a caller asking the service desk to reset a password or re-enroll multi-factor authentication, with a convincing reason it has to happen now.
One principle covers all of them: verification has to run against records the organization already holds, never against details supplied within the request itself.
This is why better judgment and more training are not enough on their own. Judgment exercised under time pressure, against someone who has prepared, is not a reliable control. The process has to carry the weight.
Not Every Request Deserves the Same Process
A verification standard that treats a shared meeting room login and a domain administrator account identically will either be too slow for routine work or too weak for the accounts that matter.
Tiering solves this. Standard accounts follow the baseline process. Accounts with elevated privileges, access to sensitive data, or authority over financial or clinical systems require additional verification, typically manager confirmation through a separate channel or in-person validation where practical. The same logic applies to payment authority, where the threshold that triggers dual confirmation should be set deliberately rather than inherited.
Two decisions must be made in advance rather than during a call: which accounts and which actions sit in the higher tier, and who has the authority to decide. Classification should be owned by whoever governs access controls rather than by the people fielding requests. Someone under pressure should be applying a tier, not determining one.
The Refusal Path
This is the part most verification policies omit, and it determines whether everything above actually holds.
Anyone receiving these requests needs a documented route to decline. That route needs three things:
- A clear statement of what cannot be completed without verification.
- An escalation path for genuine urgency, so a legitimate requester who cannot complete the standard process still has somewhere to go.
- An explicit organizational backing that a refusal made in line with the process is never treated as poor service, regardless of the seniority of the person refused.
Without the third element, the first two have limited effect. An analyst who expects a complaint for refusing a senior colleague will usually find a way to say yes. That is a policy question rather than a training one, and it is resolved by leadership stating the position clearly and standing behind it the first time someone senior is inconvenienced.
How to Test Whether Yours Works
A verification standard that has never been tested is an assumption.
The way to find out is a red team exercise. A caller unknown to the desk attempts a reset with a plausible story. You learn whether the callback went to the directory number or the one the caller offered, whether the tier was applied, and whether anyone escalated. It measures what people do rather than what the policy says they should.
A test like that is also the only way to find out whether the refusal path above is real. An analyst can know the process perfectly and still approves the request, because the pressure in the moment is not the pressure in the training room.
What Good Looks Like
An organization handling identity verification well does not refuse everything, and it does not resolve everything quickly. It applies a consistent process regardless of who is asking, records what was verified and how, escalates genuine urgency through a route that exists for the purpose, and treats a correct refusal as the process working.
The urgent request from the CEO is usually genuine. The payment is usually real. Most compliance emails are what they claim to be. The process is not there because most requests are attacks. It is there because the person receiving them cannot tell the difference in the moment and should not be asked to.
How Abacus Can Help
This is not a hypothetical risk. Abacus’ emergency incident response team has repeatedly helped organizations recover from cyberattacks that began with social engineering of support staff to reset passwords or bypass multi-factor authentication. It was among the leading entry routes we saw across 2025, as we covered in our review of last year’s ransomware activity.
Abacus provides service desk and end user support for organizations in highly regulated industries, and service desk identity verification is one of the standards we operate to on behalf of our clients. Our approach to access controls and data protection covers how account tiers are classified and maintained.
If you would like to review how requests of this kind are handled in your own environment, our team is happy to talk it through.