Before a Teams deployment goes live — or before you inherit an existing one — there are a set of security settings worth verifying systematically. This isn't a comprehensive security hardening guide; it's a checklist of the settings that are most commonly misconfigured and that carry the highest risk if left at defaults.
Authentication and Identity
Multi-factor authentication. This should be non-negotiable for all users, including administrators. Teams inherits the MFA policy from Azure Active Directory (Entra ID) — there's no separate MFA setting in the Teams Admin Center. If MFA isn't enforced for all users in your tenant, address that before focusing on any Teams-specific security settings.
Modern authentication. Ensure modern authentication (OAuth 2.0-based) is enabled for your tenant. Legacy authentication protocols (basic auth) bypass conditional access and MFA, which makes them a primary attack vector. Modern authentication should be enabled and legacy authentication blocked via Conditional Access policy.
Conditional Access policies. Review whether Conditional Access is configured to require MFA for Teams (and Office 365 generally), to block access from non-compliant devices if your organisation manages endpoints, and to restrict access from high-risk locations or sign-ins. We cover Conditional Access for Teams in a dedicated article.
Guest Access
Guest access is enabled intentionally. Guest access in Teams allows external users to be added to specific teams as guests. Verify whether guest access is enabled or disabled in your tenant (Teams Admin Center > Org-wide settings > Guest access). If it's enabled, it should be enabled because you've made an active governance decision to allow guest collaboration — not because it was left on by default.
Guest capabilities are restricted appropriately. Even when guest access is enabled, you can restrict what guests can do. Review the guest access settings and confirm: can guests make private calls? Can they share content in meetings? Can they use chat? Adjust these based on your use cases, not defaults.
Guest accounts are reviewed periodically. Guest accounts remain in your Entra ID tenant until removed. If you allow guest access, you need a periodic review process to identify and remove guests who are no longer active collaborators. Consider using Entra ID access reviews to automate this.
External Access (Federation)
Federation scope is intentional. Teams external access (Org-wide settings > External access) controls federation with other Microsoft 365 tenants and Skype users. The default allows all external domains. For many organisations, this is appropriate. For regulated industries or organisations with strict information control requirements, you should restrict federation to specific allowed domains. Review and confirm the current setting is intentional.
Skype consumer integration. This setting controls whether Teams users can communicate with Skype personal account users. This is off by default in newer tenants and should generally remain off for enterprise deployments.
App Security
App permission policy. The default app permission policy allows all apps from Microsoft, third-party publishers, and custom apps. For security-conscious organisations, tighten this: allow only Microsoft apps by default, and require IT review before third-party apps are permitted. App permission policies are configured in Teams Admin Center > Teams apps > Permission policies.
Custom app uploads. Can users upload custom apps (side-loading)? This is controlled in the org-wide app settings. For most enterprises, custom app upload should be restricted to admins only. Users uploading untested custom apps is a significant security risk.
Data Protection
Sensitivity labels are configured. If your organisation has sensitivity or classification requirements, verify that sensitivity labels are published to Teams users and that the appropriate default label is applied to new teams. Labels enforce access controls at the SharePoint site level, which provides meaningful data protection beyond the Teams interface.
DLP policies cover Teams. Microsoft Purview DLP policies can inspect content shared in Teams chats and channels. Verify whether DLP is enabled for Teams and whether the policies cover the content types you're required to protect (PII, financial data, health information, etc.).
Retention policies are in place. Confirm that Microsoft Purview retention policies are configured for Teams chats and channel messages. This is both a compliance requirement for many industries and a data governance baseline for any organisation.
Audit and Monitoring
Audit logging is enabled. Microsoft 365 audit logging records user and admin activity across Teams, SharePoint, Exchange, and other services. Confirm that audit logging is enabled for your tenant (Microsoft Purview compliance portal > Audit). Without audit logging, you can't investigate incidents after the fact.
Audit log retention is sufficient. Standard audit log retention is 90 days. Microsoft 365 E3 includes one year; Microsoft 365 E5 includes ten years. Know your retention duration and ensure it meets your compliance requirements.
Admin activity is monitored. Admin changes in the Teams Admin Center (policy changes, user assignments, org-wide setting changes) are logged. Review the admin audit log periodically, especially after any period of elevated change activity.
Meeting Security
Anonymous join is off. Confirm that "Let anonymous people start a meeting" is disabled in your meeting policy. This prevents anonymous attendees from having unsupervised access to meeting rooms without an authenticated user present.
Lobby settings are appropriate. Review the default "Automatically admit people" setting in meeting policies. For most enterprises, "People in my organisation and guests" (not "Everyone") is the appropriate default.
External participant control is off. The "Allow external participants to give or request control" setting should be off in your meeting policies. This prevents external attendees from taking control of a screen share.
A Checklist Run Against One Business Unit
A tenant-wide security checklist proves that settings exist. It does not prove they cover the people who handle the data that matters. The useful run is scoped: pick one business unit, list its accounts, and compare those accounts to the policies the checklist claims are in force.
An energy utility with about 2,200 Microsoft Teams users did this for the trading desk rather than for the whole company. Multi-factor authentication was required by a conditional access policy aimed at "all users", with an exclusion for a break-glass group and a second exclusion that had grown to include a vendor support account, two service accounts, and eleven people who had failed a rollout. Four of the eleven still worked on the trading floor. The checklist item "MFA required" was true for the policy's target and false for the people the business unit actually worried about.
Run the same comparison for guest access, external federation, app permission, and meeting recording. For each item, write the setting, the group it is assigned to, and the exception list with an owner and a review date. An exception without a review date is a finding, even if the setting itself looks strict.
App permission policies deserve a line of their own because they drift. A custom app allowed for a pilot in one region is still allowed after the pilot ends if nobody removes the assignment. Pull the app permission policy applied to the business unit and list third-party apps that are not on the approved catalogue. That list is the remediation queue.
- Export the business unit's user ids and the effective Teams policies for messaging, meeting, and app permission.
- Export conditional access exclusions and match them to those user ids.
- List guests who are members of the unit's teams, with last sign-in.
- Note any meeting policy that still allows anonymous join where the unit's standard forbids it.
- Attach the exports to the checklist so the next review starts from evidence rather than from memory.
Repeat the scoped run for a second unit before calling the checklist done. A control that holds for traders and fails for field engineers is not a tenant control. It is a control with a hole, and the hole is the part an audit will find if the sample is unlucky.
Store the checklist in the same place as the exports, with the date of the run in the file name. If a setting can only be checked in PowerShell, paste the command under the checklist item so the next run does not depend on a remembered cmdlet. Break-glass accounts belong on the exception list on purpose. Hidden exclusions are the ones that fail a review. Do not mark an item pass because a licence includes the feature. Pass means the feature is configured and assigned. A failed item needs an owner and a date. A checklist without owners is a catalogue of worries. Re-run the scoped check after any tenant-wide policy change, not only on the annual calendar. Repeat the scoped check after a merger or a large hire. The exclusion lists are where new accounts hide. Write the expected setting next to the actual setting. A checklist of actuals alone has nothing to fail against. If a control is delegated to a local admin, the checklist still records it. Delegation is not invisibility. Guest accounts used by vendors belong in the same scoped export as employees of that business unit. A pass on paper and a fail in the effective policy means the assignment is wrong. Believe the effective policy. Store screenshots only as a supplement. The export is what you can diff next quarter. Note the licence level beside any control that quietly stops enforcing when the licence is removed. The second business unit should be one that complains the least. Quiet units are where unchecked exceptions live.
