How to Run Phishing Awareness Training When Your Team Is Fully Remote

The cheapest phishing control most companies ever had was the colleague at the next desk. Someone got an odd invoice, turned their chair, asked whether it looked right, and a large share of attacks died there without anyone logging a ticket. Remote work removed that check for most knowledge workers. Gallup’s May 2026 measurement found that among US employees whose jobs can be done remotely, 52% work hybrid, 26% work exclusively remotely and 22% work fully on-site. Those are shares of remote-capable employees rather than the whole workforce, but they describe exactly the population a phishing awareness programme is built for.

At the same time, the attack moved off the channel that awareness training was designed around. The 2026 Verizon Data Breach Investigations Report found that 41% of social engineering breaches involved vectors other than email. Palo Alto Networks’ Unit 42, writing in June 2026, reported that “in the first four months of 2026, phishing alerts from collaboration tools represented 42% of all phishing alerts in Cortex, up from 30% of all phishing alerts in the preceding four months.” For a distributed team, the collaboration tool is the office and the phone is the hallway, and both are now where attackers show up.

So this article goes through the controls that CISA, the FBI and the UK’s National Cyber Security Centre agree on, one at a time: what each control says, how to train it for a team that never shares a room, and how to test that the training actually worked.

Why remote phishing awareness is a procedures problem

The strongest evidence on phishing training is sobering. A randomised controlled trial at UC San Diego Health, published at the 2025 IEEE Symposium on Security and Privacy, ran monthly simulations against more than 19,500 employees for eight months and found that embedded training reduced failure rates by 1.7% on average against the control group. Engagement explains much of that result: between 37% and 51% of training sessions lasted zero seconds, and only 15% to 24% were completed. The NCSC is blunt about the ceiling in its guidance on defending your organisation from phishing: “No training package, including phishing simulations, can teach users to spot every phishing attempt.”

The authorities don’t ask for recognition alone. CISA’s joint phishing guidance pairs user training with phishing-resistant MFA and reporting. The FBI’s IC3 pairs it with secondary-channel verification for payment changes. The CISA and FBI advisory on Scattered Spider pairs it with help desk procedures. The pattern is consistent: training teaches a procedure, and the procedure is what protects you when recognition fails.

Recognition is also getting harder to teach. The one peer-reviewed measurement of AI-generated phishing, a Columbia, University of Chicago and Barracuda study presented at ACM IMC 2025, found that attackers mostly use language models to fix grammar and spelling rather than to change strategy. Grammar and odd phrasing were the cues legacy training taught, and they no longer separate a phish from a real message.

For a remote team this all points the same way. The thing you can train, rehearse and measure is the procedure: what to do, in which channel, when a request can’t be checked in person.

Verify every payment and bank-detail change through a second channel

The FBI’s control fits in one sentence, from its September 2024 public service announcement: “Use secondary channels and/or two-factor authentication to verify requests for changes in account information.” Earlier IC3 guidance spells out what the secondary channel means: call a number already known to the business, taken from internal records, never one supplied in the message.

Remote work is where this control breaks down, because the classic verification step was walking over to the person who supposedly sent the request. Attackers now pre-answer that step. Microsoft Threat Intelligence’s write-up of a campaign that ran 3 to 5 August 2026 describes more than 1,000,000 emails, 87.7% of them aimed at US organisations, each asking for an ACH transfer of around $50,000 against a fake annual ServiceNow subscription invoice. The distinctive element was a fabricated forwarded thread in which the impersonated CEO appeared to have already corresponded with the vendor and approved the payment. For a remote finance clerk who would have to message or call the CEO to check, the fake thread makes skipping the check feel reasonable. The lookalike domains were registered on 31 July 2026, three days before the campaign began.

The money at stake is not abstract. The FBI’s 2025 Internet Crime Report recorded $3.05 billion in business email compromise losses from 24,768 complaints in a single year.

So the written procedure for a remote finance team looks like this. Any request to pay a new payee or change bank details triggers a callback to a number from internal records, regardless of what any forwarded thread appears to show. New payees and changed details need dual approval from two people. And the same rule applies when the request arrives on a video call, because a live face is a channel, not a verification. Our parent article on preventing business email compromise walks through the wider payment-control framework this sits inside.

