"The new policy in the Teams Admin Center, Manage external bots and their access to meetings, can be assigned to individual users or specific groups," Microsoft said on Monday.
What Microsoft is rolling out and where it will appear
Microsoft has added an admin policy to Teams that gives organizations the ability to block third‑party bots from joining meetings without explicit approval. The capability was first recorded in a March Microsoft 365 roadmap entry and is being made available across Windows, macOS, Android, and iOS for worldwide standard multi‑tenant and GCC cloud environments. Once enabled, the policy is intended to prevent malicious apps controlled by threat actors — as well as third‑party bots used for note‑taking, transcription, or other automated tasks — from joining meetings silently.
How Teams will detect and handle bots in meetings
When the policy is active, Teams will automatically detect potential bots, place them in the meeting lobby, clearly identify them to attendees, and prompt organizers to confirm admission. Microsoft says this operates even in meetings where human participants are allowed to bypass the lobby: bots identified under the new policy will continue to require organizer approval before joining. The stated outcome is that attendees will be made aware when a non‑human participant has been added and that organizations will gain greater control and visibility over external bots.
Planned admin controls, reporting, and Defender portal changes
Microsoft said it plans to expand administrative controls around bots, including allow lists for approved bots, policies to block external bots entirely, administrative reports and audit logs on bot detection and presence, and more granular controls to match different security needs. Separately, starting in December administrators will be able to block external Teams users via the Defender portal to prevent cybercrime gangs — including ransomware groups — from abusing the platform in social‑engineering attacks.
Other recent Teams protections and attacker behavior Microsoft called out
The new bot policy follows a string of Teams security features Microsoft added earlier in the year. In January, Teams received fraud‑protection features for calls that warn users about external callers impersonating trusted organizations, and the company announced a call‑reporting feature slated for mid‑March to let users flag unwanted or suspicious calls as potential phishing or scam attempts. In April, Microsoft warned that attackers are increasingly abusing external Teams collaboration for access and lateral movement on enterprise networks, impersonating IT or helpdesk staff via cross‑tenant chats to trick employees into granting remote access and thereby stealing data.
What this means for security teams, admins, and end users
- Technologists and security teams: The policy gives detection and admission controls that can be enforced at user or group level; teams will want to plan how detection alerts and future audit logs feed into SIEM and EDR workflows.
- IT administrators and procurement leaders: Admins should watch for the forthcoming allow lists, block policies, and Defender‑portal controls (available starting in December) and decide which users or groups should receive the new policy assignments.
- End users and employees: Attendees will see explicit identification when a non‑human participant is present and organizers will be prompted before such bots join — changing how automated meeting tools are introduced into routine collaboration.
Microsoft frames the change as part of a broader effort to reduce abuse of external collaboration channels. The company also highlighted detection gaps elsewhere: one stat cited in related material notes security teams log 54% of successful attacks and alert on just 14%, and a Picus whitepaper referenced in the same material points to breach‑and‑attack simulation as a way to test SIEM and EDR rules so that threats stop slipping by detection.
The new Teams admin policy tightens control at the meeting level and promises additional controls and reporting, but it will be the rollout of allow lists, audit logs and the December Defender‑portal block that determines how much friction administrators must add to keep malicious automation out without disrupting legitimate automated tools. Organizations will now need to decide who will receive the policy, how false positives will be handled, and how the forthcoming logs and reports are consumed by existing security tooling.
