Teams Security: Guest Access, External Sharing, and Compliance

Why Teams Security Needs Dedicated Attention

Microsoft Teams has evolved in recent years from a chat tool into the central work platform. Meetings, project documentation, client communication, file sharing, and even approval processes all run through Teams. This makes Teams not just a communication channel but a data store containing sensitive business information: strategy discussions as recordings, draft contracts as shared files, HR topics in private chats, client data in project channels.

Yet the security configuration of Teams is often neglected. Many IT departments focus on Exchange and SharePoint but overlook that Teams has its own security settings that must be configured independently of SharePoint and Exchange policies. And the default configuration is, as so often with Microsoft 365, designed for maximum collaboration.

Guest Access vs. External Access: The Difference

Before you tackle the configuration, you need to understand the difference between two features that are frequently confused:

External access (federation): External access allows users to chat and make calls with people in other Microsoft 365 tenants (or Skype for Business/Teams organizations). External users remain in their own tenant and see nothing of your internal Teams environment. It is comparable to email: you can write to external addresses without the recipient gaining access to your mailbox.

Guest access: Guest access allows external individuals to join one of your internal teams as a guest. The guest becomes a member of the team and has access to the channels, files, wikis, and chats of that team. The guest is created as a guest account in your Entra ID directory.

The distinction matters because the risks are different. External access has limited risk (1:1 chat only, no access to internal data). Guest access carries significantly higher risk because the guest can access the team's contents, including all files in the associated SharePoint site.

Configuring Guest Access

Fundamental Decision: Guest Access Yes or No?

For many organizations, guest access is a business necessity—for example, for collaboration with external consultants, agencies, or project partners. The question is not whether you allow guest access, but how you control it.

If you completely disable guest access, employees will find alternatives you can control even less: private WhatsApp groups, personal Dropbox accounts, email with attached files. Controlled sharing via Teams is more secure than the uncontrolled alternative in most cases.

Configuration in the Teams Admin Center

Teams-wide guest access settings:

• Guest access: Enabled (Org-wide Settings > Guest access)
• Guests can read channel messages: Yes
• Guests can send channel messages: Yes
• Guests can create private channels: No
• Guests can edit files: Yes (restricted by SharePoint permissions)
• Guests can delete files: No (recommended)

Who may invite guests? Configure in Entra ID (External Identities > External Collaboration Settings) who may invite guests:

• Recommendation: "Member users and users assigned to specific admin roles can invite guest users" (not every user, but not only admins either)
• Alternative: Only team owners may invite guests to their teams

Control guest access via Conditional Access: Create a Conditional Access policy specifically for guest users:

• Enforce MFA (guests must always authenticate with a second factor)
• Restrict access to specific apps (only Teams and SharePoint, not Azure Portal or other admin portals)
• Session timeout: shorter timeout than for internal users (e.g., 4 hours instead of 24)

Preventing Orphaned Guest Accounts

The biggest problem with guest access is orphaned accounts: external project members whose project finished long ago but whose guest account is still active. Without active management, dozens or hundreds of inactive guest accounts accumulate in a mid-market company within a few years.

Measures against orphaned guest accounts:

• Access reviews (Entra ID P2): Automated quarterly review of all guest accounts by team owners
• Automatic deactivation after 90 days of inactivity (via an automation script or Lifecycle Workflows in Entra ID Governance)
• Regular manual review: At least semi-annually, export a list of all guest accounts and reconcile with team owners
• Documentation: For each guest, document which project or collaboration they are assigned to and when access should be reviewed or removed

External Communication (Federation)

What Does Federation Allow?

External access (federation) enables:

• 1:1 chats and group chats with external Teams users
• Voice and video calls with external users
• Screen sharing in calls

Federation does not enable access to internal teams, channels, files, or other resources. It is a pure communication channel.

Configuration

Open federation (default): In the default configuration, every user can chat with any other Teams user worldwide, as long as their organization also allows federation. This is the most open setting.

Allow-list federation (recommended): You define a list of domains with which federation is allowed. All other domains are blocked. This restricts external communication to known partners and clients.

Block-list federation: You define a list of domains to block. All other domains are allowed. This variant is only useful if you need to specifically block certain domains but generally want open communication.

Recommendation for SMEs: Start with allow-list federation and add the domains of your business partners, clients, and service providers. When employees need to communicate with a new external organization, they must request the domain from IT. This creates a controlled process without blocking collaboration.