A callback rule is a document until someone tests it under pressure, and the failure point is the clerk who skips the callback because the caller sounds senior and in a hurry. Well, that’s testable. For example, Brightside’s vishing simulator can run a Voice + BEC attack against the finance team: the fake invoice email combined with a live AI call from a persona posing as the supplier or an executive, built on the fraudulent invoice approval goal, appealing to authority and applying pressure through risk. What comes back is a failed rate for that group, per campaign and as a 7, 30 or 90-day trend against a baseline round. Vishing sits on the Pro tier or the Voice add-on.

Make “IT never messages you first” a rule people can check

Microsoft’s April 2026 write-up of a cross-tenant intrusion states the trend plainly: “Threat actors are increasingly abusing external Microsoft Teams collaboration to impersonate IT or helpdesk personnel and convince users to grant remote assistance access.” The employee is talked into opening Quick Assist or a similar remote-support tool, the attacker takes the session, and a nine-stage chain follows through to data exfiltration. The earlier version of the same playbook, Storm-1811’s 2024 campaign, opened with an email flood followed by a phone call from “IT” offering to fix the spam problem, and ended in Black Basta ransomware.

The detail that should land with anyone running awareness training: Teams showed the user several warnings along the way, including external Accept and Block screens, phishing alerts, external-organisation labels and URL warnings. The attack succeeded because the user clicked through them. People are simply less conditioned to doubt a chat message than an email.

The platform controls come from Microsoft and Unit 42: restrict external chat to allowed domains, keep external labels visible, and let users report suspicious Teams messages. Then extend training beyond email, because the collaboration tool is where remote staff actually meet strangers.

The staff procedure is one sentence: IT does not start contact in an external chat. If a message claiming to be from IT arrives, the check is to contact the help desk through the known internal route, and the hard rule is to never open Quick Assist or any remote-support tool on an unsolicited request. That rule is checkable in a way “be suspicious of urgent messages” never was.

Harden the help desk and train for vishing on both sides of the call

The CISA and FBI advisory on Scattered Spider, AA23-320A, describes a group that worked the phone in both directions. The attackers “posed as company IT and/or helpdesk staff using phone calls or SMS messages to obtain credentials from employees,” and, in the updated version of the advisory, “posed as employees to convince IT and/or helpdesk staff to provide sensitive information, reset the employee’s password, and transfer the employee’s MFA to a device they control.” The same advisory tells organisations to “perform diligent employee training against vishing and spearphishing.”

Both directions hurt more in a remote company. The employee can’t walk over to IT to check a caller, and the help desk can’t see the person asking for a reset. Mandiant’s M-Trends 2026 found vishing was the single most common initial vector in cloud compromises at 23%, ahead of third-party compromise, stolen credentials and email phishing. That figure is specific to cloud-environment intrusions rather than all breaches, but cloud environments are where remote teams live. Regulators are catching up too: the New York Department of Financial Services issued a vishing advisory on 6 February 2026 describing actors “posing as IT help desk staff in calls to personnel in order to steal login credentials” and MFA codes.

There’s also a deadline that will make this worse before it gets better. Microsoft has announced that Entra ID will discontinue native SMS and voice delivery of MFA codes on 1 February 2027. Every organisation still on those methods will run an enrolment and recovery wave through its help desk, which is precisely the process Scattered Spider targets.

The help desk procedure has three parts. Identity checks for resets rely on something an attacker can’t find online, which rules out employee IDs, manager names and start dates. Any password or MFA reset is confirmed by a call-back to the number on record. And no MFA device change is ever approved on a single channel, however urgent the caller sounds.

Training the employee side of this is where the advisory’s vishing line gets concrete. Brightside’s vishing simulator places a live AI call from a help desk persona carrying context such as a ticket number, working toward the 2FA phishing link goal, and the agent holds a real conversation and adapts to what the employee says. Admins can preview and take the call in the browser and receive a test launch before anyone else hears it. Because the audience can be any employee group and the persona is free text, the same simulator can run a caller posing as an employee against the help desk team itself. The vishing dashboard reports failed rate, answer rate and median call duration, with the failed-rate trend over 7, 30 or 90 days.

Put phishing-resistant MFA in place so one mistake is survivable

CISA’s phishing guidance asks organisations to implement “FIDO or PKI-based MFA”, which it calls “phishing resistant”, to use number matching where only push-based MFA is possible, and to centralise logins through single sign-on, which “can reduce the chance of users being socially engineered to give up their login credentials.”

