When a Teams rollout nears production — or when you inherit one already running — a specific cluster of security settings merits a systematic pass. Treat this not as an exhaustive hardening manual but as a list of the configurations most often set up wrong, and the ones that carry the greatest danger when left at their defaults.
Identity and Authentication
Multi-factor authentication. Treat it as compulsory for everyone, administrators included. Teams draws its MFA policy from the directory service (the identity service) — the Teams Admin Center holds no standalone MFA control. If MFA is not enforced across every user in your tenant, put that right before turning to any Teams-specific controls.
Modern authentication. Verify that modern authentication (built on OAuth 2.0) is switched on for your tenant. Older methods (basic auth) bypass conditional access and MFA, which makes them a leading attack path. Modern authentication should be enabled, with legacy authentication blocked through a Conditional Access policy.
Conditional Access policies. Establish whether Conditional Access is configured to require MFA for Teams (and the cloud suite overall), to block access from non-compliant devices where your organisation manages endpoints, and to restrict access from risky sign-ins or locations. Conditional Access for Teams is covered in its own dedicated article.
Access for Guests
Guest access is enabled on purpose. Guest access in Teams lets external people join particular teams as guests. Establish whether it is switched on or off in your tenant (Teams Admin Center > Org-wide settings > Guest access). If it is on, it should be on because permitting guest collaboration was a deliberate choice — not because the default was never touched.
Guest capabilities are properly limited. Even with guest access switched on, what guests can do remains constrainable. Work through the guest access settings and decide: may guests chat? Share content during meetings? Place private calls? Configure these against your scenarios rather than leaving the defaults.
Guest accounts get reviewed on a schedule. Guest accounts remain in your the identity service tenant until someone removes them. Permitting guest access therefore requires a recurring review that spots and removes guests who no longer collaborate. The identity service access reviews can automate that for you.
Federation and External Access
Federation scope is chosen deliberately. Teams external access (Org-wide settings > External access) governs federation with the legacy messenger users and with other the cloud suite tenants. Every external domain is allowed by default, which suits plenty of organisations. Where information control is tight or the sector is regulated, federation should be confined to a specific allow-list of domains. Review the current value and make sure it reflects a decision.
the legacy messenger consumer integration. This setting determines whether Teams users may communicate with users of personal the legacy messenger accounts. Newer tenants default it to off, and for enterprise rollouts it should typically stay off.
Security of Apps
App permission policy. As shipped, the app permission policy permits everything: vendor apps, custom apps, and apps from outside publishers. Security-minded organisations should narrow it — vendor apps only by default, with an IT review required before any third-party app is cleared. These policies sit in Teams Admin Center > Teams apps > Permission policies.
Custom app uploads. Are users permitted to upload custom apps (side-loading)? The toggle for that lives in the org-wide app settings. In most enterprises, custom app uploads should be restricted to admins alone; letting users load untested custom apps creates a serious security exposure.
Protection of Data
Sensitivity labels are configured. Where your organisation carries classification or sensitivity requirements, verify that sensitivity labels are published to Teams users and that a sensible default label applies to new teams. Labels push access controls down to the file service site level, delivering genuine data protection that reaches beyond the Teams interface.
DLP policies cover Teams. the compliance portal DLP policies are able to scan content shared in Teams chats and channels. Verify that DLP is active for Teams and that the policies cover the categories of content you are obliged to protect (health information, financial data, PII, and so on).
Retention policies are in place. Check that the compliance portal retention policies cover Teams channel messages and chats. For many industries this is a regulatory obligation; for every organisation it is a baseline of sound data governance.
Monitoring and Auditing
Audit logging is enabled. the cloud suite audit logging records user and admin activity across the other services, Exchange, the file service, and Teams. Confirm it is switched on for your tenant (the compliance portal > Audit) — without it, an incident cannot be investigated after the fact.
Audit log retention is sufficient. Ninety days is the standard retention window. One year comes with the E3 plan, ten years with the E5 plan. Know how long your logs are kept and verify that it satisfies your compliance obligations.
Admin activity is monitored. The Teams Admin Center logs admin actions — org-wide setting changes, user assignments, policy edits. Examine the admin audit log on a regular basis, and especially after any period of heavy change.
Security of Meetings
Anonymous join is switched off. In your meeting policy, confirm that "Let anonymous people start a meeting" is disabled. This prevents anonymous attendees from slipping into meeting rooms unsupervised before an authenticated user arrives.
Lobby settings are sensible. Review the default "Automatically admit people" value in the meeting policies. For most enterprises the correct default is "People in my organisation and guests", not "Everyone".
External participant control is off. The meeting policies should keep "Allow external participants to give or request control" disabled, preventing external attendees from seizing control of a screen share.
Applying the Checklist to One Business Unit
A tenant-wide security checklist confirms that the settings exist. What it cannot confirm is that they shield the people who handle the data that matters. The worthwhile run is the scoped one: pick a single business unit, enumerate its accounts, and line those accounts up against the policies the checklist claims are in effect.
An energy utility with roughly 2,200 Teams users ran this for the trading desk rather than the whole company. Multi-factor authentication was required by a conditional access policy aimed at "all users", carved out by an exclusion for a break-glass group and a second exclusion that had swollen to embrace a vendor support account, two service accounts, and eleven people who had slipped through during a rollout. Four of those eleven were still on the trading floor. The checklist line "MFA required" was true for the policy's target yet false for the very people the business unit cared about most.
Run the same cross-check for meeting recording, app permission, external federation, and guest access. For each item, note the setting, the group it applies to, and the exception list together with an owner and a review date. An exception lacking a review date is itself a finding, even where the setting looks strict.
App permission policies deserve their own entry because they drift. A custom app cleared for a pilot in one region stays cleared once the pilot ends, unless somebody removes the assignment. Pull the app permission policy applied to the business unit and list the third-party apps that are absent from the approved catalogue — that list is your remediation queue.
- Export the business unit's user ids alongside the effective Teams policies for app permission, meeting, and messaging.
- Export the conditional access exclusions and reconcile them with those user ids.
- List the guests on the unit's teams, together with their last sign-in.
- Flag 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 recollection.
Complete a second scoped run for another unit before declaring the checklist finished. A control that works for traders but breaks for field engineers is not a tenant control. It is a control with a gap, and that gap is exactly what an audit will surface if the sample happens to land there.
Keep the checklist with the exports, dating the run in the file name. When a setting can only be verified in PowerShell, paste the command under the checklist item so the next run does not hinge on recalling a cmdlet. Break-glass accounts belong on the exception list deliberately — it is the undocumented exclusions that fail a review. Never mark an item as a pass simply because a licence bundles the feature; a pass means the feature is configured and assigned. A failed item needs an owner and a date, and a checklist with no owners is just a list of concerns. Re-run the scoped check after any tenant-wide policy change, not merely once a year. Repeat it after a merger or a wave of new hires — exclusion lists are precisely where new accounts tend to hide. Note the expected setting beside the actual one; a checklist of actuals alone has nothing to measure against. If a control is delegated to a local admin, the checklist still logs it; delegation does not mean invisibility. Guest accounts used by vendors belong in the same scoped export as that business unit's employees. A paper pass contradicted by a failure in the effective policy means the assignment is wrong — trust the effective policy. Keep screenshots only as a supplement; the export is what you can diff next quarter. Note the licence tier beside any control that quietly stops enforcing once the licence is pulled. Make the second business unit the one that raises the fewest complaints; quiet units are where unchecked exceptions tend to live.
