Microsoft Teams in 2026: New Features and Security Reports

TL;DR

• Three of the four client features in this article had not finished rolling out when it was written, and one of them was described wrongly. Corrections below.
• The durable story is not the features. It is the Security detections report in the Teams admin center — impersonation, malicious URL, and weaponizable file detections in one place.
• User reporting is two settings in two portals. The Teams half is on by default; the Defender half is on only for tenants created recently. Most established tenants are silently missing half the pipeline.
• You cannot proactively submit a Teams message to Microsoft. A user has to report it first. That single constraint shapes your whole Teams SOC workflow.
• The External domain anomalies report needs no Defender licence at all — and its alerts are off by default.

Corrections since this article was first published

This article was written in June 2026 from release-wave announcements. Feature announcements are not shipping dates, and three of these moved.

• "Redesigned toolbars" was wrong. There is no chat or compose toolbar redesign. The real item is the meeting toolbar (roadmap 560321), which lets you pin, unpin, and reorder meeting controls, groups Raise Hand under Reactions, and separates Leave. It slipped: worldwide general availability is now late October 2026, and Desktop and Mac only.
• Async uploads had not shipped. Roadmap 560813 was still rolling out as of late August 2026, roughly two months later than first published. The roadmap tags Desktop, Mac, and Web only, so do not promise mobile.
• The download manager is the one that actually landed. Roadmap 560815 shows Launched, Desktop and Mac only.
• Quick Share is two separate items, not one: images (560816) and search within the sharing experience (560814).
• "Security detection reporting" has a real product name: the Security detections report (roadmap 560702), rolling out from late August 2026. It is Web only, and Worldwide only — no GCC, GCC High, or DoD.

The lesson generalises: read the roadmap entry, not the blog post, and check its platform and cloud-instance tags before you write a communication plan.

What the features actually change for you

Very little, and that is the honest answer. Async uploads, a download manager, and Quick Share need no retraining and no policy work. Announce them in a release note and move on.

One has a governance edge. Faster file sharing means more files leaving chats, and a file shared in a chat lands in the sender's OneDrive, not a governed team site — so it inherits your OneDrive and SharePoint sharing posture, whatever that currently is.

Two parameters govern external file sharing, and their defaults pull in opposite directions: AutoShareFilesInExternalChats on the messaging policy defaults to Enabled, while FileSharingInChatswithExternalUsers on CsTeamsFilesPolicy defaults to Disabled. Check both before you assume it is off.

The report the announcements were pointing at

The Security detections report gives you a single view of security detections across Teams messaging. Sign in to the Teams admin center, then go to Analytics & reports > Protection reports. On the View reports tab, under Report, select Security detections, choose a Date range, and select Run report.

It covers three detection types: Impersonation, Malicious URL, and Weaponizable File. The on-screen table gives you Detection date, Sender name, Sender email, Detection type, Recipient, and Recipient action.

The table export is where the investigative value is. The CSV adds four fields the portal never shows you: Sender MRI, Recipient email, Recipient ID, and Thread ID. Sender MRI is the identifier you paste into the External access page to block that sender. Thread ID is what you hand to eDiscovery to pull the conversation. Export first, investigate second.

The one column that measures your security training

Recipient action records whether the recipient Accepted, Blocked, or Unblocked the conversation after an impersonation detection was shown to them, with a timestamp. It is populated for Impersonation detections only; for other types it is blank.

That is a rare thing in a Microsoft report: a direct measurement of whether users did the right thing when the product warned them. Accepted-after-warning is a phishing-susceptibility signal, per user, with no simulation campaign needed. Trend it monthly and aim training at the people it names.

User reporting is two settings, and you are probably missing one

Users reporting suspicious Teams messages is gated by two independent toggles in two different portals, and the defaults do not match.

In the Teams admin center, Report a security concern is on by default. In the Microsoft Defender portal, Monitor reported items in Microsoft Teams is on by default for new tenants only — existing tenants have to enable it. If the Defender half is off, user reports will not show up correctly on the User reported tab of the Submissions page, and the people reporting have no idea their reports are going nowhere useful.

