Teams apps: regaining control over what users install
Teams is not just a chat tool: it is a platform on which hundreds of third-party apps can be installed, read messages or access files. In many tenants the default settings have never been reviewed and nobody really knows which apps are in use or with which permissions.
What a Teams app can do
A Teams app can take the form of a tab, a bot, a messaging extension or a connector. Behind the interface it often relies on an application registered in Entra ID and on Microsoft Graph permissions: reading channel messages, accessing team files, viewing the user's calendar. An innocuous-looking app, such as a polling tool, can therefore gain broad access to data.
Governing Teams apps therefore happens at two levels: in Teams, to decide which apps can be installed and by whom, and in Entra ID, to control the permissions granted to those apps.
Org-wide settings
In the Teams admin centre, org-wide app settings define the overall framework:
- whether to allow third-party apps and new apps published to the store;
- whether to allow custom apps, developed in-house or supplied as a package;
- whether users can request a blocked app, which creates an approval path rather than a flat refusal.
These settings override everything else: a third-party app allowed in a policy remains unavailable if third-party apps are turned off at organisation level.
Permission policies or app centric management
Historically, app availability was managed through app permission policies assigned to users: "all Microsoft apps, these specific third-party apps, no custom apps". Microsoft is moving this model to app centric management, where each app carries its own availability: everyone, specific users or groups, or no one. Tenants are being migrated gradually and both models still coexist depending on the case; check which one applies in your admin centre.
Whatever the model, the approach is the same: start from an inventory of the apps actually installed, decide on each one, and define the default behaviour for new apps published by Microsoft and by third-party vendors.
Third-party apps and Graph permissions
Blocking an app in Teams does not remove the permissions its Entra ID application has already been granted. Conversely, an app allowed in Teams may request consent to data when it is installed. Two mechanisms deserve attention:
- standard consent to delegated or application permissions, governed by user consent settings in Entra ID;
- resource-specific consent (RSC), which lets a team or chat owner grant an app access to the data of that team or chat only, if the tenant settings allow it.
RSC is not trivial. A team owner who grants an app read access to all messages in their team opens up conversations they do not control alone. Decide explicitly whether this consent is allowed, and for whom, rather than leaving the default setting in place.
Custom app uploads
Uploading custom apps lets someone install an app from a package, without going through the store or the organisation's catalogue. Developers need it, but it is risky if open to everyone: a package can contain a bot or a tab pointing to any service. This right is controlled both in org-wide settings and in the setup policies assigned to users. Restrict it to an identified group of developers, and publish validated internal apps to the organisation's catalogue.
For monitoring, Teams app installations and removals are recorded in the unified audit log, which makes it possible to spot a new third-party app arriving in a sensitive team.
What an audit checks
- Org-wide app settings: third-party apps, custom apps, user requests.
- The management model in use and the actual availability of third-party apps.
- The inventory of installed apps and their publishers.
- Graph permissions granted to Teams apps in Entra ID.
- Resource-specific consent settings.
- Users allowed to upload custom apps.
- Monitoring of app installations in the audit log.