Deepfakes Expose Verification Gaps in Corporate Security

The call comes in at 4:40 on a Friday. It's the CFO, or it sounds exactly like her, asking the controller to push a supplier payment out before the weekend because a deal closes Monday.

Gartner, Osterman Research, the FBI, and FinCEN: the signal is clear

The rise of convincing synthetic speech and video is no longer hypothetical. A 2025 Gartner survey of 302 cybersecurity leaders found 62% of organizations had experienced at least one deepfake attack in the prior 12 months; 43% reported at least one deepfake audio call incident and 37% had seen deepfakes on video calls. A January 2026 Osterman Research study, commissioned by IRONSCALES, found 60% of 128 U.S. security and IT leaders lacked confidence in their ability to counter deepfake attacks even with existing training.

Federal warnings reinforce that reality. In May 2025 the FBI advised recipients to confirm identity by calling an independently sourced phone number before acting on requests after noting cloned voices that could sound nearly identical to the real person. FinCEN has alerted finance and compliance teams to generative-AI impersonation in schemes directing employees to transfer funds — a specific red flag is anyone who switches communication methods mid-conversation and blames technical glitches.

Why detection by ear falls short

Traditional awareness training looks for human tells: awkward phrasing, odd sender addresses, or mismatched links. Synthetic voices and real-time face swaps erase many of those signals. As the article notes, asking staff to rely on whether a caller “sounds” fake is increasingly asking too much.

That forces a change in emphasis: process over perception. If employees follow the same verification step every time money, credentials, or permissions are at stake, the quality of the fake becomes far less relevant. A readiness drill tests whether those steps actually happen when someone senior is applying pressure.

Step 1 & 2: Map who attackers will clone — and write the verification rules first

Start with two lists: the identities attackers would impersonate (executives who approve payments, VPs and directors in finance/IT/HR, and outside contacts such as supplier AR leads or a managed service provider engineer) and the people attackers will call (accounts payable, treasury, payroll, HR, executive assistants, IT help desk, and identity admins).

Before testing, document the verification rules. Strong rules the source recommends include:

• Out-of-band callback to a number pulled from the internal directory or vendor master, never a number supplied in the request.
• Clear thresholds that specify which actions always require verification.
• Dual approval for new payees, changed banking details, privileged accounts, and role changes.
• Challenge phrases that rotate on a schedule for frequently impersonated executives and their support staff.
• No-blame reporting so employees report mistakes immediately without fear of shame.
• Explicit permission from the CEO and CFO that nobody gets in trouble for hanging up and calling back.

“Don’t just do something, stand there,” the author advises — a minute of pause and one callback costs nothing; acting on a convincing fake can cost far more.

Step 3 & 4: Design multi-channel scenarios and run them in stages

Real attacks typically span channels: email or chat sets context, then voice or video applies pressure. The article offers four starter scenarios to mirror that chain:

• Urgent wire from the CFO: spoofed email plus voicemail in the CFO’s voice asking for an immediate payment.
• Supplier bank change: vendor message with new banking details followed by a Teams call from the “vendor.”
• Help desk reset: a caller sounding like the VP of sales asks to move MFA to a new phone while traveling.
• Access cleanup: an email announcing permissions review followed by a Teams call that walks an identity admin through changes, with an attack hidden inside routine cleanup.

Run tabletop exercises first to surface policy gaps. Move to live simulations with a small control group briefed (executive sponsor, SOC lead, head of finance), keep money and access in test sandboxes, set stop conditions if participants become distressed or the scenario bleeds into real operations, and always tell participants afterward.

Step 5 & 6: Measure behavior, debrief quickly, fix, and repeat

Measure the behaviors beneath pass/fail. Useful metrics include verification rate, time to escalation, whether reports reached the SOC through expected channels, specific break points (missing directory numbers or unclear thresholds), whether bundled requests hid privilege grants, and trust signals participants cited.

Debriefs should be blameless and immediate. Explain which elements were synthetic, how the fake was built, and which signals could have been checked. Fix the mapped break points: update the callback directory, tighten thresholds, and fold the scenarios into regular phishing simulations so lessons persist. Repeat at least twice a year and whenever the high-exposure list changes.

What this means for finance, help desks, and security teams

Finance and compliance teams: build the FinCEN red flag into practice — watch for mid-conversation channel switches and explicit technical-glitch rationales, and require out-of-band callbacks for bank-detail changes.

Help desks and identity admins: include MFA moves and privileged-account requests in the high-risk list; treat calls from “traveling” executives as routine verifications rather than exceptions.

Security teams and SOCs: run multi-channel drills, measure verification rates and report paths, and consider tooling that flags unusual executive requests or offers real-time identity verification in collaboration platforms — evaluating privacy trade-offs such as whether solutions record or transcribe meetings versus processing signals in the moment.

Start small: two lists, one page of rules, four scenarios, and a debrief template are enough to learn where you actually stand. And start this quarter — the “bad connection” on a Friday afternoon is exactly the moment a drill should catch, not a real incident response.

Original article — The Hacker News (contributed by Audian Paxson, Principal Technical Strategist, IRONSCALES)