Check the Defender side first: Settings > Email & collaboration > User reported settings tab, then the Microsoft Teams section. Then confirm the three Teams-side toggles, which now live in the unified experience at Settings & policies:

Two more things to tell your legal and privacy people before you switch this on. Reported items remain visible to the user — reporting is not removal. And when a message is reported to Microsoft, up to fifteen messages before and after it may be included for analysis.

Where the reports land, and the constraint that shapes everything

Reported items appear on the User reported tab of the Submissions page in the Defender portal. Four alert policies — covering Teams messages and calls reported as a security risk and as not a security risk — fire by default, regardless of your submission destination. Their exact names vary across Microsoft's own documentation, so confirm the strings in your tenant before building rules on them.

Then the constraint: the only way to submit a Teams message to Microsoft is from a user report. There is no proactive admin submission path. If nobody reports it, it never reaches Microsoft, no matter what the detections report showed you.

That makes end-user reporting a load-bearing dependency, not a nice-to-have. It also means the Send the reported items to setting matters: choose My reporting mailbox only and nothing reaches Microsoft at all unless an admin manually resubmits it.

Budget your retention accordingly. Submissions are kept 30 days, and advanced hunting data is also 30 days. Alert metadata lasts 90. Anything you need beyond a month has to be exported.

flowchart TD
    A[Teams message] --> B{Detected by
Teams protections?}
    B -->|Yes| C[Security detections report
Impersonation / URL / File]
    B -->|No| D{User reports it?}
    D -->|No| E[Invisible. No admin
submission path exists]
    D -->|Yes| F[Submissions > User reported
30-day retention]
    F --> G[Alert policies fire by default
no automated investigation]
    C --> H[Export CSV:
Sender MRI + Thread ID]
    H --> I[Block sender
External access page]
    H --> J[Pull conversation
Purview eDiscovery]
    G --> I
    K[External domain anomalies] -.alerts off by default.-> L[Teams channel notification
never reaches SIEM]
    L --> I

Blocking the sender, and the newer security-team lane

Historically, blocking an external domain meant a Teams admin doing it on the External access page. There is now a second lane: turn on Allow my security team to manage blocked domains in the Teams admin center under Users > External access, and your security team can manage the same block list from the Defender portal's Tenant Allow/Block Lists page.

It needs Defender for Office 365 Plan 1 or Plan 2, and your external access setting must be Allow all external domains or Block only specific external domains. The two lists are the same list. Limits: 4,000 domain entries, 200 user entries, entries never expire, and a new block should be active within 24 hours.

That last number matters when you are triaging live. Twenty-four hours is not an incident-response timeline, so pair the block with removing users from the conversation — which is itself a Plan 2 capability.

The licensing that decides what you actually get

This is where tenants discover they bought the announcement and not the feature.

The anomalies report needing no Defender licence is the genuinely useful discovery here: it is the one Teams detection surface an E3-only tenant can use today. If you are weighing the jump, our E3 versus E5 comparison and the Defender for Office 365 tiering guide cover the trade.

Three protection behaviours to know before you rely on them. Safe Links does not rewrite URLs in Teams — protection is time-of-click only. ZAP for Teams does not work in private channels, and its exclusions apply to recipients, not senders. And ZAP acts up to 48 hours after delivery, so it is a cleanup mechanism, not prevention.

The anomalies report, and its honest gap

Under the same Protection reports node, select Communication anomalies. It flags external domains showing unusual first-time external-to-internal contact against a behavioural baseline — the pattern that precedes most Teams-based social engineering.

Two limits to plan around. The longest date range is Last 10 days, so it is a monitoring surface, not a forensic one. And alerts are not enabled by default: turn them on under Notifications & alerts > Rules > External domains anomalies.

Then the gap. Those notifications post to a Teams channel with a link back to the report. They do not raise a Defender incident and they do not reach your SIEM. If you run a real SOC, treat that channel as an intake queue a human triages, or you have built an alert nobody is on call for. Everything else you route through Defender XDR and Sentinel.