This matters more for a remote team than an office one, because every login already happens over the internet to a SaaS tool. There’s no network boundary left to catch the ones that go wrong. Phishing-resistant MFA is what makes a single distracted click survivable instead of fatal.

What it doesn’t cover is why the other controls in this article stay. Device code phishing sends the victim to a genuine Microsoft sign-in page to type in an attacker-generated code, so authentication succeeds with real credentials and real MFA; Push Security recorded a 37.5-fold increase in device code phishing pages by April 2026, and a passkey doesn’t stop it. A fake invoice needs no credential at all. A help desk reset happens after authentication. And a remote-support session the user agrees to open hands over the whole session. We have a separate guide on how vishing gets past MFA through the help desk route. MFA closes the credential path. The procedures above cover everything else.

Make reporting one click, and measure how fast it happens

The NCSC asks whether your reporting process is “clear, simple and quick to use”, and it’s equally direct about culture: “Don’t reprimand users who are struggling to recognise phishing emails. Users who fear reprisals will not report mistakes promptly, if at all.” CISA calls reporting suspicious phishing activity “one of the most efficient methods for protecting organizations.”

Reporting is also where training shows a measurable effect. The 2025 Verizon DBIR found that users who had recently completed training reported phishing at around 21%, against a base rate of about 5%. That’s a reporting rate rather than a click rate, and it’s the number that matters for a distributed team, because reports are what let a security team pull a campaign from other inboxes before it spreads. The one public phishing test at an all-remote company makes the gap concrete: in 2020, GitLab’s red team sent a fake laptop-upgrade email to 50 employees, and 17 clicked the link, 10 of those entered credentials, and 6 reported the email. One in five handing over credentials at a security-literate, remote-by-design company is a fair picture of the baseline.

Time to report is arguably the remote metric, because it’s the one human signal that arrives before the damage. Click rate, the traditional number, is easy to corrupt: automated link scanners, safe-link rewriting and mobile previews all inflate it, and a remote workforce maximises all three. We wrote about measuring behaviour rather than completion in more depth separately.

The NCSC’s “clear, simple and quick” test is a design spec, and the way to meet it is to put the report button where the email already is. Brightside’s Report Phishing add-on puts a one-click report in the Gmail side panel on the web and on Android. A reported simulation counts as a catch in the employee’s stats, and a reported real attack reaches the security team within seconds with the original email and headers intact. Brightside then reports report rate and time to report per employee, group and campaign, so the metric this section argues for is the one you actually get.

Run simulations people will still trust next quarter

The NCSC warns that simulations can create legal risk and advises involving HR before running them. The canonical cautionary tales are lures that exploited staff goodwill: West Midlands Trains sent a fake Covid bonus email to 2,500 staff in 2021, and GoDaddy sent a fake holiday bonus during layoffs in 2020. Both drew public anger. A vignette experiment presented at USEC 2025 alongside NDSS found that simulations built on bonus incentives or severe personal consequences caused significant backlash and lasting damage to trust.

Remote teams add a consent question on top. A simulated SMS or voice call to a personal phone reaches the employee outside work, which raises data-protection and works-council issues, particularly in the EU. Get consent before any simulation touches a personal device.

No lures built on pay, bonuses or job security, ever. Follow up a failure with a lesson that teaches, not a message that shames. And remember the connection to the previous section: a team that feels tricked stops reporting, and reporting is the signal the whole programme depends on.

Rehearse in the channels and hours remote people actually work

CISA’s training recommendation and AA23-320A’s vishing-and-spearphishing line amount to the same instruction: drill the channels attackers use, which for a remote team means the phone and the chat window alongside the inbox. The drill data supports broadening out. The 2026 DBIR found voice phishing simulations had a median click rate of 2% against 1.4% for email simulations; those are simulation numbers rather than breach numbers, but the direction matches the shift in real attacks. Microsoft reported a 146% rise in QR-code phishing among the 8.3 billion email phishing threats it analysed in the first quarter of 2026.

Lure choice matters as much as channel. The UC San Diego trial found a seventeen-fold spread in failure rates across lures, from 1.8% for an “Outlook Password” pretext to 30.8% for a “Vacation Policy” one. Internal HR and policy notices are exactly the messages a remote employee can’t check with a colleague, which is why they work. Hoxhunt’s 2026 Phishing Trends Report, a vendor dataset, found spoofed internal HR and IT notices were the most-clicked simulation theme at a 7.4% failure rate.

