Custom Teams App Governance: Six Requirements

Governance and Architecture Requirements for Custom Teams Apps

By Michael Branson

Quick answer. Custom Teams app governance requires six things: an admin-approved catalog route, permissions reviewed before consent, per-app access, Microsoft Entra ID sign-in, a documented data boundary, and re-review at every version. Teams admin center has a control for the first three; your review demands the rest.

A custom app built for one department reaches your security review carrying Microsoft Graph permissions nobody scoped, and the review has no written bar to hold it to. The six requirements here are that bar, for apps your organization builds or commissions to run inside its own tenant. They cover the app, not the Teams environment it runs in. Apps built in Power Apps follow a Power Platform Governance Framework of their own, and agents built in Copilot Studio are governed as described in Copilot Studio Governance for Enterprise Agent Estates.

Requirement 1: an admin-approved catalog route

When your organization commissions an app for its own people, Microsoft treats it as a custom app: “Your organization can commission creation of Teams apps that work only within your organization.” It reaches users through your organization’s catalog, not the public Teams Store, and the catalog has two doors that the approval record has to cover.

The first door is user submission. Microsoft’s page on how to Manage custom apps in Microsoft Teams admin center states: “Submit option is available to all users and can’t be turned off. Admins can disapprove any submission.” A submitted app waits for an admin decision, so that decision is where your review sits.

Admin upload is the second door, and it has no waiting step: “If an admin uploads a custom app, it’s available in the organization’s catalog in the store without requiring any approval.” Require that an admin upload carries the same approval record as a submission, because Teams will not ask for one.

Restrict who can upload custom apps at all. Microsoft’s control is the app setup policy: “You apply app setup policy to specific users to allow or disallow them from uploading custom app in personal context or in a team.” Grant upload rights to named developers, and where you disallow upload in production, Microsoft notes that developers can create a separate test tenant to test apps.

Requirement 2: permissions reviewed before consent

Microsoft’s own instruction to admins is direct: “You must evaluate the compliance, security, and data handling information of an app and also understand the permissions requested by the app before you allow an app to be used by your users.” Read the app’s Permissions tab in Teams admin center before anyone grants consent, and keep the export in the approval record; Microsoft’s guide to Understand the permissions and information accessed by Teams apps notes “You can also download all the permissions in a .csv file”.

Two facts decide how hard that read has to be. Application permissions mean “An application acts on its own with no user signed in”, and admin consent widens the blast radius: “If you grant admin consent to such a permission in a Teams app, then all allowed users of your org can use the app and let the app access org’s information.” Record the privilege level Teams reports for the app; the high rating reads “The app has at least one high-privileged permission.”

Resource-specific consent or Microsoft Graph permissions

When an app works inside one team, chat or meeting, resource-specific consent (RSC) lets it limit its access to that resource. Microsoft’s description: “With RSC permissions, an app doesn’t have to request access to org-wide information and can limit the scope of its access.” RSC is declared differently (“Define RSC permissions in the app manifest and not in Microsoft Entra ID”), and the grant sits with the people who own the resource: “Only resource owners can grant application RSC permissions.”

The decision rule: if the app needs data from one team, chat or meeting, require RSC. If it needs data across the tenant, or runs with no signed-in user across many resources, accept Microsoft Graph application permissions with admin consent and a written justification for each permission. When the developer’s request and the app’s use disagree, the use wins: an app that works inside one team and asks for tenant-wide Graph access goes back for RSC.

Requirement 3: per-app access

If your tenant manages Teams apps today, access is now set app by app. Microsoft states: “Starting from April 2025, your tenant is automatically migrated to app centric management.” Under that model, “Each app contains its access definition using a list of users and groups that you assign to it.”

Require every custom app to start available to specific users and groups, the ones named in its approval record, and to widen only by a recorded decision. One limit belongs in that record too: if an app is restricted to specific users or groups, guests cannot use it. Microsoft’s wording: “Guests can’t use the app if this option is selected and even if guests are assigned to the app.”

