Guest access in Microsoft Teams allows people outside your organisation to be added to specific teams as guests. A guest can participate in channels, attend meetings, share files, and collaborate in the same ways as internal members — but they're governed by your organisation's Teams policies, not their own.
Guest access is one of the most common sources of governance questions. Who can add guests? What can guests do? How do you ensure guests are removed when the collaboration ends? This article covers the configuration and governance of guest access from end to end.
The Three Levels of Guest Access Control
Guest access in Teams is controlled at three levels, and all three need to be considered together:
Level 1: Azure Active Directory (Entra ID) external collaboration settings. This is the tenant-level switch. In the Entra ID admin center, under External identities > External collaboration settings, you control whether guest invitations are allowed at all in your tenant, who can invite guests, and whether guests can invite others. If external collaboration is blocked at this level, Teams guest access cannot work regardless of Teams settings.
Level 2: Teams org-wide guest access settings. In the Teams Admin Center under Org-wide settings > Guest access, there's a master toggle: "Allow guest access in Teams." This must be enabled for any guest users to participate in Teams. Additional settings here control what guests can do: make private calls, use Meet Now, share screens, use messaging features.
Level 3: Team-level controls. Individual team owners can control whether their specific team allows guests. Under Team settings > Member permissions, team owners can enable or disable guest access for their team, independent of the org-wide setting.
Who Can Add Guests?
By default, team owners can add guests. This means any team owner can add any external email address as a guest to their team, without any IT approval step. For many organisations, this is appropriate — team owners are responsible for their teams and should be trusted to manage membership.
For organisations that need tighter control over who can collaborate externally, you can restrict guest invitations at the Entra ID level to specific users (e.g., only members of the HR or IT team can send guest invitations). This creates a centralised control point but adds friction to legitimate collaboration workflows.
What Guests Can and Cannot Do
Guests in Teams have a different experience from internal users. By default, guests can access channels and conversations in teams they've been invited to, share and receive files, participate in meetings, and access tab content. Guests cannot search the directory for internal users, view the org chart, access channels in teams they haven't been invited to, or use certain premium features.
You can further restrict guest capabilities in the org-wide guest access settings: disable calling, disable Meet Now, disable screen sharing, disable messaging features. For high-security environments, restricting guests to read-only participation (messaging and calling disabled) is sometimes appropriate.
Governance: Keeping Guest Membership Clean
The most common guest access governance failure isn't in the initial configuration — it's in the ongoing management. Guests are added, the project ends, but the guest account remains in your Entra ID tenant indefinitely. After two or three years, you may have hundreds of stale guest accounts with no clear connection to active work.
Technical solution: Entra ID access reviews. Access reviews are a feature of Entra ID Governance (requires P2 or Governance licensing) that periodically asks team owners (or other reviewers) to confirm that specific guest users still need access. If the reviewer doesn't respond, the guest's access can be automatically removed. This is the right mechanism for organisations that have significant guest usage and need a defensible access review process.
For organisations without Entra ID Governance licensing, a manual periodic review process can work: a quarterly report of all guest accounts and their last activity date, reviewed by IT and team owners, with inactive guests removed.
Guest Account Lifecycle
When a guest is invited to Teams, a guest account is created in your Entra ID tenant. When the guest is removed from all teams and groups, the guest account should be deleted — but it isn't automatically. You need to explicitly delete the guest account in Entra ID to fully remove the external user.
Build this cleanup into your guest lifecycle process: when a guest is removed from a team (or when a team is archived), check whether the guest has access to any other teams in your tenant. If not, delete the guest account from Entra ID.
Sensitivity Labels and Guest Access
As covered in the sensitivity labels article, sensitivity labels on Teams can control whether team owners can add guests to a specific team. For teams classified as "Confidential" or "Highly Confidential," the label can enforce a "no guests" policy regardless of the team owner's preferences. This is the cleanest way to ensure that high-sensitivity teams don't inadvertently allow external access.
Guests Who Outlive the Project That Invited Them
Guest access in Microsoft Teams is a membership problem that looks like a settings problem. The org-wide switch, the per-team setting, and the sensitivity label decide whether a guest can be added. None of them notice that the project ended. The guest account remains, the team remains, and the files remain available to an external mail address that may now belong to someone else at that company.
A software vendor with about 250 employees ran an implementation with a client and invited eight client staff as guests into the project team. The project closed in November. In April the same client addresses were still members, and two of them had signed in during March to fetch a statement of work that was never meant to stay available. The guest policy was "on, owners may invite", which was the intended setting. The missing piece was a removal date written down when the invitation was sent.
Put the removal date on the invitation itself. The owner who clicks Add member should know the date the guest is expected to leave, and a monthly job should list guests whose teams have had no activity for 90 days or whose invitation is older than the standard engagement length. Removal is a membership edit, not a deletion of the guest object from the directory. Decide both: remove from the team, and disable or delete the guest account if it has no remaining memberships.
- Guests with no team membership and no sign-in for 60 days are deletion candidates.
- Guests on an inactive team stay until the team is archived or they are removed. Inactivity of the team is not removal.
- A guest who is also a member of a second, active team must not be deleted from the directory just because the first project ended.
- Access reviews, where the licence exists, push the decision back to the owner on a schedule instead of relying on a spreadsheet.
- Re-inviting a removed guest creates a new acceptance flow. Warn owners so they do not treat removal as reversible with a silent click.
Sensitivity labels that forbid guests will block new additions and still leave old guests in place, as with any label applied after the fact. A guest review and a labelling project solve different halves of the same exposure. Running only one of them leaves the other half open.
Count guests as a headline number next to employee count. A guest population larger than a department deserves a named owner. External mail addresses from free consumer domains may be legitimate contractors or may be a mistake. The review asks which, rather than banning the domain blindly. Shared channels add another membership list. A guest review that only reads the team roster will miss people who sit only on a shared channel. Disable guest invitations tenant-wide only if the business has agreed to a different collaboration path. A silent disable becomes a shadow-IT problem. Keep the invitation text honest about what the guest will be able to see. Surprise access is how guest reviews turn into incidents. After removal, search the audit log for that guest's activity in the prior week so the owner knows what was touched. A guest's display name is not an identity. Match on the mail address when you compare months. Owners who have left cannot review their guests. Reassign the team before you send the review. Bulk invitation tools should write the engagement end date into a tracked field, or the monthly job has nothing to read. Deleting a guest who still has a file open does not recall the file they already downloaded. Say that in the review note. Shared mailboxes should not be used as guest identities. They obscure who actually read the channel. If access reviews are not licensed, the spreadsheet still needs a due date and a named chaser. Re-check teams whose label changed in the last month. The label may now forbid guests the roster still contains. A guest who is an owner is a priority removal or a conscious exception. Do not leave it in the ordinary pile. Consumer mail addresses invited into a staff team are a different risk from a partner domain on a project team. Split the report.
