Microsoft’s Q2 2026 threat report says weekly malicious Teams call attempts reached nearly ten times the mid-2025 baseline. That is a telemetry finding—not a forecast that every Teams user is about to receive a scam call. The practical signal is more useful: workplace chat and voice now deserve the same verification habits as email.

At a glance

  • Microsoft observed rising Teams-based vishing during April–June 2026.
  • Technical-support impersonation remained a common lure, but generic display names also increased.
  • Verify unexpected callers through a known company channel; never hand over a sign-in code or install a tool because a caller asks.

Microsoft’s July 23 threat-intelligence review describes a changing second-quarter landscape. The report says weekly malicious call attempts over Teams grew about 80% from the start of 2026 and, by the end of June, ran at nearly ten times the mid-2025 baseline. In the same report, email remained the dominant initial-access channel. Those two details belong together: a sharp rise in one communication channel does not mean the whole threat picture has shifted to calls, but it does show attackers are investing in places where workers feel they are speaking to colleagues.

The company also reports that more than half of Teams-based phishing attempts observed in June used generic display names. That matters because a suspicious caller may not appear as “IT Help Desk” or another obvious impersonation. A plain name, a familiar-looking avatar, or a confident voice can feel routine; none of those alone proves the caller belongs to your organization.

What the numbers say—and what they do not

Microsoft’s Q2 observation Practical reading What it does not prove
Weekly malicious Teams call attempts were nearly 10× the mid-2025 baseline by late June. Teams deserves attention in staff awareness and incident reporting. That an average employee has ten times the personal chance of being targeted.
Observed call attempts increased roughly 80% from January to June. The trend in Microsoft’s telemetry moved upward during that period. That all industries, tenants, or regions experienced the same rate.
Generic display names made up 52% of June attempts. Do not depend on a conspicuous “IT Support” label to spot a lure. That every generic name in Teams is malicious.
Technical-support impersonation remained a leading theme. Unexpected account-fix calls deserve a pause and a separate check. That every support call or helpdesk interaction is a scam.

These are observations from one vendor’s detection systems, not a population-wide survey. Detection coverage, definitions, customer mix, and the volume of calls seen can affect the numbers. Microsoft does not say the statistics represent every Teams tenant. The signal is still useful for IT teams: voice interactions can bypass habits built around suspicious email, and users need a simple way to confirm identity without embarrassing themselves or delaying real work unnecessarily.

Why a voice call creates a different kind of pressure

Email gives people time to reread a request, inspect the address, or forward it to a colleague. A live call adds conversational pressure. Someone may claim that a session is about to expire, a laptop is infected, or a security update must be installed immediately. The caller can ask the employee to share a screen or read a one-time code while staying on the line. The instruction feels like a collaboration task rather than a decision about account access.

Teams can also blur boundaries between internal colleagues, guests, vendors, and people reached through external collaboration. A display name may look familiar even when the identity behind it is not. Attackers do not have to reproduce a perfect technical identity if the story itself persuades a worker to act before checking.

One useful test: if the caller asks you to make a security-sensitive change, stop the live conversation and verify the request using a contact method already in your company directory or approved support portal.

A low-friction verification routine

  1. Ask for the ticket or workflow reference. A legitimate helpdesk should be able to point you to a traceable request. Do not treat a ticket number supplied by the caller as proof; check it in your organization’s system.
  2. End the call before handling secrets. Never read out a password, MFA code, recovery code, or device approval prompt. A real support agent should not need your one-time sign-in code.
  3. Start a new contact path. Use the number, support portal, or employee directory your organization already publishes. Do not use a callback number or link sent during an unexpected call.
  4. Verify the requested action, not only the person. Confirm what tool will be installed, what access it needs, and whether the change is part of an approved process.
  5. Report the attempt quickly. Use the company’s established security-reporting route. Include the display name, time, claim, and any link or tool the caller mentioned; avoid forwarding suspicious content to coworkers as a warning without context.

What an IT team can change before the next call

Security awareness works better when the safe action is also the easy action. A policy that says “verify identity” but provides no quick directory or callback path leaves employees to improvise while someone is pressuring them. Teams administrators and security leaders can make that process concrete:

  • Publish one clearly labeled helpdesk portal and a known method for validating urgent support requests.
  • Teach staff how to report a suspicious chat or call without needing to decide whether it is definitely malicious.
  • Review guest and external-access settings against collaboration needs; removing all outside communication may break work without solving impersonation.
  • Set a consistent rule that staff never disclose passwords or one-time codes to support agents.
  • Give helpdesk workers a script for ending a call and resuming through a verified channel when identity is uncertain.
  • Use short drills based on realistic support scenarios, then improve the workflow when people hesitate or report confusion.

Microsoft’s report also notes that some detected calls were rejected or ended quickly. That is encouraging as an observation, but blocking and filtering do not replace the human verification path. Callers can change names, channels, and pretexts; the organization should make it normal to pause and call back independently.

If you already followed the instruction

Act on what you shared. If you gave a password, change it through the official identity provider and report the event. If you approved an MFA prompt you did not initiate or revealed a one-time code, contact IT immediately so they can check sessions and revoke access. If you installed remote-support software, disconnect from the network if instructed by your security team, and do not try to “clean up” evidence on your own. If you entered payment or payroll information, notify the responsible finance or bank contact through a known channel.

Preserve the meeting or chat details if your organization’s policy allows it. Note the time, caller display name, exact request, and any application you installed or setting you changed. A quick report can help the security team check whether the attempt reached other employees. You do not need to prove that it was a scam before reporting it.

Bottom line

The Microsoft Q2 report is a reason to extend familiar security habits into Teams—not to distrust every coworker or disable voice calls. A caller’s name, voice, or apparent urgency is not the same as verified identity. For account, device, or financial changes, end the call, use a contact route already on file, and confirm the request in the system your organization trusts. That small pause is easier to practice when the helpdesk has made the callback process obvious.

More practical coverage: how to think about personal context and AI assistants and what to check before adopting new hardware.

Sources

End of articleOur method →