Communication with Skype Users and Non-Teams Organizations

You can separately configure whether users may communicate with Skype consumer users (not Skype for Business) and with organizations that do not have a Teams license (e.g., via Teams Essentials accounts). For most organizations, it is recommended to disable both, as it is rarely needed for business and creates additional attack surface.

Meeting Security

Teams meetings are an underestimated security topic. In virtual meetings, confidential information is discussed, screens with sensitive data are shared, and recordings are created that are subsequently stored in SharePoint.

Lobby and Participant Control

The lobby is the waiting area for participants who have not yet been admitted to the meeting. The organizer decides who is admitted directly and who must wait in the lobby.

Recommended configuration (Meeting Policy):

• Who bypasses the lobby? "People in my org" (external participants always wait in the lobby)
• Anonymous participants may join a meeting: No (or only when the organizer explicitly allows it)
• Dial-in participants bypass the lobby: No
• Who can present? Only organizers and co-organizers (participants can be promoted to presenter on request)

Recording Policies

Teams meeting recordings are automatically stored in OneDrive (for 1:1 calls) or SharePoint (for channel meetings). This means that the recording is subject to the sharing and retention policies of the respective storage location.

Recommended configuration:

• Who may record? Only organizers and co-organizers
• Automatic recording: Disabled (recording only on deliberate decision by the organizer)
• Recording expiration: 60–120 days (automatic deletion thereafter, unless a Retention Label has been applied)
• Transcription: Only if business-required (transcripts contain the entire conversation content in plain text)

End-to-End Encryption (E2EE)

Teams offers end-to-end encryption for 1:1 calls and more recently for group meetings. With E2EE enabled, audio, video, and screen sharing are encrypted so that even Microsoft cannot decrypt the content.

E2EE has limitations: recording, live transcription, live captions, and some other features are unavailable when E2EE is active. For most organizations, E2EE is not necessary for daily use, but for particularly confidential conversations (strategy meetings, M&A, HR matters) it can be worthwhile to make the option available.

Recommended configuration:

• Enable E2EE in the Meeting Policy (allows usage but does not enforce it)
• Raise employee awareness about when E2EE should be used
• Document E2EE usage in the ISMS as a TOM for particularly sensitive communication

Compliance Features for Teams

Retention Policies

Teams messages (channel and chat messages) are subject to the same retention requirements as emails and documents. Without a Retention Policy, Teams messages are retained indefinitely, which both increases storage costs and may conflict with data protection requirements.

Recommended configuration:

• Retention Policy for Teams channel messages: Retain for 2 years, then delete
• Retention Policy for Teams chat messages: Retain for 1 year, then delete
• Align with the company's deletion concept (GDPR compliance)
• Retention Labels for specific channels or teams with longer retention requirements (e.g., project teams with contractual retention obligations)

eDiscovery for Teams

eDiscovery enables targeted searches of Teams messages, files, and recordings in the context of investigations, data subject requests, or litigation. Teams content is searchable in Unified eDiscovery in Microsoft Purview.

For the ISMS, eDiscovery is relevant because it demonstrates the ability to quickly identify and produce affected data in the event of a security incident or a GDPR request.

Communication Compliance

Communication Compliance (available with E5 or Compliance add-on) scans Teams messages and other communication channels for policy violations: harassing language, confidential information, insider trading indicators, and custom patterns. For most mid-market companies, this feature is overkill, but in regulated industries (financial services, healthcare) it may be a regulatory requirement.

App Permissions in Teams

Teams is a platform for third-party apps: bots, connectors, tabs, and messaging extensions. In the default configuration, users can install any app from the Microsoft Teams App Store and grant these apps access to corporate data.

The risk: a malicious or over-privileged app can access chat messages, files, and user information. In the best case, it is a privacy problem; in the worst case, a security incident.

Configuring App Permissions

Organization-wide app settings:

• Allow third-party apps: Yes, but restricted
• Allow custom apps: Only for developer scenarios; disabled by default

App permission policies:

• Create a policy that only allows explicitly approved apps (allow list)
• Alternative: Allow all apps but block specific categories (block list)
• Microsoft-owned apps: Generally allow (Forms, Planner, Whiteboard, etc.)
• Third-party apps: Only approve after IT review

App setup policies:

