Cybersecurity
Updated
A polished message is not evidence that it is safe. In 2026, staff need a repeatable way to evaluate requests that arrive through email, text, QR codes, phone callbacks, shared documents, and real accounts that have already been compromised. The goal is not to turn every employee into a threat analyst. It is to make pausing, verifying through a separate channel, and reporting easy enough to use during ordinary work.
Recent Microsoft investigations show why spelling and branding checks are insufficient. One 2026 campaign used a multi-stage flow, legitimate-looking services, authentication prompts, and adversary-in-the-middle infrastructure to capture session tokens. Another used compromised trusted identities and SharePoint-themed messages before follow-on business email compromise. These are specific observed campaigns, not a claim that every phishing message uses the same technique. See Microsoft's May 2026 AiTM analysis and January 2026 SharePoint and BEC analysis.
Judge the request, not its appearance
Ask what the sender wants you to do. High-risk requests commonly involve signing in, scanning a code, calling an unfamiliar number, installing software, approving an authentication prompt, changing payment instructions, sharing sensitive information, opening an attachment, or bypassing a normal process. A message can come from a real vendor or coworker account and still be malicious. The FBI describes business email compromise as a request that appears to come from a known source and advises independently verifying payment or account changes. See the FBI's business email compromise guidance.
Use a trusted contact path that you already possess: a number in the approved vendor record, an internal directory entry, a known portal opened independently, or an in-person conversation. Do not verify a suspicious request by replying to the same thread, calling the number inside it, or using a link it supplied. Verification tests the request through a different channel; it is not a debate with the sender.
Recognize five phishing patterns
1. Message and document-share lures
The lure may imitate a routine invoice, voicemail, e-signature request, password notice, HR document, or shared file. Look for a request that is unexpected in context, changes a known procedure, creates urgency, or asks for authentication after a path you did not initiate. Inspecting a visible address can help, but it cannot establish safety when an account or legitimate service has been abused.
2. QR-code detours
A QR code moves inspection from the managed email screen to a phone and hides the destination until it is scanned. The FTC warns that QR codes delivered by unexpected email or text can lead to spoofed sites or malware and recommends using a known contact route when a message might be legitimate. See the FTC's QR-code phishing guidance. Treat a code as a link, not as proof of a secure process.
3. Callback and phone-transfer lures
Some messages contain no clickable link. They manufacture a subscription, invoice, security warning, or service problem and tell the recipient to call. The person answering may request remote access, payment, a code, or a sign-in. Stop and locate the organization's verified number independently. A familiar area code, caller ID, or professional greeting does not validate the caller.
4. Adversary-in-the-middle sign-in flows
An AiTM phishing page can proxy a real authentication experience and capture session material after the victim completes a sign-in. That means a familiar login screen and completion of a non-phishing-resistant authentication step do not prove the original link was safe. Employees should report the event even if the sign-in appeared to succeed. Responders may need to review and revoke sessions and investigate mailbox or account changes; Microsoft's 2026 SharePoint analysis specifically notes that a password reset alone was insufficient in the observed campaign.
5. Messages from compromised accounts
A real account can send a malicious request in an existing thread, use a valid signature, or refer to authentic work. The strongest clues are changes in behavior or process: a new bank account, an unusual document, an unexpected secrecy request, a different approval path, or a request that conflicts with known policy. Verify the transaction, not merely the identity displayed in the message.
Use this triage and reporting matrix
Publish the matrix where staff can use it without deciding whether an event is technically an "incident." Customize the response channel and urgency to the organization.
- Suspicious, no interaction: do not click, scan, call, reply, or forward normally. Use the approved report button or reporting address. Preserve the original message and note the business context.
- Link opened or QR scanned, no information entered: stop interacting and report promptly. Record the device, approximate time, and what appeared. Do not erase evidence unless responders direct it.
- Credentials, code, or approval entered: contact the designated security or support path immediately using a separate channel. State exactly what was entered and whether a sign-in completed. Do not assume changing only the password ends a stolen session.
- Attachment opened or software installed: stop work, disconnect only if the approved procedure instructs it, and call the response channel. Identify the file and device; do not continue exploring it.
- Payment or sensitive data sent: alert security, leadership, and the appropriate finance, privacy, or legal owner immediately. For a transfer, the FBI advises contacting the financial institution promptly and reporting BEC to IC3.
- Message came from a real internal or vendor account: report it as possible account compromise and verify through a known path. Warn affected parties through the approved communications process, not by replying to the suspect account.
Design reporting for fast, useful context
The 2025 joint CISA, NSA, FBI, and MS-ISAC phishing defense guide provides organizational recommendations for disrupting the phishing attack cycle, but each organization must publish its actual internal channel. A good report captures the original message, time, sender, recipient, requested action, interaction taken, device, account used, information disclosed, and related payment or document. Staff should be able to report uncertainty without punishment for a good-faith mistake.
The response owner should acknowledge receipt, give immediate instructions, preserve relevant evidence, identify other recipients, review identity and mailbox activity when warranted, and close the loop with the reporter. The FTC's small-business cybersecurity guidance provides additional planning resources. External reporting does not replace the organization's internal response process.
Coach decisions instead of memorized clues
Use short exercises built from the organization's real workflows: a vendor payment change, a QR-code benefits notice, a callback invoice, a shared document from a compromised partner, and an authentication prompt after a link. Ask participants to identify the requested action, choose a separate verification route, and submit a complete report. Avoid publishing failure-rate benchmarks as universal targets. Measure whether reporting paths work, high-risk requests receive independent verification, reports contain useful context, and responders provide timely closure.
Related security guides
Pair employee reporting with the MDR decision guide for monitoring and escalation ownership, the credential abuse prevention guide for account controls, and the password risk guide for authentication hygiene. Those controls limit impact; they do not remove the need to recognize and report suspicious workflows.