Requirement 4: Microsoft Entra ID sign-in

Users of a custom app should sign in through the identity your tenant already governs. Microsoft describes single sign-on for a tab app this way: “Your app is available to app users on any device with access granted through Microsoft Entra ID.”

The architecture requirement is that the app’s consent path matches your tenant’s consent policy, confirmed before the build starts. The reason is Microsoft’s own warning: “Microsoft Entra tenant consent policies can block user consent and require administrator approval, even for permissions that don’t generally require administrator consent.” An app designed around user consent, in a tenant whose policy blocks it, waits on administrator approval instead. How the consent policy itself is designed belongs to Microsoft Entra ID Governance for Regulated Enterprises, not to the app review.

Requirement 5: a documented data boundary

Messages and files sent to a bot leave your corporate network. Microsoft’s permissions guide says it twice: “Bots only receive messages in chats where users explicitly mention a bot by its name. This data leaves the corporate network.” and “When a file is sent to a bot, the file leaves the corporate network.”

Require a data-flow record for each app that names every endpoint the app calls, where each endpoint is hosted, and which classes of data it receives. The review compares that record with the app package and the Permissions tab export; an endpoint in the package that the record does not name sends the app back.

In GCC, Microsoft adds two conditions for apps published to your organization: “make sure that all the agent or app’s endpoints comply with your GCC organization’s requirements”, and “If your agent or app includes a bot or message extension, you must select the Microsoft Teams for Government option when setting up a channel between your bot and Teams in Azure.”

Requirement 6: re-review at every version

When a developer publishes a new package, nothing resets. Microsoft states: “When a new version of an app is published, the existing policies that applied to the previous version of the app continue to be in effect for the updated version.” Consent also carries over the app centric migration: “After migration, any admin consent to app permissions that was previously granted is retained.”

Because access and consent carry forward on their own, i3solutions recommends treating each new version as a new review of permissions and endpoints; that is our recommendation, drawn from Microsoft’s behavior, not a Microsoft rule. Retirement is the last version decision, and it is final for users: “The deleted app isn’t available in your org. Existing app users also can’t use it anymore.”

The six requirements at a glance

When two requirements point different ways for one app, the narrower setting wins until the approval record says otherwise: an app whose data boundary is not yet documented stays assigned to its named users and groups, whatever its access request asks for.

What must be true before custom apps are governed

Before the first custom app is approved, the six requirements lean on tenant controls that carry their own licensing, and Microsoft’s 2023 Teams governance planning page states two of those prerequisites in wording its current pages have since replaced. Read at Microsoft’s current pages on 2026-09-18:

• Access reviews, the Microsoft Entra control that recertifies who holds access to groups and enterprise applications, per Microsoft Entra ID Governance licensing fundamentals: “Using this feature requires a Microsoft Entra ID Governance subscription for your organization’s member users, including for all employees who are reviewing access or having their access reviewed.” Microsoft’s access reviews overview adds that some capabilities operate with Microsoft Entra ID P2. The 2023 page’s “P2” entry for access reviews is superseded.
• Group expiration still requires Microsoft Entra ID P1 or P2, per Microsoft’s page on the expiration policy for Microsoft 365 groups: you must “possess but not necessarily assign Microsoft Entra ID P1 or P2 licenses for the members of all groups to which the expiration policy is applied.”
• Retention for Teams chats and channels is licensed more widely than the 2023 page’s “Microsoft 365 or Office 365 Enterprise E3 or above”. For Teams chats, channels and private channels, the current Microsoft Purview service description lists Microsoft 365 E3, E5, F3 and F1, Office 365 E1, E3, E5 and F3, and Business Basic, Business Standard and Business Premium, plus the education and government versions it names beside them; for some of those plans the retention or deletion period must be more than 30 days.