• Define which apps are installed and pinned by default for all users (e.g., Planner, Approvals)
• Prevent users from self-pinning unapproved apps

Evaluation Process for New Apps

When an employee requests a new app for Teams, a defined review process should exist:

1. Purpose and benefit: What should the app do? Is there a Microsoft-native alternative?
2. Review permissions: What permissions does the app request? Are they appropriate for the purpose?
3. Data protection: Where is data processed and stored? Is there a GDPR-compliant privacy policy?
4. Security: Is the vendor known and trustworthy? Is there a security certification?
5. Approval and documentation: Approval by IT security, documentation of the app and its permissions

Teams Security in the ISMS

The security configuration of Teams covers multiple ISO 27001 controls:

A.5.14 (Information transfer):

• External communication (federation) controlled
• Guest access with defined permissions
• DLP policies for Teams messages

A.5.15 (Access control):

• Guest access configuration and processes
• Conditional Access for guests
• App permission policies

A.5.33 (Protection of records):

• Retention Policies for Teams messages and files
• Recording policies and storage locations
• eDiscovery capability

A.6.6 (Confidentiality agreements):

• Guest access only with documented business purpose
• NDA requirements for external project members
• Regular review of guest accounts

A.8.9 (Configuration management):

• Documented meeting policies
• Documented app permission policies
• Regular review of configuration

Documentation in the ISMS

For the ISMS, you should create a Teams governance policy—ISMS Lite helps you document and track all Teams-related TOMs within its control framework. The policy covers the following areas:

• Guest access: When is guest access granted? Who approves? How long is access valid? How is it reviewed?
• External communication: Which domains are enabled for federation? How is the list maintained?
• Meeting policies: When must the lobby be used? When may recordings be made? When is E2EE required?
• App policy: Which apps are allowed? How are new apps reviewed and approved?
• Retention: How long are Teams messages retained? Which channels have special retention requirements?
• Responsibilities: Who manages the team owner role? Who reviews guest accounts? Who approves apps?

Common Mistakes in Teams Security

Completely disabling guest access instead of controlling it: If you turn off guest access, employees will resort to uncontrolled alternatives: private WhatsApp groups, personal Slack workspaces, or email with attached files. Controlled collaboration via Teams with documented guest access, Conditional Access, and access reviews is more secure than the alternative in almost all cases.

No differentiation between team types: Not every team needs the same security configuration. A marketing team with general project files has different requirements than an executive leadership team with confidential strategy papers. Use Sensitivity Labels at the team level according to your classification policy to automatically adjust security settings: a "Confidential" team automatically restricts guest access and prevents external sharing.

Not training team owners: Team owners are the decentralized administrators of their teams. They invite guests, manage channels, and set sharing settings. If they do not understand the responsibility that comes with the role, security gaps arise. Training for team owners should cover guest access, file permissions, and data protection.

Not cleaning up orphaned teams: Teams created for completed projects often remain active indefinitely. Files remain accessible, guests retain access, and nobody feels responsible. Implement a process for archiving or deleting inactive teams. Microsoft offers Inactivity Policies in Entra ID that prompt team owners to review after a defined inactivity period.

Not considering meeting recordings: Teams recordings often contain confidential conversations and are stored in SharePoint, where they are subject to the sharing policies of the respective site. Without specific Retention Policies or Sensitivity Labels for recordings, they can be accidentally shared externally or retained indefinitely.

Monitoring and Continuous Improvement

The security configuration of Teams is not a one-time project but requires regular monitoring:

Monthly review:

• Review guest accounts: new guests, inactive guests, guests in unexpected teams
• Review app usage: Which third-party apps are being installed? Are there unapproved apps?
• Review meeting recordings: Where are recordings stored? Are access permissions correct?

Quarterly review:

• Update the federation domain list (add new partners, remove old ones)
• Review meeting policies against current best practices
• Conduct guest account access review (automated with P2 license)
• Identify and archive inactive teams

Annually:

• Review and update the entire Teams governance policy
• Feed results into the management review
• Refresh training for team owners

Checklist: Teams Security

Further Reading

• Securing Microsoft 365: The 15 Most Important Security Settings
• Securing SharePoint and OneDrive: Sharing, DLP, and Data Classification
• Conditional Access in Entra ID: Policies for Mid-Market Companies
• Creating an Authorization Concept: Roles, Rights, and Recertification
• Creating an Information Security Policy: Structure, Content, and Examples