Collaboration Tool Security Guide: Teams, Slack and Zoom

Chat and meeting platforms now carry the conversations, files and approvals that used to travel by email, but many organisations secure them far less carefully than their mail gateway. Default settings in Microsoft Teams and Slack let users talk to almost any external tenant and install apps without review, and attackers have noticed: state and criminal groups have used Teams chats to pose as IT support, harvest MFA approvals and launch ransomware. This guide covers external access, guests, apps and bots as non-human identities, chat phishing, meetings, retention, DLP and AI assistants, for collaboration platform owners, security engineers and compliance teams. Products such as Microsoft Teams, Slack, Zoom and Google Chat are named only to document their settings; nothing here is a recommendation.

Key takeaways

• Defaults are open: Microsoft documents that "By default, all external domains are allowed" in Teams, and Slack documents that members "can install apps without a Workspace Owner's approval". Review both before anything else.
• External access, guest access and shared channels are different controls: each grants different reach into your tenant, lives in different admin consoles and needs its own policy.
• Chat is now a phishing channel: attackers message staff from look-alike tenants as "Help Desk" or security staff. Restrict external chat, show external labels clearly and train staff never to approve sign-ins at someone's request.
• Bots, apps and webhooks are non-human identities: their tokens and OAuth scopes often reach every channel they join. Govern them like any other integration credential.
• Retention and DLP must follow the conversation: chat, channel, meeting recordings and AI interactions each have their own retention location, and cross-tenant chats follow the host tenant's DLP, not yours.

The collaboration attack surface

External access and federation

External access (federation) lets users chat and meet with other organisations; Microsoft notes that "People from outside your organization don't have access to your teams, sites, or other Microsoft 365 resources." The risk is not data access but trust: an external message looks much like an internal one.

Microsoft Teams settings

Both the organisation setting and a per-user policy must allow external access, and both are on by default. The domain setting has four modes: allow all external domains (the default), allow only specific domains, block specific domains, or block all.

Two details catch teams out. People from blocked domains "can still join meetings anonymously if anonymous access is allowed", so meeting policy has to be tightened separately. And Microsoft documents a security team blocklist that lets security administrators manage blocked Teams domains in Microsoft Defender's Tenant Allow/Block Lists, which ties chat blocking to the same process used for email.

Slack and Google Chat

Slack Connect requires an invitation to be accepted, and administrators can control who approves Slack Connect channel invitations, set per-organisation approval and automatic acceptance rules, and revoke pending invitations; Enterprise plans can also restrict Slack Connect to specific workspaces. Google Chat has comparable external chat controls. On any platform, record an owner for each trusted connection and review connections at least annually.

Guest access and shared channels

• Guests are identities: Microsoft notes that guests get "the same compliance and auditing protection as other Microsoft 365 users" and that Conditional Access and MFA can be enforced for B2B users. Apply them.
• Removal is not automatic: a guest leaving a team does not delete the guest account; "Your Microsoft Entra admin must remove the guest account." Use recurring Entra access reviews for guests, and expire inactive ones. See the Third-Party Access Guide.
• Restrict and label: delegate invitations through the Guest Inviter role, audit the "Added member to group" event, and use sensitivity labels to keep guests out of specific teams rather than disabling guest access everywhere.

Where identity fits: apps, bots and integrations

Every bot, app, connector and webhook is a non-human identity with its own credential and permissions. An app granted broad scopes can read files, channel history and profiles across the workspace, and such grants are long-lived, rarely reviewed and often owned by someone who has left. The Salesloft Drift Breach 2025 showed how stolen OAuth tokens from one chatbot integration opened hundreds of Salesforce tenants.

• Require approval: in Slack, enable "Require approved apps" and "Only allow pre-approved apps"; approving a request "also approves the app's scopes", so review the scopes, not just the app name. In Teams, app centric management sets each app to Everyone, Specific users or groups, or No one, and the org-wide "Let users install and use available apps by default" setting covers Microsoft, third-party and custom apps separately. Admin consent to an app's Microsoft Graph permissions is a separate decision; review it in Entra ID.
• Prefer narrow, short-lived tokens: use granular bot scopes, enable token rotation where supported (Slack notes rotation "may not be turned off once it's turned on"), and replace legacy custom integration tokens, which carry the full scope of the user who created them.
• Treat webhooks as secrets: an incoming webhook URL is a bearer credential that lets anyone holding it post into a channel. Store it in a vault, not in a repository. See the Secrets Management Guide.
• Give every integration an owner: inventory apps quarterly, remove ownerless or inactive ones, and revoke tokens when the owner leaves. Restricted Slack apps that are already installed keep working, so uninstall them too.

See the SaaS and OAuth App Governance Guide for consent and scope governance, and the API Key Management Guide for rotation and storage.

Phishing, vishing and malware over chat

