TLP:CLEAR
CISA M365 Secure Configuration Baseline for Teams
Microsoft 365 (M365) Teams is a cloud-based text and live chat workspace that supports video calls, chat messaging, screen sharing, and file sharing. This secure configuration baseline (SCB) provides specific policies to strengthen Microsoft Teams’ security.
Many admin controls for Teams are found in the Teams admin center. However, several essential security functions for Teams require a dedicated security tool, e.g., for data loss prevention. M365 provides these security functions natively via Defender for Office 365. Notably, Defender for Office 365 capabilities require Defender for Office 365 Plan 1 or 2. These are included with E5 and G5 and are available as add-ons for E3 and G3. However, third-party solutions that offer comparable security functions can be used in lieu of Defender. Refer to the CISA M365 Secure Configuration Security Suite Baseline for additional guidance.
The Secure Cloud Business Applications (SCuBA) project, run by the Cybersecurity and Infrastructure Security Agency (CISA), provides guidance and capabilities to secure federal civilian executive branch (FCEB) agencies’ cloud business application environments and protect federal information that is created, accessed, shared, and stored in those environments.
The CISA SCuBA SCBs for M365 help secure federal information assets stored within M365 cloud business application environments through consistent, effective, and manageable security configurations. CISA created baselines tailored to the federal government’s threats and risk tolerance with the knowledge that every organization has different threat models and risk tolerance. While use of these baselines will be mandatory for civilian Federal Government agencies, organizations outside of the Federal Government may also find these baselines to be useful references to help reduce risks.
For non-Federal users, the information in this document is being provided “as is” for INFORMATIONAL PURPOSES ONLY. CISA does not endorse any commercial product or service, including any subjects of analysis. Any reference to specific commercial entities or commercial products, processes, or services by service mark, trademark, manufacturer, or otherwise, does not constitute or imply endorsement, recommendation, or favoritism by CISA. Without limiting the generality of the foregoing, some controls and settings are not available in all products; CISA has no control over vendor changes to products offerings or features. Accordingly, these SCuBA SCBs for M365 may not be applicable to the products available to you. This document does not address, ensure compliance with, or supersede any law, regulation, or other authority. Entities are responsible for complying with any recordkeeping, privacy, and other laws that may apply to the use of technology. This document is not intended to, and does not, create any right or benefit for anyone against the United States, its departments, agencies, or entities, its officers, employees, or agents, or any other person.
This document is marked TLP:CLEAR. Recipients may share this information without restriction. Information is subject to standard copyright rules. For more information on the Traffic Light Protocol, see https://www.cisa.gov/tlp.
License Compliance and Copyright
Portions of this document are adapted from documents in Microsoft’s M365 and Azure GitHub repositories. The respective documents are subject to copyright and are adapted under the terms of the Creative Commons Attribution 4.0 International license. Source documents are linked throughout this document. The United States government has adapted selections of these documents to develop innovative and scalable configuration standards to strengthen the security of widely used cloud-based software services.
Assumptions
The License Requirements sections of this document assume the organization is using an M365 E3 or G3 license level at a minimum. Therefore, only licenses not included in E3/G3 are listed.
Key Terminology
The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in RFC 2119.
Access to Teams can be controlled by the user type. In this baseline, the types of users are defined as follows:
-
Internal users: Members of the agency’s M365 tenant.
-
External users: Members of a different M365 tenant.
-
Business to Business (B2B) guest users: External users who are formally invited to collaborate with the team and added to the agency’s Microsoft Entra as guest users. These users authenticate with their home organization/tenant and are granted access to the team by virtue of being listed as guest users on the tenant’s Microsoft Entra.
-
Unmanaged users: Users who are not members of any M365 tenant or organization (e.g., personal Microsoft accounts).
-
Anonymous users: Teams users joining calls who are not authenticated through the agency’s tenant; these users include unmanaged users, external users (except for B2B guests), and true anonymous users (i.e., users who are not logged in to any Microsoft or organization account, such as dial-in users1).
BOD 25-01 Requirement: This indicator means that the policy is required under CISA BOD 25-01.
Automated Check: This indicator means that the policy can be automatically checked via ScubaGear. See the Quick Start Guide for help getting started.
Manual: This indicator means that the policy requires manual verification of configuration settings.
Baseline Policies
1. Meeting Policies
This section helps reduce security risks posed by the external participants during meetings. In this instance, the term “external participants” includes external users, B2B guest users, unmanaged users, and anonymous users.
This section helps reduce security risks related to the user permissions for recording Teams meetings and events. These policies and user permissions apply to meetings hosted by a user, as well as during one-on-one calls and group calls started by a user. Agencies should comply with any other applicable policies or legislation in addition to this guidance.
Policies
MS.TEAMS.1.1v1
External meeting participants SHOULD NOT be enabled to request control of shared desktops or windows.
- Rationale: An external participant with control of a shared screen could potentially perform unauthorized actions on the shared screen. This policy reduces that risk by removing an external participant’s ability to request control. However, if an agency has a legitimate use case to grant this control, it may be done on a case-by-case basis.
- Last modified: July 2023
- Note: This policy applies to the Global (Org-wide default) meeting policy, as well as custom meeting policies.
- NIST SP 800-53 Rev. 5 FedRAMP High Baseline Mapping: AC-17a
- MITRE ATT&CK TTP Mapping:
- None
MS.TEAMS.1.2v2
Anonymous users SHALL NOT be enabled to start meetings.
- Rationale: This policy protects against anonymous users starting Microsoft Teams meetings to scrape internal contacts. The policy is beneficial for agencies that have implemented custom policies, providing flexibility for some users to automatically admit “everyone” to a Microsoft Teams meeting.
- Last modified: August 2025
- Note: This policy applies to the Global (Org-wide default) meeting policy, and custom meeting policies if they exist.
- NIST SP 800-53 Rev. 5 FedRAMP High Baseline Mapping: SC-15a
- MITRE ATT&CK TTP Mapping:
MS.TEAMS.1.3v1
Anonymous users and dial-in callers SHOULD NOT be admitted automatically.
- Rationale: Automatically allowing admittance to anonymous and dial-in users diminishes control of meeting participation and invites potential data breach. This policy reduces that risk by requiring all anonymous and dial-in users to wait in a lobby until admitted by an authorized meeting participant. If the agency has a use case to admit members of specific trusted organizations and/or B2B guests automatically, custom policies may be created and assigned to authorized meeting organizers.
- Last modified: July 2023
- Note: This policy applies to the Global (Org-wide default) meeting policy. Custom meeting policies MAY be created to allow specific users more flexibility. For example, B2B guest users and trusted partner members may be admitted automatically into meetings organized by authorized users.
- NIST SP 800-53 Rev. 5 FedRAMP High Baseline Mapping: SC-15a
- MITRE ATT&CK TTP Mapping:
- None
MS.TEAMS.1.4v1
Internal users SHOULD be admitted automatically.
- Rationale: Requiring internal users to wait in the lobby for explicit admission can lead to admission fatigue. This policy enables internal users to be automatically admitted to the meeting through global policy.
- Last modified: July 2023
- Note: This policy applies to the Global (Org-wide default) meeting policy. Custom meeting policies MAY be created to allow specific users more flexibility.
- NIST SP 800-53 Rev. 5 FedRAMP High Baseline Mapping: AC-3
- MITRE ATT&CK TTP Mapping:
- None
MS.TEAMS.1.5v1
Dial-in users SHOULD NOT be enabled to bypass the lobby.
- Rationale: Automatically admitting dial-in users reduces control over who can participate in a meeting and increases potential for data breaches. This policy reduces the risk by requiring all dial-in users to wait in a lobby until they are admitted by an authorized meeting participant.
- Last modified: July 2023
- Note: This policy applies to the Global (Org-wide default) meeting policy, as well as custom meeting policies.
- NIST SP 800-53 Rev. 5 FedRAMP High Baseline Mapping: SC-15a
- MITRE ATT&CK TTP Mapping:
- None
MS.TEAMS.1.6v1
Meeting recording SHOULD be disabled.
- Rationale: Allowing any user to record a Teams meeting or group call may lead to unauthorized disclosure of shared information, including audio, video, and shared screens. By disabling the meeting recording setting in the Global (Org-wide default) meeting policy, an agency limits information exposure.
- Last modified: March 2025
- Note: This policy applies to the Global (Org-wide default) meeting policy. Custom policies MAY be created to allow more flexibility for specific users.
- NIST SP 800-53 Rev. 5 FedRAMP High Baseline Mapping: CM-7
- MITRE ATT&CK TTP Mapping:
- None
MS.TEAMS.1.7v2
Record an event SHOULD NOT be set to Always record.
- Rationale: Limiting recording permissions to only the organizer minimizes the security risk to the organizer’s discretion for these Live Events, reducing data leakage and other security risks. Administrators can also disable recording for all live events.
- Last modified: March 2025
- Note: This policy applies to the Global (Org-wide default) meeting policy. Custom policies MAY be created to allow more flexibility for specific users.
- NIST SP 800-53 Rev. 5 FedRAMP High Baseline Mapping: AC-21a
- MITRE ATT&CK TTP Mapping:
- None
Resources
- Manage who can present and request control in Microsoft Teams | Microsoft Learn
- Assign policies in Teams – getting started | Microsoft Learn
- Live Event Recording Policies | Microsoft Learn
License Requirements
- N/A
Implementation
MS.TEAMS.1.1v1 Instructions
To help ensure external participants do not have the ability to request control of the shared desktop or window in the meeting:
-
Sign in to the Microsoft Teams admin center.
-
Select Meetings > Meeting policies.
-
Select the Global (Org-wide default) policy.
-
Under the Content sharing section, set External participants can give or request control to Off.
-
If custom policies were created, repeat these steps for each policy, selecting the appropriate policy in step 3.
MS.TEAMS.1.2v2 Instructions
To configure settings for anonymous users:
-
Sign in to the Microsoft Teams admin center.
-
Select Meetings > Meeting policies.
-
Select the Global (Org-wide default) policy.
-
Under the Meeting join & lobby section, ensure the Anonymous users and dial-in callers can start a meeting setting remains at the default position of Off.
-
If custom policies were created, repeat these steps for each policy, selecting the appropriate policy in step 3.
MS.TEAMS.1.3v1 Instructions
-
Sign in to the Microsoft Teams admin center.
-
Select Meetings > Meeting policies.
-
Select the Global (Org-wide default) policy.
-
Under the Meeting join & lobby section, ensure Who can bypass the lobby is not set to Everyone. Bypassing the lobby should be set to People in my org, though other options may be used if needed.
-
In the same section, set People dialing in can bypass the lobby to Off.
MS.TEAMS.1.4v1 Instructions
-
Sign in to the Microsoft Teams admin center.
-
Select Meetings > Meeting policies.
-
Select the Global (Org-wide default) policy.
-
Under the Meeting join & lobby section, ensure Who can bypass the lobby is set to People in my org.
-
In the same section, set People dialing in can bypass the lobby to Off.
MS.TEAMS.1.5v1 Instructions
-
Sign in to the Microsoft Teams admin center.
-
Select Meetings > Meeting policies.
-
Select the Global (Org-wide default) policy.
-
Under the Meeting join & lobby section, set People dialing in can bypass the lobby to Off.
MS.TEAMS.1.6v1 Instructions
-
Sign in to the Microsoft Teams admin center.
-
Select Meetings > Meeting policies.
-
Select the Global (Org-wide default) policy.
-
Under the Recording & transcription section, set Meeting recording to Off.
-
Select Save.
MS.TEAMS.1.7v2 Instructions
-
Sign in to the Microsoft Teams admin center.
-
Select Meetings > Live events policies.
-
Select Global (Org-wide default) policy.
-
Set Record an event to either Organizer can record or Never record
-
Click Save.
-
If custom policies were created, repeat these steps for each policy, selecting the appropriate policy in step 3.
2. External User Access
This section helps reduce security risks related to external and unmanaged user access. In this instance, external users refer to members of a different M365 tenant, and unmanaged users refer to users who are not members of any M365 tenant or organization.
External access allows external users to look up internal users by their email address to initiate chats and calls entirely within Teams. Blocking external access prevents external users from using Teams as an avenue for reconnaissance or phishing. Even with external access disabled, external users will still be able to join Teams calls, assuming anonymous join is enabled. Depending on agency need, if both external access and anonymous join are blocked—neither required nor recommended by this baseline—external collaborators would only be able to attend meetings if added as B2B guest users.
External access may be granted on a per-domain basis. This may be desirable in some cases (e.g., for agency-to-agency collaboration). See the Chief Information Officer Council’s Interagency Collaboration Program Office of Management and Budget MA site for a list of .gov domains for sharing.
Similar to external users, blocking contact with unmanaged Teams users prevents these users from looking up internal users by their email address and initiating chats and calls within Teams. These users would still be able to join calls, assuming anonymous join is enabled. Additionally, unmanaged users may be added to Teams chats if the internal user initiates the contact.
Policies
MS.TEAMS.2.1v2
External access for users SHALL only be enabled on a per-domain basis.
- Rationale: The default configuration allows members to communicate with all external users with similar access permissions. Unrestricted access can lead to data breaches and other security threats. This policy provides protection against threats posed by unrestricted access by allowing communication with only trusted domains.
- Last modified: August 2025
- NIST SP 800-53 Rev. 5 FedRAMP High Baseline Mapping: AC-3
- MITRE ATT&CK TTP Mapping:
MS.TEAMS.2.2v2
Unmanaged users SHALL NOT be enabled to initiate contact with internal users.
- Rationale: Allowing contact from unmanaged users can expose users to email and contact address harvesting. This policy provides protection against this type of harvesting.
- Last modified: August 2025
- Note: This policy is not applicable to Government Community Cloud (GCC), GCC High, and Department of Defense (DoD) tenants.
- NIST SP 800-53 Rev. 5 FedRAMP High Baseline Mapping: CM-7, SI-8
- MITRE ATT&CK TTP Mapping:
MS.TEAMS.2.3v2
Internal users SHOULD NOT be enabled to initiate contact with unmanaged users.
- Rationale: Contact with unmanaged users can pose the risk of data leakage and other security threats. This policy provides protection by disabling internal user access to unmanaged users.
- Last modified: August 2025
- Note: This policy is not applicable to Government Community Cloud (GCC), GCC High, and Department of Defense (DoD) tenants.
- NIST SP 800-53 Rev. 5 FedRAMP High Baseline Mapping: CM-7, SC-7(10)(a)
- MITRE ATT&CK TTP Mapping:
Resources
License Requirements
- N/A
Implementation
Steps for the unmanaged users are outlined in Manage chat with external Teams users not managed by an organization.
MS.TEAMS.2.1v2 Instructions
To enable external access for only specific domains:
-
Sign in to the Microsoft Teams admin center.
-
Select Users > External access > Organization settings.
-
Next to Teams and Skype for Business users in external organizations, select Allow only specific external domains
-
Select Add external domains. Enter domains allowed, and then select Done
NOTE: Domains will need to be added in this step in order for users to communicate with them.
-
Click Save.
MS.TEAMS.2.2v2 Instructions
-
Sign in to the Microsoft Teams admin center.
-
Select Users > External access.
-
Select Policies.
-
Select Global (Org-wide Default).
-
Under Edit policy details, toggle People in my organization can communicate with unmanaged Teams accounts to one of the following:
- To completely block contact with unmanaged users, toggle the setting to Off.
- To allow contact with unmanaged users only if the internal user initiates the contact:
- Toggle the setting to On.
- Clear the check next to External users with Teams accounts not managed by an organization can contact users in my organization.
MS.TEAMS.2.3v2 Instructions
-
Sign in to the Microsoft Teams admin center.
-
Select Users > External access.
-
Select Policies.
-
Select Global (Org-wide Default).
-
To completely block contact with unmanaged users, under Edit policy details, set People in my organization can communicate with unmanaged Teams accounts to Off.
4. Teams Email Integration
This section helps reduce security risks related to Teams email integration. Teams provides an optional feature allowing channels to have an email address and receive email.
Policies
MS.TEAMS.4.1v1
Teams email integration SHALL be disabled.
- Rationale: Microsoft Teams email integration associates a Microsoft, not tenant domain, email address with a Teams channel. Channel emails are addressed using the Microsoft-owned domain
<teams.ms>. By disabling Teams email integration, an agency prevents potentially sensitive Teams messages from being sent through external email gateways. - Last modified: July 2023
- Note: Teams email integration is not applicable to Government Community Cloud (GCC), GCC High, and Department of Defense (DoD) tenants.
- NIST SP 800-53 Rev. 5 FedRAMP High Baseline Mapping: SI-8, SC-7(10)(a), AC-4
- MITRE ATT&CK TTP Mapping:
Resources
License Requirements
- N/A
Implementation
MS.TEAMS.4.1v1 Instructions
-
Sign in to the Microsoft Teams admin center.
-
Select Teams > Teams Settings.
-
Under the Email integration section, set Users can send emails to a channel email address to Off.
5. App Management
This section helps reduce security risks related to app integration with Microsoft Teams. Teams can integrate with the following classes of apps:
-
Microsoft apps: apps published by Microsoft.
-
Third-party apps: apps not authored by Microsoft, published to the Teams store.
-
Custom apps: apps not published to the Teams store, such as apps under development, that users sideload into Teams.
Policies
MS.TEAMS.5.1v2
Agencies SHOULD only allow installation of Microsoft apps approved by the agency.
- Rationale: Allowing Teams integration with all Microsoft apps can expose the agency to potential vulnerabilities present in those apps. By only allowing specific apps and blocking all others, the agency can better manage app integration and potential exposure points.
- Last modified: August 2025
- Note: This policy applies to the Global (Org-wide default) policy, all custom policies, and the org-wide app settings. Custom policies MAY be created to allow more flexibility for specific users.
- NIST SP 800-53 Rev. 5 FedRAMP High Baseline Mapping: CM-11
- MITRE ATT&CK TTP Mapping:
MS.TEAMS.5.2v2
Agencies SHOULD only allow installation of third-party apps approved by the agency.
- Rationale: Allowing Teams integration with third-party apps can expose the agency to potential vulnerabilities present in an app not managed by the agency. By allowing only specific apps approved by the agency and blocking all others, the agency can limit its exposure to third-party app vulnerabilities.
- Last modified: August 2025
- Note: This policy applies to the Global (Org-wide default) policy, all custom policies if they exist, and the org-wide settings. Custom policies MAY be created to allow more flexibility for specific users. Third-party apps are not available in GCC, GCC High, or DoD regions.
- NIST SP 800-53 Rev. 5 FedRAMP High Baseline Mapping: CM-11
- MITRE ATT&CK TTP Mapping:
MS.TEAMS.5.3v2
Agencies SHOULD only allow installation of custom apps approved by the agency.
- Rationale: Allowing custom apps integration can expose the agency to potential vulnerabilities present in an app not managed by the agency. By allowing only specific apps approved by the agency and blocking all others, the agency can limit its exposure to custom app vulnerabilities.
- Last modified: August 2025
- Note: This policy applies to the Global (Org-wide default) policy, all custom policies if they exist, and the org-wide settings. Custom policies MAY be created to allow more flexibility for specific users. Custom apps are not available in GCC, GCC High, or DoD regions.
- NIST SP 800-53 Rev. 5 FedRAMP High Baseline Mapping: CM-11
- MITRE ATT&CK TTP Mapping:
Resources
License Requirements
- N/A
Implementation
NOTE: The Teams admin portal has been updated and the manner in which applications are controlled has changed. The MS.TEAMS.5.#v2 policies follow the new manner of implementing the policies. Newer Tenants, created within 2024 and newer will follow the newer version 2 policy implementation steps while older tenants will follow the legacy implementation steps.
ScubaGear will continue to look for and gather the legacy policies when running in any mode. However, there a limitation in the API when gathering the data for the report. Users must utilize interactive mode to allow ScubaGear to gather the data for the newer portal based settings.
NOTE: Legacy implementation instructions are below the Version 2 intructions. If your tenant has the Version 2 settings available, there is no need to perform the legacy implementation instructions.
MS.TEAMS.5.1v2 Instructions
-
Sign in to the Microsoft Teams admin center.
-
Select Teams apps > Manage apps.
-
In the upper right-hand corner select Actions
-
Select Org-wide app settings.
-
Under Microsoft apps > Select On
-
Click Save.
NOTE: This will make Microsoft apps in the application list available to “Everyone.” If adjustments are needed follow the remaining instructions
-
Select Teams apps > Manage apps.
-
Select each individual app.
-
Select Users and groups > Edit availability
-
Change Available to to the appropriate setting for your organization. (Everyone, Specific users or groups, or No one)
-
Repeat steps 7 to 10 for each application
MS.TEAMS.5.2v2 Instructions
-
Sign in to the Microsoft Teams admin center.
-
Select Teams apps > Manage apps.
-
In the upper right-hand corner select Actions
-
Select Org-wide app settings.
-
Under Third-party apps > Select Off
-
Click Save.
NOTE: This will make third party apps in the application list available to “No one.” If adjustments are needed follow the remaining instructions
-
Select Teams apps > Manage apps.
-
Select each individual app.
-
Select Users and groups > Edit availability
-
Change Available to to the appropriate setting for your organization. (Everyone, Specific users or groups, or No one)
-
Repeat steps 7 to 10 for each application
MS.TEAMS.5.3v2 Instructions
-
Sign in to the Microsoft Teams admin center.
-
Select Teams apps > Manage apps.
-
In the upper right-hand corner select Actions
-
Select Org-wide app settings.
-
Under Custom apps > Select Off
-
Click Save.
NOTE: This will make Custom apps in the application list available to “No one.” If adjustments are needed follow the remaining instructions
-
Select Teams apps > Manage apps.
-
Select each individual app.
-
Select Users and groups > Edit availability
-
Change Available to to the appropriate setting for your organization. (Everyone, Specific users or groups, or No one)
-
Repeat steps 7 to 10 for each application
Legacy Policy Implementation
NOTE: Only Implement these settings if the v2 settings above are not available in your tenant.
Legacy MS.TEAMS.5.1v1 Instructions
-
Sign in to the Microsoft Teams admin center.
-
Select Teams apps > Permission policies.
-
Select Global (Org-wide default).
-
Under Microsoft apps, select Allow specific apps and block all others or Block all apps.
-
Click Allow apps.
-
Search and Click Add to all appropriate Microsoft Apps.
-
Click Allow.
-
Click Save.
-
If custom policies have been created, repeat these steps for each policy, selecting the appropriate policy in step 3.
Legacy MS.TEAMS.5.2v1 Instructions
-
Sign in to the Microsoft Teams admin center.
-
Select Teams apps > Manage apps.
- Select Org-wide app settings button to access pop-up options.
- Under Third-party apps turn off Third-party apps.
- Click Save.
-
Select Teams apps > Permission policies.
-
Select Global (Org-wide default).
-
Set Third-party apps to Block all apps, unless specific apps have been approved by the agency, in which case select Allow specific apps and block all others.
-
Click Save.
- If custom policies have been created, repeat steps 4 to 7 for each policy, selecting the appropriate policy in step 5.
Legacy MS.TEAMS.5.3v1 Instructions
-
Sign in to the Microsoft Teams admin center.
-
Select Teams apps > Manage apps.
- Select Org-wide app settings button to access pop-up options.
- Under Custom apps turn off Interaction with custom apps.
- Click Save.
-
Select Teams apps > Permission policies.
-
Select Global (Org-wide default).
-
Set Custom apps to Block all apps, unless specific apps have been approved by the agency, in which case select Allow specific apps and block all others.
-
Click Save.
- If custom policies have been created, repeat steps 4 to 7 for each policy, selecting the appropriate policy in step 5.
Appendix A - Custom Meeting Policies
If there is a legitimate business need, custom meeting policies can be defined with specific users assigned to them. For example, custom meeting policies can be configured with specific users having permission to record meetings. To allow specific users the ability to record meetings:
-
Sign in to the Microsoft Teams admin center.
-
Select Meetings > Meeting policies.
-
Create a new policy by selecting Add. Give this new policy a name and appropriate description.
-
Under the Recording & transcription section, set Cloud recording to On.
-
Select Save.
-
After selecting Save, a table displays the set of policies. Select the row containing the new policy, then select Manage users.
-
Assign the users who need the ability to record to this policy.
-
Select Apply.
TLP:CLEAR
-
Note that B2B guest users and all anonymous users except for external users appear in Teams calls as John Doe (Guest). To avoid potential confusion, true guest users are always referred to as B2B guest users in this document. ↩