Cybersecurity briefing
/
As AI Makes Impersonation More Convincing, Security Training Becomes More Critical
Teams is adding deepfake warnings and ASOS blames a trusted-contact impersonation. Training must teach employees to verify and report before certainty.
/
AUTHOR
Jeff Dyer
/
SHARE THIS ARTICLE
Overview
A familiar face on a video call can make an unusual request feel routine. As synthetic audio and video become part of the impersonation threat, employees have to judge more than whether a message looks suspicious. Two developments reported on October 8 expose different sides of that problem: Microsoft is preparing new meeting protections, while ASOS has linked a breach to someone posing as a trusted contact. Both raise a question that security teams can no longer leave to an annual training module: what should an employee do when the person seems credible, but the request has not been verified?
The workplace has become an impersonation channel
BleepingComputer reports that Microsoft plans to bring third-party deepfake detection and impersonation protection to Teams meetings. The roadmap describes detection signals from supported providers and warnings about potentially deceptive participants. Availability is planned for November; these are forthcoming capabilities, not protections organizations should assume are deployed today.
The development matters because a warning still leaves someone with a decision. A participant may be flagged during a legitimate meeting. A suspicious request may arrive without a warning. Employees need an established way to pause, verify the person's authority, and involve security without having to diagnose manipulated media themselves.
The ASOS disclosure provides a separate example of how trust can be exploited. In a customer notification obtained by BleepingComputer, the retailer said an attacker impersonated a trusted contact, obtained an employee's credentials, and accessed information on third-party platforms. The investigation remains underway. The reporting does not establish that AI was involved, and the incident should not be described as a deepfake attack.
Its relevance is the underlying decision: familiarity was not sufficient evidence that a request was legitimate. AI-assisted impersonation makes that distinction more important, but the verification problem already exists without it.
Recognition alone is an unreliable burden
Much awareness advice asks employees to notice something wrong: unusual wording, an unfamiliar address, an implausible request. Those clues remain useful. They cannot be the entire basis for authorizing access or releasing information, particularly when a message is polished and the purported sender is known.
An employee should not need to establish that a caller is an impostor before declining to share a security code. A finance employee should not need to detect a synthetic voice before independently confirming a change to payment instructions. The relevant question is whether the requested action satisfies the organization's verification procedure.
That procedure has to be usable. Calling a number supplied by the person making the request does not provide independent confirmation. A better route is a previously established contact, an internal directory, or the company's documented support process. For consequential transactions, the second approval should come from someone who can verify the business purpose through a separate route.
These requirements apply to executives as well as junior staff. A senior leader who treats verification as an inconvenience makes the procedure harder for everyone else to follow. Training works against the organization's own habits if urgency or rank routinely overrides it.
Security findings should change what employees practice
The security team often learns about a new lure before the training program reflects it. A reported message, a confirmed impersonation attempt, or an investigated identity alert can reveal the specific decision employees are being asked to make. Translating that evidence into a useful exercise is different from circulating another warning about phishing.
Consider an illustrative case in which someone poses as IT support and asks an employee to authorize remote access. The lesson should use the organization's actual support procedure, explain how legitimate requests arrive, and give the employee a clear alternative when the caller applies pressure. People with administrative access may need a different exercise from employees who cannot install software. The scenario is hypothetical, but the design principle is practical: the training should reproduce the decision, not merely the appearance of the lure.
ShieldLink's Security Awareness AI documentation describes generating role-specific lessons from employee risk profiles and connected identity, collaboration, and security signals. It also supports company knowledge and technology profiles, subject-matter review, and targeted microlearning. Its attack simulation capabilities include voice and deepfake scenarios alongside phishing. Those capabilities offer a way to build exercises around the systems employees use and the requests their jobs expose them to.
The quality of that approach depends on the inputs and review. A suspicious sign-in is a reason to investigate, not proof that an employee made a mistake. Confirmed findings can inform training, while unnecessary personal details should be removed. The specific signal sources and automated assignment rules need validation against the organization's supported integrations. Nothing in the Teams announcement establishes a direct connection between its forthcoming detection signals and ShieldLink.
Reporting must be possible before certainty
Even a well-prepared employee will sometimes be unsure. A reporting process that effectively demands proof delays the security team's opportunity to investigate. Employees need permission to report a concern, including after they have clicked, disclosed information, or approved something they now question.
The instructions should be concrete: where to report, what information to preserve, and whom to contact if the usual channel is unavailable. A report should capture the requested action and what the employee actually did. Security responders can then decide whether containment, account review, or another response is needed.
Training measures should reflect those decisions. Completion records establish that a lesson was delivered. A simulation can also test whether someone used an independent verification route, withheld a credential, or reported promptly. A single click rate provides a narrower picture and should not become a public ranking of employees.
Organizations can begin by selecting one consequential workflow, such as help-desk access recovery or supplier payment changes. Check whether the verification procedure is clear, rehearse a credible impersonation attempt, and make reporting easy. Use the findings to improve both the procedure and the next exercise. As impersonation improves, employees need more than a demand for vigilance. They need practiced responses that remain useful when appearances cannot be trusted.
