Nobody in your finance team is going to be tricked by a badly written email any more. They will be tricked by a phone call from a voice they recognise, on a Friday afternoon, about a supplier they really do work with, referencing an invoice number that really does exist. The firewall never gets a vote.
Deepfakes attack your process, not your perimeter
A cloned voice does not exploit a vulnerability. It exploits a workflow that quietly treats recognition as authentication. If a payment can be released, a bank account changed or an MFA token reset because somebody sounded right and sounded senior, then your network controls were never part of that decision at all.
This is why the usual security spending does not help here. Endpoint protection, patching and email filtering are all worth doing, and none of them are in the room when a manager approves a payment because the CFO called and asked. Synthetic voice and video are cheap, fast and more than good enough over a compressed phone line, and the raw material is public: conference talks, podcasts, webinars, social video, a voicemail greeting. Track the trend through the ENISA Threat Landscape rather than vendor marketing.
How a voice or video attack is actually run
Reconnaissance first, pressure second. The attacker learns your reporting lines, your suppliers, your finance calendar and your internal vocabulary, often from a mailbox they already control. Then they place a call that arrives carrying correct context: the real project name, the real supplier, the real invoice reference, the real name of your accounts payable clerk.
The mechanics are consistent:
- ▸Context acquisition. Public sources give the org chart and the voice samples. Account access gives the rest, usually via credential stuffing against reused passwords or an infostealer that lifted session cookies from a browser, letting the attacker read live threads without triggering a login alert. Checking your domain's exposure on Have I Been Pwned is a five minute starting point.
- ▸Pretext construction. The request is always plausible and always slightly outside normal process, with a reason: an acquisition under NDA, a supplier changing banks after a merger, a locked out executive travelling abroad.
- ▸The three levers. Authority, urgency and secrecy, applied together. Authority stops questions. Urgency stops verification. Secrecy stops the target asking a colleague, which is the one behaviour that would end the attack.
- ▸The channel. A phone call, a voice note, or a short video meeting with a convenient excuse for poor quality, where the deepfake only needs to hold up for two minutes before the conversation moves to chat.
The helpdesk variant matters just as much as the finance one. A convincing call to IT asking for an MFA reset hands over an identity, and identities are what ransomware crews buy and use. The playbooks published under CISA Stop Ransomware exist because that chain, social engineering to remote access to encryption, is the standard route.
Your approval workflow was written for a pre-AI world
Most finance and IT approval processes were designed when faking a voice needed a studio and faking a face needed a film crew. They encode assumptions that are now purchasable: that a familiar voice is proof of identity, that a reply inside an existing email thread is proof of continuity, that a face on video is proof of presence.
Look for these lines in your own procedures, because attackers already have:
- ▸A single approver above a meaningful threshold. One human, under pressure, is the whole control.
- ▸"Verbal confirmation from a director is sufficient." This sentence is a licence for a cloned voice.
- ▸Email as the channel of record for bank details. A compromised mailbox turns your process into the attacker's process.
- ▸A documented exception for the CEO or the owner. The most dangerous clause in any policy, and the first one an attacker will invoke.
- ▸Helpdesk identity checks based on knowable facts. Name, date of birth, employee number and manager are all discoverable, so they verify nothing.
Out-of-band verification, done properly
Verify the request through a different channel, using contact details you already hold, with the call initiated by you. Not the number in the email signature, not the number the caller offers, not a reply in the same thread. Call back on a number stored in your vendor master, and make it mandatory for a defined class of actions.
The detail is where this usually fails, so be specific in your procedure:
- ▸Maintain the callback directory separately from the request channel, and treat changes to that directory as a controlled action in their own right.
- ▸Never verify while the caller is still on the line. Hang up, then dial. Attackers will offer to stay on hold, which is the tell.
- ▸Use a rotating code phrase for executive requests, agreed in person and never stored in email, chat or the CRM.
- ▸Apply a hold period to new payees and changed bank details, long enough that a callback can complete during working hours.
- ▸Log the verification. Who called back, on which number, and what was confirmed. A verification nobody recorded did not happen.
Dual control and thresholds, the boring controls that survive
Two people, two devices, two channels. Dual control works against synthetic media because the attacker must now compromise two independent humans in real time while keeping the story consistent for both. That is dramatically harder than pressuring one person who has been told to keep it confidential.
Set thresholds by the risk of the action, not by the seniority of the requester. The actions worth splitting across two people include creating a new payee, changing existing bank details, releasing payments above a threshold, resetting MFA, granting administrator permissions, changing DNS or domain registrar settings, and creating mailbox forwarding rules.
Separate the roles too. Whoever creates a payee must not be the person who releases payment to it. Cap what a single approval can move, so a successful attack is a bad day rather than a solvency event. Delay the first payment to any new payee, because time is the control that lets a callback catch up with the attacker.
Identity hardening removes the attacker's script
Deepfakes usually ride on top of an account compromise, because the attacker needs your context to sound credible. Harden identity and you take away the invoice numbers, the thread history and the internal vocabulary that make the call work. Without those details, the pretext collapses into a generic scam that people already refuse.
Phishing-resistant MFA is the highest value move here. Hardware security keys and passkeys defeat both credential replay and real time relay attacks, which is why CISA guidance on implementing phishing-resistant MFA is worth handing to whoever runs your identity provider. Then close the gaps around it: shorten session lifetimes, bind sessions to devices, revoke tokens on suspicious sign in, and alert on new mailbox rules and forwarding.
Treat the helpdesk reset path as part of your MFA design, not as a support convenience. Every strong authentication scheme has a recovery process, and the recovery process is where attackers aim. Governance, roles and escalation paths for this scenario are what the NIST Cybersecurity Framework is for.
Put the verification in the software, not in a policy PDF
A control that depends on a stressed human remembering step four will fail on the worst possible day. Encode it in the system instead. The payment screen refuses to release funds to a new payee until a callback record exists. The helpdesk tool refuses an MFA reset without a second approver. The workflow enforces the hold period automatically.
This is where legacy software becomes a security problem rather than an inconvenience. Older accounting and ERP systems often cannot express rules like "two approvers, one of whom did not create the record". So the process gets pushed out into email threads and spreadsheets, which is precisely the terrain the attacker chose. If you cannot change the core system, put a thin approval service in front of it and make that service the only way payments get released, an approach we walk through in Escaping SaaS: The Complete Guide to Migrating Your Business to Custom Software.
Keeping those controls working is operational, not a one off project: permissions drift, thresholds get raised for a busy month and never lowered, staff change roles. That review cadence belongs in the same place as your other recurring security work, which we set out in What Website Maintenance Should Actually Include (and What You Are Probably Paying For).
Train refusal, not detection
Stop training staff to spot deepfakes. The visual and audio artefacts people are taught to look for (odd blinking, flat intonation, blurred edges) vanish with each model release, and detection tools lag the generators. Train the one behaviour that keeps working: any request touching money, credentials or access gets verified out of band, whoever appears to be asking.
Make refusal socially safe, because that is the real control. If an employee makes the CFO wait ten minutes for a callback, the CFO thanks them publicly. One executive who reacts badly to being verified will undo a year of training in a single meeting.
Rehearse it rather than quizzing it. Run a simulated urgent call against finance and the helpdesk, with consent from leadership, and measure time to verification rather than pass or fail. Give everyone who can move money a one page decision card: what triggers a callback, which number to use, who to escalate to, and what to do in the first hour if a payment already left (call the bank, request recall, preserve recordings and logs). Pair that with the hygiene in The Small Business Website Security Checklist for 2026, so the account takeover feeding these calls gets harder too.
How TuniCyberLabs helps
We rebuild approval workflows so the control lives in the software: enforced dual control, callback verification recorded against the transaction, hold periods on new payees, and audit trails that survive a dispute. We harden the identity layer around it and we rehearse the scenario with your finance and helpdesk teams.
Send us your current payment approval process and we will tell you exactly where a cloned voice gets through: book a review with our team.