Microsoft has documented two patterns that every Teams tenant should plan for. In August 2023 it reported that Midnight Blizzard used previously compromised small-business tenants, renamed with new onmicrosoft.com subdomains and security or product themed names, to send Teams chat requests posing as technical support; targets were asked to enter a code into their Microsoft Authenticator prompt, handing over their account. Fewer than 40 organisations were affected. In May 2024 (updated in June) Microsoft reported that Storm-1811 flooded targets' inboxes with subscription email, then contacted them by phone and, from late May 2024, by Teams messages and calls from tenants with display names such as "Help Desk" and "IT Support", persuading them to open Quick Assist, with intrusions in some cases ending in Black Basta ransomware. ATT&CK cites Storm-1811's Teams activity as a procedure example for T1566.003 Spearphishing via Service.

• Restrict who can reach your users: an allow list of partner domains removes most of this attack surface; where that is not possible, block unmanaged accounts and trial tenants and maintain a block list.
• Make "External" obvious: both Microsoft reports tell users to check the "External" tag and to accept or block outside senders. Train staff that real IT support does not start conversations from external tenants. See the Security Awareness and Human Risk Management Guide.
• Remove the payoff: phishing-resistant MFA defeats code-approval tricks (see the MFA Fatigue and Bypass Guide), and blocking or removing Quick Assist and unused remote management tools, as Microsoft advises, removes the remote-control step. Help desk verification for inbound requests is covered in the Account Recovery and Help Desk Security Guide.
• Scan links and files in chat as you do for email, and include chat in phishing simulations. See the Phishing Guide.

Meeting security

The NCSC's guidance for organisations is to "Only allow direct access to authenticated users and invited guests", require passcodes for unauthenticated users, use a lobby to verify participants before admitting them, consider blocking calls from outside the organisation and from unknown contacts, and not to share meeting links publicly.

• Join controls: require sign-in for internal meetings, send anonymous and external participants to the lobby, and restrict who can bypass it. In Teams, remember that anonymous join can bypass a domain block.
• Host controls: Zoom documents Lock meeting ("no new participants can join"), Suspend Participant Activities (stops video, audio, sharing, chat and recording at once) and Remove participant ("cannot rejoin"). Restrict screen sharing to presenters by default and brief hosts on these controls; they are the main response to "Zoombombing".
• Verify people, not faces: the Arup Deepfake Fraud 2024 involved a fake CFO on a video call. Payment and access requests made in meetings need out-of-band verification. See the Deepfake and AI Impersonation Guide.
• Recordings and transcripts: the NCSC advises knowing where recordings, transcriptions, chat logs and shared files are stored. In Teams, channel meeting files fall under SharePoint and chat meeting files under the organiser's OneDrive, so retention and sharing settings follow those locations.

Retention, eDiscovery and DLP

Chat holds records that regulators and litigants will ask for, and secrets and personal data that attackers look for: ATT&CK lists T1552.008 Unsecured Credentials: Chat Messages and T1213.005 Data from Information Repositories: Messaging Applications. Retention, eDiscovery and DLP need to be designed together.

• Retention locations: Microsoft Purview uses separate locations for Teams chats, Teams channel messages and (for private channels before migration) Teams private channel messages; Teams retention "isn't included in retention policies that are configured for Exchange user or group mailboxes." Chat data is stored in "a hidden folder in the mailbox of each user included in the chat".
• Deletion is not instant: expired items move to the SubstrateHolds folder, stay there "for at least 1 day", and are removed by a timer job that "typically takes 1-7 days to run". Litigation Hold, delay holds and eDiscovery holds suspend deletion, and Microsoft advises verifying retention "by eDiscovery tools rather than by messages that are currently visible in the Teams app."
• DLP coverage: Purview DLP covers chat and channel messages, including private and shared channels, with files covered through SharePoint and OneDrive. Messages with sensitive information sent to guests are deleted "automatically, and within seconds" when your tenant initiated the chat. Microsoft states that "Support for DLP protection in Teams Chat requires an E5 license".
• Cross-tenant limits: "a user's home-tenant DLP policies don't automatically follow the user into a conversation hosted by another tenant", and in shared channels each tenant's policy applies only to its own users. Shared channels and Slack Connect therefore need contractual and approval controls, not just DLP.
• Secrets in chat: add credential patterns (cloud keys, tokens, private keys) to chat DLP and secret scanning, and treat any key posted in chat as exposed and due for rotation. See the Leaked Credential Response Playbook.

AI assistants in collaboration tools

Meeting copilots, chat summarisers and AI note-takers read what the invoking user can read, so any over-sharing surfaces in their answers. The NCSC also tells organisations to be aware of "AI attendees" that record, transcribe or analyse meetings, and Zoom documents an Active Apps Notifier that "notifies the host and participants that an automated meeting tool has joined a meeting".

• Clean up permissions first: fix over-shared teams, channels and sites before enabling assistants, and apply sensitivity labels to restricted content.
• Treat invites and messages as untrusted input: the Gemini AI Calendar Prompt Injection 2026 showed a malicious invite steering an assistant into leaking meeting data, and EchoLeak 2025 showed zero-click prompt injection against Microsoft 365 Copilot.
• Govern note-takers and retain AI interactions: third-party note-takers are apps with meeting and calendar scopes, so put them through app approval; include assistant prompts and responses in retention where supported.

