Catalog and publisher
Identify the exact app, publisher, app ID, distribution source, current version, support owner, certification information, and whether it is Microsoft-provided, third-party, custom, or a Copilot agent.
Microsoft Teams application governance
Teams App Permission Policy Review Guide
Determine who can use each Teams app or agent, which control model is authoritative, what data permissions were granted, and whether deployment, external participation, monitoring, and rollback match the approved business use.
App-centric management
Legacy permission policies
Consent and RSC
Custom app lifecycle
Audit evidence
Review objective
Review effective access—not the name of a policy page
Microsoft is replacing Teams app permission policies with app-centric management and is also unifying app availability between the Teams and Microsoft 365 admin centers. A credible review first identifies the tenant's active model, then proves the resulting experience for representative users.
Organization availability
Record org-wide defaults, individual app status, active app availability, and any unresolved difference between the Teams admin center and Microsoft 365 Integrated apps.
User and group scope
Prove whether access is Everyone, Specific users or groups, or No one—or, in a legacy tenant, which permission policy applies to each user and what the policy permits.
Permissions and consent
Separate app availability from Microsoft Graph delegated or application permissions, resource-specific consent, user consent, admin consent, and any new permission introduced by an app update.
Installation and context
Check app setup policy, admin preinstallation, pinning, personal, chat, channel, and meeting scopes, custom upload authority, and behavior for guests, external users, and anonymous attendees.
Evidence and lifecycle
Retain approval, risk decision, assignment source, test result, audit events, owner, review date, support data, version-change trigger, incident action, and a practical disable or revoke path.
Key distinction: allowing an app does not grant all permissions it requests, granting consent does not make the app available to every user, and pinning an app does not override a block. Each control answers a different question.
Control model decision
Identify whether the tenant uses app-centric management or legacy permission policies
Do not document both models as simultaneously authoritative. The Teams admin center itself is the primary evidence: migrated tenants no longer use permission policies for app access, while tenants that still display usable policies can continue with them until migration.
| Control question | App-centric management | Legacy permission policies | Evidence to retain |
|---|---|---|---|
| Where user access is defined | Per app on the Users and groups tab | Global or custom permission policy assigned to a user | Tenant mode, admin-center capture, export, review date |
| Available scopes | Everyone, Specific users or groups, or No one | Allow all, allow specific, block specific, or block all by Microsoft, third-party, and custom categories | App ID, assignment source, exact users/groups or policy name |
| Group support | Supported security, Microsoft 365, dynamic-user, nested, and distribution groups; guests are excluded from Specific users or groups | App permission policies do not support group policy assignment | Group type, membership owner, dynamic rule, exceptions |
| Migration behavior | Permission policies are replaced and the migration cannot be reversed | Inventory all assigned policies and conflicting app decisions before migration | Before/after exports, conflict decisions, auto-created groups, pilot tests |
| Propagation | Changes can take up to 24 hours and, rarely, longer in clients | Policy changes can take several hours | Change timestamp, validation window, client and user tests |
Migration caution: preserve the before-state and resolve conflicts before the transition. Microsoft documents a special auto-migration case in which a custom policy block can map differently when the global policy allows the app. Treat post-migration user testing as mandatory.
Evidence-first workflow
Run the review in a sequence that exposes hidden dependencies
Confirm tenant mode
Capture whether app-centric management is active, whether permission policies remain usable, and whether unified app management has synchronized Teams and Microsoft 365 admin centers.
Export the catalog
Export the app and agent catalog. Record app ID, publisher, type, status, availability, certification, permissions indicator, owner, business purpose, and risk tier.
Map org defaults
Document defaults for Microsoft, third-party, and custom apps. Identify apps individually managed outside those defaults and all apps set to No one or a restricted population.
Reconcile assignments
For app-centric tenants, map users/groups to each critical app. For legacy tenants, export global/custom policies and every direct user assignment.
Inspect consent
Review Graph delegated and application permissions, admin consent, user-consent policy, resource-specific consent, app registration, service principal, and version changes.
Check deployment
Compare access with setup policies, preinstall and pinning, custom-upload controls, team-level upload settings, and app availability in each supported scope.
Test real identities
Validate allowed, denied, new, guest, external, anonymous, and privileged populations across web, desktop, mobile, channel, chat, and meeting contexts as applicable.
Close with ownership
Assign approval, technical owner, data owner, support path, review date, evidence location, monitoring trigger, incident action, and rollback decision for every critical app.
App inventory and posture
Apply a deliberate default to each app family
| App family | What to inventory | Practical default | Escalation triggers | Proof to retain |
|---|---|---|---|---|
| Microsoft apps and agents | Business purpose, included service, data locations, user population, new feature exposure | Allow required workloads; restrict high-impact or unapproved experiences by population when supported | New agent, new scope, sensitive meeting/chat use, license or compliance change | Service owner, assignment, accepted data use, client test |
| Third-party apps | Publisher identity, certification, permissions, terms, privacy, data processor, support, renewal, usage | Default-deny or controlled-request model for regulated environments; scoped pilot before broad access | Broad Graph permission, external storage, unverified publisher, dormant owner, material update | Risk review, legal/privacy decision, consent record, scope, expiry |
| Custom apps | Source owner, app package and manifest, endpoints, credentials, RSC, release pipeline, support, rollback package | Separate development/test tenant; admin-published production package; least-privilege availability and upload rights | Manifest permission change, new domain, unsigned or unexpected package, owner departure | Hash/version, approval, test result, publisher, deployment record |
| Meeting apps and external bots | Host organization, participant type, recording/transcription behavior, data export, lobby/bot detection, organizer control | Permit only approved meeting use; require organizer awareness and separate external-bot controls | Recording, transcription, automated note storage, anonymous use, external-hosted meeting | Meeting policy, app availability, organizer guidance, incident procedure |
Permissions and consent
Review what the app can do after a user gains access
Teams app availability controls who can add or use an app. Microsoft Entra consent controls the Graph permissions granted to its service principal. Resource-specific consent can let a team or chat owner authorize access to that particular resource. These layers must be reviewed together, but they must not be conflated.
Match the Teams app ID to the Entra enterprise application and publisher.
Separate delegated permissions from application permissions.
Record who granted tenant-wide admin consent and when.
Inspect RSC permissions declared in the app manifest.
Review whether group or team owners may consent to RSC.
Trigger re-review when an update introduces new permissions.
Confirm user-consent policy and low-risk permission classifications.
Document consent revocation and downstream outage impact.
Custom app governance
Control submission, upload, publication, use, update, and retirement separately
A custom app can enter the tenant through user submission for approval, an admin upload to the organization catalog, or permitted user upload for personal or team testing. Each route has different authority and risk.
Submission and triage
Users can submit apps for admin approval. Route each request to a named service owner, require a business purpose and population, and prevent a support ticket from becoming implicit security approval.
Development and testing
Use a separate development tenant when possible. Validate the manifest, app ID, domains, endpoints, secrets, permissions, RSC, bot behavior, and failure mode before production publication.
Production publication
Retain the approved package and version, hash, publisher, release note, consent decision, assignment, validation evidence, support contacts, and rollback package.
User upload rights
Scope upload rights through app setup policy, then reconcile the team-level setting that determines whether members may upload into a particular team. Test personal and team contexts separately.
Updates and reconsent
Compare every manifest and permission change. New Graph permissions can require new admin consent; new domains, data flows, meeting capabilities, or RSC should reopen the risk decision.
Decommissioning
Remove availability, uninstall where required, revoke consent, disable or delete the service principal only after dependency analysis, retire credentials/endpoints, preserve evidence, and confirm vendor-side data deletion.
External and meeting behavior
Test the contexts in which app policy is easiest to misunderstand
| Participant or context | What to test | Why it matters | Related control |
|---|---|---|---|
| Guest | Whether the app is blocked org-wide, added by an internal user, available through setup policy, or exposed in personal/team context | Guests can't browse and add from the host store, but can use apps added by host users in supported contexts | Host org app settings, guest access, setup policy |
| External-access user | Group chat and meeting chat with a host-added app; bot, tab, and message-extension interaction | External users can't add host apps, but can interact with apps added to a host conversation | Host policy, external access policy, app data practices |
| Anonymous attendee | Interaction with an existing meeting app or Adaptive Card and the anonymous-app meeting setting | Anonymous participants can't add apps but may interact with existing apps when allowed | Meeting settings and the global default app control |
| External meeting bot | Detection, lobby placement, organizer approval, recording/transcription notice, storage destination, and incident action | External bots are participants and require a separate meeting-policy control; app allow/block alone is not sufficient | External bot access mode, lobby roles, organizer guidance |
Cross-control dependency: use the Teams external federation review for external chat boundaries and the recording and transcription governance guide for meeting artifacts. App access does not replace either control.
Top app-governance risks
Common failures that survive a screenshot-only review
An app can appear blocked, allowed, pinned, or consented in one interface while the user's real access is determined elsewhere. Treat the following as control defects requiring reconciliation and evidence.
Wrong control model
The review documents legacy permission policies after app-centric migration, or assumes migration occurred without checking the tenant.
Admin-center mismatch
Teams and Microsoft 365 availability differ before unified management, and one control plane silently defeats the intended result.
Availability mistaken for consent
The app is scoped correctly, but broad Graph or application consent remains from an earlier approval.
Group assignment drift
A dynamic rule, nested group, distribution list, or auto-created migration group expands access beyond the approved population.
Update changes permissions
A publisher adds new permissions, domains, agents, or data flows without reopening security, privacy, or support review.
Custom upload bypass
App setup policy or team-level upload settings let a development package enter production collaboration contexts without catalog approval.
External context ignored
The app is tested only with internal users; guest, external, anonymous, or external-bot behavior exposes data or breaks meetings.
No disable sequence
The incident plan says “block the app” but omits assignment removal, uninstall, consent revocation, service-principal action, token/session impact, and vendor data.
No usage owner
An unused app retains consent and availability because the sponsor left, renewal dates were not tracked, or telemetry was never reviewed.
Change, validation, and rollback
Make every app-access decision testable and reversible
Pre-change evidence
- Catalog export and tenant control-model proof
- Org-wide defaults and individual app availability
- User/group or legacy policy assignments
- App details, version, permissions, consent, and RSC
- Setup policy, installation/pinning, upload settings
- Representative user and external-context test plan
Validation populations
- Allowed pilot user and denied control user
- New user and removed user
- Direct assignment and group-derived assignment
- Guest, external, and anonymous participant where applicable
- Web, desktop, and mobile clients
- Personal, chat, channel, and meeting contexts
Rollback layers
- Restore prior availability or legacy policy assignment
- Remove setup-policy installation or pinning
- Disable custom upload and remove the package
- Revoke newly granted permission consent when safe
- Disable the service principal only after dependency review
- Notify users, owners, help desk, security, and vendor
Closeout evidence
- Change and approval identifiers
- Before/after exports and screenshots
- Effective-access test results and timestamps
- Audit events and known propagation delay
- Exceptions with owner and expiry
- Updated app register, support notes, and next review date
Practical rule: because app availability changes can take time to reach every client, do not repeatedly broaden the policy during propagation. Validate the admin-center state, allow the documented window, use controlled test identities, and collect evidence before making another change.
Operational measures
Track control health, not only the number of installed apps
Inventory coverage
Percentage of available apps with an owner, purpose, data classification, risk tier, approved population, permissions record, support path, and next review date.
Assignment accuracy
Count of apps whose documented scope matches effective access for representative users, including direct, group-derived, and exception assignments.
Consent exposure
Apps with high-impact application permissions, tenant-wide consent, owner-granted RSC, stale service principals, or permissions changed since approval.
Request performance
Median age of user app requests, percentage with complete risk packets, approval/denial reasons, and repeated requests for the same business capability.
Lifecycle hygiene
Unused apps, expired exceptions, orphaned custom apps, outdated versions, dormant owners, unresolved vendor notices, and decommission actions overdue.
Response readiness
Critical apps with tested disable, unassign, uninstall, consent-revoke, investigation, communication, and vendor-data containment steps.
Continue the ecosystem review
Connect app access to the controls that determine real business risk
Govern support access and admin consentSeparate vendor support, OAuth consent, delegated administration, and approval evidence.
Secure Entra app registrationsReview ownership, secrets, certificates, redirect URIs, permissions, and enterprise applications.
Review Teams channel governanceUnderstand where apps, tabs, bots, files, owners, guests, and channel-specific sites intersect.
Align Teams lifecycle and archivingRemove or revalidate apps when teams, owners, projects, and business purposes change.
Use ongoing Microsoft 365 managementOperationalize app inventory, requests, user support, change control, monitoring, and monthly review.
Meet Ali Hassani, CISO25+ years of IT, cybersecurity, compliance, Microsoft infrastructure, and operational experience.
Microsoft references
Authoritative Teams app access, consent, deployment, and audit resources
- Use app-centric management for Teams app access
- Manage apps and org-wide app settings
- Understand unified agent and app management
- Review legacy app permission policies
- Grant and manage consent to Teams app permissions
- Manage custom app policies and settings
- Manage app setup policies
- Manage user requests for apps
- Search Teams app management audit events
- Understand apps for guests and external attendees
- Manage external meeting bots
- Configure the Entra admin consent workflow
Frequently asked questions
Teams app permission policy review FAQ
Do Teams app permission policies still control every tenant?
No. Microsoft is migrating tenants to app-centric management, which replaces permission policies with per-app availability for Everyone, Specific users or groups, or No one. If the Teams admin center still shows usable permission policies, the tenant can continue using them until migration. Always document the tenant's actual state.
Does allowing an app grant its Microsoft Graph permissions?
No. App availability and permission consent are separate. A user may be allowed to access an app while required Graph consent is missing; an app may also retain broad Entra consent even when Teams availability is restricted. Review both the Teams app and its enterprise application.
Does pinning an app override an app block?
No. App setup policies control installation and pinning, but they do not override an app that is unavailable to the user or blocked by the organization. Validate availability first, then setup policy and client placement.
Can app-centric management assign access through groups?
Yes. Microsoft supports security groups, Microsoft 365 groups, dynamic user membership groups, nested groups, and distribution lists for specific app availability. Guest users cannot use an app through the Specific users or groups option even if assigned. Group ownership and membership logic therefore belong in the review.
Can guests or external users interact with Teams apps?
In supported contexts, yes. Guests and external users cannot add apps from the host organization's store in the same way as native users, but they may interact with apps added by host users in chats, channels, or meetings. Anonymous attendees can interact with existing meeting apps when the relevant meeting setting allows it.
What evidence should a Teams app review produce?
At minimum: tenant control model, catalog export, app and publisher IDs, owner and purpose, availability, user/group or policy assignment, setup policy, permissions and consent, RSC, external-context tests, audit events, risk approval, support owner, review date, and a tested disable and rollback sequence.
Make application access deliberate
Reconcile Teams app availability, consent, deployment, and evidence
IT Perfection can inventory Teams apps and agents, identify the tenant's active access model, reconcile Teams and Microsoft 365 controls, review permissions and custom apps, test representative users and meeting contexts, and establish a practical approval, monitoring, incident, and rollback runbook for Orange County and Southern California organizations.
This guide is for initial guidance only and does not replace a professional cybersecurity audit, compliance assessment, penetration test, legal/privacy review, software-vendor due diligence, or tenant-specific change-control process. Created by Ali Hassani, CISO — 25+ years of IT, cybersecurity, compliance, and infrastructure experience.
