Teams plans to spot phishing in the conversation, before the dangerous link

Microsoft is preparing a Teams phishing detector that looks beyond dangerous links and attachments to the context of a conversation. The planned feature focuses on higher-risk exchanges such as an external sender's first contact, where an impersonation attempt can begin with an ordinary-looking request rather than a malicious file. The roadmap points to November 2026; this is a planned rollout, not confirmation that every tenant already has the protection.

The Microsoft 365 roadmap entry, numbered 575288, describes context-aware detection of phishing and social engineering. Reporting on the accompanying Microsoft message adds that the capability is intended for security protection, with warnings when suspicious activity is identified. Administrators should use their own service notices to confirm scope and timing.

A suspicious request can arrive without a suspicious URL

Traditional indicators remain useful: a known malicious address or a dangerous attachment gives a security system something concrete to inspect. Social engineering can begin before either appears. Someone may claim to be support staff, establish urgency and ask the recipient to move to another channel or perform an unusual action.

The relevant signal then lies in the relationship between messages: who is speaking, what they claim and what they want the recipient to do. A familiar collaboration interface can make the exchange feel more internal than it actually is. The software's appearance is not evidence that the sender belongs to the organization.

Context-aware detection is intended to address that gap. It does not establish that the system understands every legitimate business relationship, or that every unusual request is malicious. The quality of the feature will depend on how well warnings distinguish risky behavior from ordinary external collaboration.

The data boundary matters too

Microsoft's reported description limits the capability to security use and says customer message content is not retained by the detection system for model training or secondary purposes. That is a statement about this feature's handling, not a blanket description of every Teams retention, compliance or administrative function.

Keeping that scope precise avoids two opposite mistakes: assuming a security feature authorizes unrelated uses of conversations, or assuming its training statement means the organization has no separate message-retention policies. Administrators need the feature documentation alongside their existing controls.

Verification still needs a route outside the suspicious chat

The practical response to a questionable support request is to use an established organizational contact method, rather than trusting contact details supplied by the same sender. A warning is most useful when it leads to a clear next action that staff can actually take.

The planned change acknowledges that a scam can be carried by a plausible conversation, not just a bad link. Its value will be measured by how well it interrupts that conversation before trust turns into an unauthorized action, while allowing legitimate collaborators to keep working.