Setting the prerequisites in PowerShell

The Teams-side reporting toggle is a real messaging-policy parameter, so you can audit it across every policy rather than clicking through each one:

Connect-MicrosoftTeams

# Which policies leave users unable to report a security concern?
Get-CsTeamsMessagingPolicy |
    Select-Object Identity, AllowSecurityEndUserReporting, AutoShareFilesInExternalChats |
    Where-Object { -not $_.AllowSecurityEndUserReporting }

# Fix the global policy
Set-CsTeamsMessagingPolicy -Identity Global -AllowSecurityEndUserReporting $true

On the Defender side, ZAP for Teams is a single policy object — and note there is no Remove-TeamsProtectionPolicy, so you modify it rather than recreate it:

Connect-ExchangeOnline

Get-TeamsProtectionPolicy |
    Format-List Name, ZapEnabled, HighConfidencePhishQuarantineTag, MalwareQuarantineTag

Set-TeamsProtectionPolicy -Identity "Teams Protection Policy" -ZapEnabled $true

One documentation trap worth knowing: the Monitor reported items in Microsoft Teams checkbox and the ReportChatMessageEnabled property are decoupled. Changing the checkbox does not change the PowerShell property, and the property can read $false while the box appears selected. Verify the behaviour, not the value.

If you have Plan 2, hunt across Teams messages directly. Every column below is in the published schema:

MessagePostDeliveryEvents
| where ActionType in ("Phish ZAP", "Malware ZAP")
| join kind=inner MessageUrlInfo on TeamsMessageId
| project Timestamp, TeamsMessageId, ActionType, Action, ThreatTypes,
          LatestDeliveryLocation, IsExternalThread, Url, UrlDomain

Where none of this works

GCC, GCC High, and DoD: user reporting of Teams messages and calls is unsupported, and so is ZAP for Teams. The Security detections report is Worldwide only.

Mobile: reporting requires Teams for iOS 7.15 or later, or Android 1416/1.0.0.2025153104 or later, and both are messages only — no call reporting. If your field staff are mobile-first, a large share of your users cannot report the calls they are most likely to receive.

What to do in the next two weeks

1. Check the Defender toggle today. If your tenant predates the default, Monitor reported items in Microsoft Teams is off and user reports are not landing properly. Five-minute fix, highest-value action here.
2. Audit AllowSecurityEndUserReporting across every messaging policy, not just Global. Custom policies drift.
3. Turn on the external domain anomalies alert rule and name an owner for the channel it posts to. An unowned alert channel is worse than no alert.
4. Run the Security detections report for the last 30 days and export the CSV. Read Recipient action first — it names who accepted an impersonation warning.
5. Decide who blocks, then confirm your submission destination. If it is set to a reporting mailbox only, nothing reaches Microsoft and detection quality never improves.
6. Put the 30-day export in a runbook. Submissions and hunting data both age out at a month.

The bottom line

The 2026 Teams client changes are minor, late, and partly mis-reported — including in the first version of this article. The security reporting is the part that deserves your afternoon: more capable than the announcements suggested, and more conditional than they implied. Two portals, mismatched defaults, a hard dependency on users reporting, and a headline detection surface that alerts into a chat channel rather than your SIEM.

None of that makes it unusable. It makes it something to configure deliberately rather than assume. Start with the Defender toggle, because until that is on, the rest of the pipeline is decorative.

Further reading

• User reported settings in Teams (Microsoft Learn)
• Security detections report in Microsoft Teams (Microsoft Learn)
• Microsoft Teams external domain anomalies report (Microsoft Learn)
• Microsoft Defender for Office 365 support for Microsoft Teams (Microsoft Learn)
• Manage external meetings and chat (Microsoft Learn)
• Microsoft roadmap roundup — 01 June 2026 (SharePoint Stuff)
• Microsoft 365 Roadmap Updates — April 2026 (Level Up M365)

Image credit: Shixart1985 via Wikimedia Commons (CC BY 2.0).