See the Enterprise AI Copilot Security Guide for rollout controls.

Implementing a hardened configuration

1. Inventory: export external access and federation settings, guest counts, shared channels and Slack Connect connections, installed apps with their scopes, and meeting policies for every tenant and workspace.
2. Quick wins: block unmanaged consumer accounts and trial tenants, turn on app approval, restrict who can invite guests, and require the lobby for anonymous and external participants. These rarely break business processes.
3. Pilot domain restrictions: build a partner allow list from recent audit logs, apply it to a pilot group through per-user policies, and collect exceptions for two to four weeks.
4. Enforce in rings: extend the policy by department, starting with finance, IT and executives, who are the most targeted.
5. DLP in test mode: run chat DLP rules in simulation first, tune for false positives, then enable policy tips, and only then blocking for external recipients.
6. Apps and tokens: assign owners to every app, remove orphaned ones, and move remaining integrations to granular scopes and rotating tokens.
7. Rollback: keep the previous federation configuration exported, so a broken partner connection can be restored by adding the domain back to the allow list or reverting the user policy; document an emergency exception process with expiry.

Choosing an approach

• Allow list or block list: an allow list gives the strongest protection and suits regulated firms and organisations with a stable partner set. A block list suits organisations that collaborate widely, such as universities, agencies and professional services, but depends on fast threat intelligence and strong user awareness.
• Guest access or shared channels: guests suit long-running projects needing files and several channels; shared channels suit focused collaboration without guest accounts, at the cost of relying on the other tenant's controls.
• Small or large: small organisations get most value from native settings: block unmanaged accounts, require app approval, use the lobby, enforce MFA for guests. Large organisations add per-user policies, automated guest reviews, DLP, regulatory retention and SOC integration.

Detection and measurement

Collect the Microsoft 365 unified audit log (Teams events, guest additions, app consents), Slack audit logs where the plan provides them, and meeting platform logs. Alert on first contact from a new external domain to many users, external display names containing "help desk", "IT support" or "security", new app consents with broad scopes, new webhooks, and remote support tool launches following a chat.

• External exposure: number of external domains users can chat with, and percentage of users covered by a restrictive policy.
• Guest hygiene: guests inactive for 90 days, and percentage of guests reviewed in the last cycle.
• Integration hygiene: apps without an owner, apps with message-read or file-read scopes, and tokens older than your rotation standard.
• Chat phishing: reported external chat attempts and time from report to tenant or domain block.
• DLP: chat DLP matches per month by policy, and override rate.

Framework mapping

Common failure patterns

• Leaving federation at the default: "allow all external domains" plus unmanaged accounts lets any tenant, including a fresh one named "IT Support", message every employee.
• Blocking domains but allowing anonymous meeting join: the blocked party simply joins as an anonymous guest.
• Guest accounts that never expire: partners' staff keep access long after a project ends because removing someone from a team does not remove the guest account.
• Integrations nobody owns: bots and webhooks created by former employees still hold workspace-wide tokens. Token theft from vendors that hold your tokens is a recurring pattern, as the Slack GitHub Breach 2022 showed with employee tokens held by a vendor.
• Retention policy assumed from email: Exchange mailbox policies do not cover Teams chat, so chat is either kept forever or deleted too early.
• Secrets pasted into chat and never rotated: deleting the message does not revoke the key.

Practitioner checklist

• Review external access in every tenant: domain allow or block list, subdomains blocked, unmanaged accounts and trial tenants blocked.
• Tighten meeting policy so anonymous and external participants wait in the lobby, and brief hosts on lock, suspend and remove controls.
• Restrict guest invitations, enforce MFA and Conditional Access for guests, and run recurring access reviews.
• Require approval for Slack apps and Teams apps, review scopes and Graph permissions, and assign an owner to every integration.
• Rotate or replace long-lived bot, user and app-level tokens, and vault webhook URLs.
• Remove Quick Assist and unused remote support tools, and train staff that IT never initiates contact from an external tenant.
• Configure retention locations for chats, channel messages and meeting recordings, and verify with eDiscovery.
• Deploy chat DLP for credentials and personal data, starting in simulation mode.
• Clean up over-sharing and govern note-takers before enabling AI assistants.
• Send collaboration audit logs to the SOC with alerts for external help desk impersonation and broad app consents.

Standards and references

• NCSC: Video conferencing services, security guidance for organisations
• Microsoft Learn: Manage external meetings and chat with people and organisations using Microsoft identities
• Microsoft Learn: Guest access in Microsoft Teams
• Microsoft Learn: Data loss prevention and Microsoft Teams
• Microsoft Learn: Learn about retention for Microsoft Teams
• Microsoft Threat Intelligence: Midnight Blizzard conducts targeted social engineering over Microsoft Teams
• Slack: Manage app approval for your workspace
• MITRE ATT&CK: T1566.003 Spearphishing via Service

Related NHI Mgmt Group resources: SaaS and OAuth App Governance Guide · Enterprise AI Copilot Security Guide · Third-Party Access Guide · Phishing Guide · Email Security Guide