Two lines belong in the approval record before the first app is approved. Every custom app has one named owner who signs its approval and answers for each re-review. Each app also carries a review cadence set in that record: a review at every new version, plus a recurring access review of the groups assigned to it. Deciding the environment governance these apps run inside, and whether the licensing above is in place, is the work of the Teams Enterprise Readiness Assessment described on Microsoft Teams Enterprise Development & Services.

How i3solutions reviews and builds custom Teams apps

When an app needs building as well as reviewing, i3solutions designs and builds custom Microsoft Teams apps and reviews them against these six requirements inside the customer’s own tenant. i3solutions operates within established enterprise risk management frameworks from day one: pre-built RACI matrices, documented access control procedures, and compliance reporting frameworks designed for regulated Microsoft environments. i3solutions is entirely U.S.-based. Every i3solutions employee is U.S.-based, every i3solutions project is U.S.-based, and every technology i3solutions delivers is U.S.-based. i3solutions has been a Microsoft partner since 1997.

If you need developers to build an app to these requirements, see Microsoft Teams Developers and Enterprise Specialists. If a custom app is waiting on your security review and one of the six requirements has no owner yet, bring the app’s package and its permissions export to the conversation. Contact a senior architect

Frequently Asked Questions

What should we require before approving a custom Teams app?

Require six things before approving a custom Teams app: an admin-approved catalog route, permissions reviewed before consent, per-app access, Microsoft Entra ID sign-in, a documented data boundary, and re-review at every version. Teams admin center has a control for the first three; the approval review demands and records the other three.

Can users get a custom Teams app into the org catalog without admin review?

No: when a user submits a custom Teams app, it waits for an admin to approve it, and Microsoft states that admins can disapprove any submission and that the submit option cannot be turned off. An app uploaded by an admin goes into the org catalog without an approval step, so your own process has to require an approval record for admin uploads.

When should a custom Teams app use resource-specific consent instead of Microsoft Graph permissions?

Use resource-specific consent when a custom Teams app needs data from one team, chat or meeting, because resource-specific consent lets the app limit its access to that resource and only the resource’s owners can grant its application permissions. Use Microsoft Graph application permissions, with admin consent and a written, recorded justification for each permission, only when the app needs data across the tenant or runs with no signed-in user.

Does an updated version of a custom Teams app need a new review?

When a developer publishes an updated version of a custom Teams app, Microsoft keeps the previous version’s policies in effect for it, and admin consent survives the move to app centric management. i3solutions recommends a new review of permissions and endpoints for each version, logged in the version review log, for that reason; the recommendation is ours, not a Microsoft rule.

Can guests use a custom Teams app limited to specific users and groups?

No: if a custom Teams app is restricted to specific users or groups, Microsoft states that guests cannot use it, even when a guest is assigned to the app.

What changes for custom Teams apps in GCC High?

Microsoft’s government cloud table shows that custom apps built for your organization can be distributed and used in GCC High, while uploading a custom app is not available in GCC High or DoD; Microsoft’s Teams app publishing guide states the same limit. Microsoft states: “Third-party apps are turned off by default for GCC and aren’t available for GCC High and DoD.” (Microsoft Learn) Microsoft also states: “Developer Portal isn’t available for GCC High, Department of Defense (DoD), and Teams operated by 21Vianet tenants.” (Microsoft Learn)

Do custom Teams apps need Microsoft 365 Certification?

If your custom Teams app is built for one tenant, note how Microsoft frames the program: Microsoft 365 Certification is one of the routes independent software vendors use to prove an app’s security and compliance, inside its Microsoft 365 App Compliance Program. Certified apps go through a yearly independent audit that includes penetration testing and reviews of data handling, privacy and security practices. Because the program is written for vendors, i3solutions recommends holding a custom Teams app built for one tenant to the same classes of evidence in your own review; that recommendation is ours, not a Microsoft requirement.