Teams guest access makes it possible to add people from outside your organisation to specific teams as guests. Channels can be participated in, meetings attended, files shared, and collaboration carried out in much the same way as internal members — except that your organisation's Teams policies govern them, not their own.
Governance questions arise around guest access more than almost any other area. Who is able to add guests? What are guests able to do? How do you make sure guests are removed once the collaboration ends? From end to end, this article covers the configuration and governance of guest access.
Three Levels of Control for Guest Access
Three levels control guest access in Teams, and all three must be considered together:
Level 1: the directory service (the identity service) external collaboration settings. This is the tenant-level switch. Under External identities > External collaboration settings in the identity service admin center, you decide whether guest invitations are permitted at all in your tenant, who is able to invite guests, and whether guests may invite others. Blocked at this level, external collaboration means Teams guest access cannot work regardless of the Teams settings.
Level 2: Teams org-wide guest access settings. Under Org-wide settings > Guest access in the Teams Admin Center sits a master toggle: "Allow guest access in Teams." Without this enabled, no guest users can participate in Teams. Further settings here govern what guests are able to do: messaging features, screen sharing, Meet Now, and private calls.
Level 3: Team-level controls. Whether a specific team allows guests is up to its individual owner. Under Team settings > Member permissions, owners can switch guest access on or off for their own team, independently of the org-wide setting.
Who Is Permitted to Add Guests?
Team owners can add guests by default. In practice, any team owner may add any external email address to their team as a guest, with no IT approval step involved. For many organisations this is the right arrangement — owners are accountable for their teams and should be trusted to manage membership.
Where tighter control is needed over who may collaborate externally, guest invitations can be restricted at the identity service level to specific users (for example, only members of IT or HR may send them). A centralised control point is created, but friction is added to legitimate collaboration workflows.
What Guests Are and Aren't Able to Do
The experience for guests in Teams differs from that of internal users. By default, guests can reach channels and conversations in teams they have been invited to, send and receive files, join meetings, and open tab content. Searching the directory for internal users, viewing the org chart, accessing channels in teams they have not been invited to, and certain premium features are all unavailable to guests.
Further restriction of guest capabilities is possible in the org-wide guest access settings: messaging features, screen sharing, Meet Now, and calling can each be disabled. In high-security environments, limiting guests to read-only participation with messaging and calling disabled is sometimes appropriate.
Governance: Keeping the Guest Roster Clean
The initial configuration is not where the most common guest access governance failure lies — it lies in ongoing management. Guests get added, the project finishes, yet the guest account stays in your the identity service tenant indefinitely. Two or three years on, you may find hundreds of stale guest accounts with no clear link to active work.
The technical solution: the identity service access reviews. Offered as part of the identity service Governance (P2 or Governance licensing required), access reviews periodically ask team owners or other reviewers to confirm that particular guest users still need access. Should the reviewer fail to respond, the guest's access can be dropped automatically. For organisations with significant guest usage that need a defensible access review process, this is the right mechanism.
A manual periodic review process can work for organisations lacking the identity service Governance licensing: every quarter, produce a report of all guest accounts with their last activity date, have IT and team owners review it, and remove inactive guests.
The Lifecycle of a Guest Account
Inviting a guest to Teams creates a guest account in your the identity service tenant. Once the guest has been removed from all teams and groups, the guest account ought to be deleted — but that does not happen automatically. Full removal of the external user requires you to explicitly delete the guest account in the identity service.
This cleanup belongs in your guest lifecycle process: whenever a guest is removed from a team, or a team is archived, check whether the guest still has access to any other teams in your tenant. Where none remain, delete the guest account from the identity service.
Guest Access and Sensitivity Labels
As the sensitivity labels article covers, labels applied to Teams can govern whether owners may add guests to a particular team. For teams classified as "Confidential" or "Highly Confidential," the label can impose a "no guests" policy irrespective of the owner's preferences. Nothing else is as clean a way to guarantee that high-sensitivity teams do not inadvertently permit external access.
Guests Who Survive the Project That Invited Them
Teams guest access presents a membership problem disguised as a settings problem. Whether a guest can be added is decided by the org-wide switch, the per-team setting, and the sensitivity label. Not one of them notices that the project has ended. The guest account stays, the team stays, and the files remain reachable by an external mail address that may now belong to somebody else at that company.
An implementation with a client was run by a software vendor with about 250 employees, and eight client staff were invited as guests into the project team. The project closed in November. By April those same client addresses were still members, and two of them had signed in during March to collect a statement of work that was never intended to remain available. The guest policy read "on, owners may invite", exactly the intended setting. What was missing was a removal date recorded when the invitation went out.
The removal date belongs on the invitation itself. The owner clicking Add member should know when the guest is expected to leave, and a monthly job should list guests whose teams have seen no activity for 90 days, or whose invitation predates the standard engagement length. Removal is a membership edit, not a deletion of the guest object from the directory. Decide both things: remove from the team, then disable or delete the guest account if it has no remaining memberships.
- A guest with no team membership and no sign-in for 60 days is a deletion candidate.
- Guests on an inactive team remain until the team is archived or they are removed. Team inactivity is not removal.
- That the first project ended is not a reason to delete from the directory a guest who is also a member of a second, active team.
- Where the licence exists, access reviews push the decision back to the owner on a schedule rather than depending on a spreadsheet.
- A removed guest, if re-invited, creates a fresh acceptance flow. Owners should be warned so they do not treat removal as something reversible with a silent click.
Sensitivity labels that forbid guests block new additions while leaving old guests in place, as with any label applied after the fact. Different halves of the same exposure are solved by a guest review and by a labelling project. Run only one of them and the other half stays open.
Track guests as a headline figure sitting next to employee count. A named owner is deserved by any guest population larger than a department. External mail addresses drawn from free consumer domains may belong to legitimate contractors or may be a mistake. Which one it is should be asked by the review, rather than banning the domain blindly. Shared channels bring yet another membership list. People who sit only on a shared channel will be missed by a guest review that reads only the team roster. Only disable guest invitations tenant-wide if the business has agreed a different collaboration path. Disable it silently and a shadow-IT problem follows. The invitation text should stay honest about what the guest will be able to see. Guest reviews turn into incidents when access surprises people. Once a guest is removed, search the audit log for their activity in the prior week so the owner knows what was touched. An identity is not a guest's display name. When comparing months, match on the mail address. Their guests cannot be reviewed by owners who have left. Reassign the team before the review goes out. Bulk invitation tools should write the engagement end date into a tracked field, otherwise the monthly job has nothing to read. Recalling a file a guest already downloaded does not happen when you delete a guest who still has it open. State that in the review note. Guest identities should never be shared mailboxes. Who actually read the channel is obscured by them. Even without access review licensing, the spreadsheet still needs a due date and a named chaser. Teams whose label changed in the last month deserve a re-check. The label may now forbid guests that the roster still contains. A guest who is an owner is either a priority removal or a conscious exception. It does not belong in the ordinary pile. The risk from consumer mail addresses invited into a staff team differs from that of a partner domain on a project team. Split the report accordingly.
