How to See Which Apps Have Access to Your Microsoft 365

You can see every app with access to your Microsoft 365 tenant from the Microsoft Entra admin center, under Identity → Applications → Enterprise applications → All applications. Selecting an app and opening its Permissions tab shows exactly what Microsoft Graph data it can reach, split into permissions your organization's admins approved and permissions individual users approved for themselves.

This guide covers that path in full, the admin-consent-versus-user-consent distinction that trips people up, and what a one-app-at-a-time review can't tell you.

Where do I find the list of apps with access in Entra?

1. Sign in to entra.microsoft.com with an account holding at least the Cloud Application Administrator or Application Administrator role.
2. Go to Identity → Applications → Enterprise applications → All applications.
3. Select the app you want to review, then open Permissions.

This lists every application that was added to your tenant through either user or admin consent — including AI assistants, meeting bots, and productivity extensions that connect through Microsoft's identity platform, alongside line-of-business apps. The list covers both first-party Microsoft apps and third-party registrations, so it is worth scrolling past the familiar names to see what else has quietly accumulated permissions over time.

What's the difference between admin consent and user consent?

The Permissions tab splits into two:

• Admin consent — permissions granted for the entire organization by an administrator. These apply to every user the grant covers, not just the person who happened to click through.
• User consent — permissions an individual approved for themselves, one person at a time, without an admin's involvement (when your tenant's consent settings allow it).

Selecting any listed permission opens a Permission Details pane describing exactly what it allows.

How do I revoke an app's access?

For an admin consent grant: open the permission in the list, select the … control next to it, and choose Revoke permission — this works directly in the portal.

For a user consent grant, the portal has no revoke button. Taking it back requires a Microsoft Graph API call (DELETE /oAuth2PermissionGrants/{id} for delegated permissions, or the equivalent appRoleAssignments call for application permissions) or the matching PowerShell cmdlet, run by someone with the Cloud Application Administrator role. Revoking a grant also doesn't stop the same user from consenting again the next time the app asks — stopping that requires changing the tenant's consent policy separately, under Enterprise apps → Consent and permissions → User consent settings.

What happens when a user hits a permission they can't grant themselves?

If a tenant restricts user consent, a person who tries to sign in to an app requesting a permission above that limit hits a wall rather than a grant. A Global Administrator can turn on the admin consent workflow at Enterprise apps → Consent and permissions → Admin consent settings, which lets that person send a request instead: it goes by email to whichever users, groups, or roles are set as reviewers, who can approve, block, or deny it from their My Pending tab. Only a Global Administrator can approve a request for Microsoft Graph application permissions — being named a reviewer doesn't hand over that privilege on its own. Each request also expires after a configurable number of days, so an unreviewed request doesn't sit open indefinitely.

What if my organization spans multiple Microsoft 365 tenants or a partner directory?

A review inside one tenant only shows that tenant. If your organization works across more than one Microsoft 365 directory — a parent company and an acquired subsidiary, for instance, or a partner's own tenant — each one needs this same walkthrough separately, signed in with the right role in each. Fixed-tenant tooling built for a single organization breaks the moment a second directory is added to the picture, so any tool meant to cover more than one tenant needs to support consenting from any organization's own directory, not just the one it was originally set up against.

What can't a one-app-at-a-time review tell you, and how does 8200.dev answer that?

Going through Enterprise applications one app at a time tells you what each app is *allowed* to reach. It doesn't rank the apps by how much risk they actually represent, doesn't flag which grants have gone stale, and doesn't hold still while you work through the list — a new consent can land while you're still reviewing the last one. 8200.dev's Microsoft 365 connector reads Sites, Files, Directory, Application registrations, Users, tenant security policies, MFA registration reports, audit logs, role assignments, and delegated permission grants — all through read-only Graph scopes — and turns them into one continuously updated, risk-scored inventory instead of a list you re-open by hand. The same read-only access also runs a tenant-wide configuration audit alongside the app inventory: Security Defaults and Conditional Access policy state, app-consent policy, and external-collaboration settings, so an over-permissive app and a loosened tenant policy that let it in show up together instead of in two unrelated reviews. It connects the same way to any organization's own Microsoft work or school directory, so a group spanning more than one tenant doesn't need a separate setup for each one. Every scope here is read-only: nothing changes a permission or a policy unless the organization separately opts in to automate a specific action.

See the full connector list for how this fits alongside Google Workspace, Slack, and GitHub.