Cadence beats depth. Short, regular rehearsals in the channels people actually use teach more than an annual module, and the UC San Diego engagement figures show what happens to training nobody looks at.

Then there’s the detail office programmes never think about: time zones. A simulation that lands at 2 a.m. local time teaches nothing, and one that lands for the whole team at once just teaches colleagues to warn each other in chat. This is the mechanical part Brightside handles by default. Brightside sends simulations only within the workspace’s working days and business hours, staggers delivery randomly so colleagues can’t warn each other, and can translate email attacks automatically into each employee’s own language. An employee who clicks or enters credentials before reporting immediately sees the exact email that fooled them with every red flag highlighted.

Treat personal phones and home devices as part of the attack surface

NIST’s telework guide, SP 800-46 Revision 2, holds that telework client devices, including personally owned ones, should carry the same baseline security controls as office devices. In practice that’s rarely true of a personal phone, and attackers know it. QR codes and SMS lures exist largely to move the victim from a managed laptop to an unmanaged phone, where link previews, URL inspection and security tooling are weaker. The FBI’s advice in its BEC guidance is to verify the sender’s address “especially when using a mobile or handheld device”, which is the device remote staff most often read email on outside working hours.

The practical rules for remote staff are short. Open work links on managed devices where possible. Never approve an MFA prompt that a message or call asked for. And make sure reporting works from the phone too, because that’s where the suspicious message increasingly arrives.

Front-load training for new remote hires

NIST’s SP 800-50 Revision 1, the guide to building a cybersecurity learning programme, names new-hire training as a distinct part of the programme alongside regular and role-based training. For remote teams the first weeks carry extra risk, because new starters meet their colleagues through a screen and can’t yet tell a normal request from an odd one. Keepnet’s 2025 new-hire report, drawn from 237 companies, claims 71% of new hires fail a phishing test within their first 90 days. That’s vendor data without a published method, but the direction fits everything else in this article.

What to cover before broad access comes straight from the earlier sections: the payment callback rule, how IT and finance really contact people, the help desk reset procedure, and how to report. None of it requires the new starter to recognise anything, only to know the procedures.

Remote hiring is also its own attack surface now. CrowdStrike reported that North Korean IT workers tracked as FAMOUS CHOLLIMA infiltrated more than 320 companies in twelve months, a 220% year-on-year increase, using AI-written CVs and deepfaked video interviews. The figure is vendor-reported, but the mechanism is well documented: in a remote company the hiring pipeline is an identity-verification process, so recruiters and hiring managers need the verification procedures too.

NIST’s new-hire line is easy to write into a policy and tedious to run by hand, since the audience changes every week. Brightside’s ready-made dynamic group of new hires from the last 90 days updates itself from employee data, and every workspace includes a New employee onboarding curriculum with deadlines and automatic reminders. Courses are chat-based, guided by Brighty, the interactive learning companion, and run in English, French, German, Italian and Spanish. What the admin sees is completion and overdue courses per employee and group, so the new-hire procedure is tracked the same way as everything else.

FAQ

How can I train my employees about phishing?

Teach procedures rather than recognition: how to verify payment changes through a second channel, how IT really contacts people, how to report a suspicious message. Then rehearse those procedures with simulations in the channels your team actually uses, and measure report rate and time to report rather than completion.

What is the strongest defense against phishing?

No single control is enough, which is why CISA, the FBI and the NCSC all recommend the same pairing: phishing-resistant MFA (FIDO or PKI-based) to close the credential path, out-of-band verification for payments and account changes, and easy, blame-free reporting so attacks surface fast.

How can employees protect their devices when working remotely?

Open work links on managed devices rather than personal phones, since QR codes and SMS lures exist to move you onto weaker tooling. Never approve an MFA prompt a message or call asked for. Keep reporting within one click on whatever device the message arrived on.

What are the top 3 best practices for avoiding phishing attacks?

First, verify any payment or bank-detail change by calling a number from internal records, never one from the message. Second, treat any unsolicited contact from “IT” as unverified and check it through the known internal route. Third, report suspicious messages immediately, and make sure nobody fears reprisal for a mistake.

The colleague at the next desk isn’t coming back for remote teams. What can come back is the check itself, written down as a procedure and rehearsed until it holds under pressure. Get the procedures right first, and let recognition support them. That’s the order the authorities recommend, and it’s the order that survives contact with a real attacker.