Microsoft 365 app governance
Hundreds of apps can read your tenant. 30-50 of them have no users left.
Every OAuth consent an employee clicked, every add-in and vendor integration is a standing credential into your data - with no expiry and no review. In a typical tenant we find hundreds of them, dozens with tenant-wide read on files or mail, and 30-50 that nobody has used in a year. 1Security lists every one, shows how it reaches data and who let it in, and stages the revocations behind a review window.
- 6access channels an app can use to reach data - tenant-wide, admin-consent delegated, user consent, license-driven, explicit grant, none
- 5app types in one list - enterprise apps, app registrations, add-ins, AI agents, managed identities
- 30-50consented apps with zero active users in a typical tenant, still holding every permission
The problem
Apps get in through a consent screen. Nobody ever lets them out.
The integration that reads every mailbox in the company was never on a purchase order.
An OAuth consent screen is a purchasing decision made by whoever is looking at it, in about two seconds, to unblock a task. What it creates is a standing credential that keeps working after the project ends, the vendor is replaced and the employee who clicked has left. There is no renewal, no review and no expiry.
The dangerous attribute is not the app name but how it reaches data. A tenant-wide application permission such as Files.Read.All or Mail.Read reads for everyone, with no user signed in. A user-consent grant reads for one person - which is also the exact shape of an OAuth phishing attack. In a plain application list those two look the same. In consequence they are nothing alike - which is why 1Security classifies the channel on every row.
Reviews that look only at third-party integrations also skip Microsoft first-party services such as Forms, Lists or Approvals, which hold real permissions as well. 1Security lists both, classifies the channel for every app, counts what each can actually touch, and records which admin let it in.
What you get
Every app, with what it can actually reach
Open Apps and sort by files or users in reach instead of guessing risk from a logo.
Access channel, on the row
Tenant-wide, admin-consent delegated, user consent, license-driven, explicit grant or none. The column that turns an app list into a risk list, and the first filter in every review.
Reach in files, users and mail
How many files and users each app can access, external users broken out, plus its permission level to files, user data and email. An app with Mail.Read and 40,000 files behind it stops looking like a calendar widget.
Sensitive data inside the reach
Sensitivity labels and sensitive-info counts per app - card numbers, IDs, health data - so "this app can read files" becomes "this app can read 3,100 files with personal data".
Who consented, and when
The first admin who approved the app and the connection date, kept on the row. Two years later, when that admin has left and the app still reads mail, this is the only record.
Publisher verification
Verified or not, read next to the granted permission family. Unverified plus user consent plus mail permissions is a filter you run on a schedule, not after an incident.
Idle apps
Orphaned indicators: no users, no activity for a month or a year. Typically 30-50 apps in a mid-size tenant, all keeping their permissions. Select them and stage the revocation behind the review window.
How deep it goes
Three filters that find the apps worth revoking
Filters cover app type, access channel, Graph permission family (files, sites, mail, chat, directory, audit logs), publisher verification, sensitive reach, orphaned indicators and security alerts.
The OAuth phishing triage: user consent + unverified publisher + file or mail permissions. This is the exact pattern attackers use to turn one careless click into persistent mailbox access. In most tenants the list is under 20 rows, changes slowly, and takes ten minutes a month to review.
Overpowered and idle: tenant-wide channel + no activity in the last year. Maximum privilege, zero use, and no owner to object - the best place to start a consent cleanup. It is common to find 10-30 such apps on the first day.
The pre-approval lookup: before granting a pending consent request, search the app here. If it is already present, you see its current reach and any security alerts against it - so the approval is made on numbers, not on a vendor name.
In practice
A consent cleanup that actually finishes
Cleanups stall when every app looks equally risky. Ranking is what gets one done.
- 01
Count what is there
Open Apps. The full list lands, typically hundreds of rows, including add-ins, managed identities, Microsoft first-party services and the AI tools employees connected themselves.
- 02
Split by channel
Filter to tenant-wide: those are decisions an admin made. Then user consent: those are decisions nobody made. They get two different reviews.
- 03
Sort by reach
Sort by files in reach, then by sensitive info. The top ten rows usually hold most of the tenant exposure - and that is a very short queue.
- 04
Revoke the idle ones first
Filter to no activity in a year, select all, stage the revocation. Proposals wait 72 hours by default, owners can confirm, and every executed action lands in Actions.
What 1Security adds
From a list of applications to a list of consequences
An application list names the apps. 1Security adds what they reach, who let them in and whether anyone still uses them.
- How each app reaches data, classified into six access channels
- The number of files and users an app can touch, with external users separated
- Sensitive information and labels inside the reach of each app
- Which admin consented and when - kept after that admin leaves
- Publisher verification read next to the granted permission family
- Apps with no activity for a month or a year that still hold full permissions
- Microsoft first-party service principals included alongside third-party integrations
- Security alerts attached to an application, and revocation staged behind a review window
Scale
Hundreds of apps is normal. Reviewing them is not.
The count is never the surprise. The surprise is how many hold tenant-wide permissions granted years ago for a reason nobody can reconstruct - and how few of them anyone still uses. The inventory refreshes about every ten minutes, so an app consented this morning is on the list this afternoon.
- 100sof connected apps in a typical mid-size tenant
- 10 minuntil a newly consented app appears in the inventory
- 0write permissions needed to build the whole picture - the base connection is read-only
Related
Where this fits
Apps are one kind of non-human identity. AI agents are another - and in tenants building with Copilot Studio they already outnumber the classic integrations. Both inherit reach from the same file permissions underneath.
AI agent inventory
Copilot, Entra and Foundry agents in one list, with the sites and files each one can actually read.
See agents →Tenant inventory
Every site, OneDrive, user, guest, group, app, agent, device and license in one live inventory - apps included.
See inventory →File permissions
What "this app can read files" means as a concrete list of documents, with who else can open them.
See files →
FAQ
Questions teams ask first
Does this cover apps users consented to themselves?
That is the main point. User consent is one of the six access channels and it is the shadow-IT channel, so one filter isolates it and it can be reviewed as its own population - typically dozens of apps nobody in IT approved.
Are Microsoft first-party apps included?
Yes. Filtering only for third-party integrations hides built-in services such as Forms, Lists and Approvals that hold real permissions, so the inventory covers both and lets you filter afterwards.
What does "tenant-wide" actually mean?
Application permissions granted by an administrator, where the app reads data for everyone with no user signed in - Files.Read.All, Mail.Read and the like. It is the highest-stakes channel because nothing about a single user session limits it.
Can I revoke an app from here, and is that safe?
Yes, once the write module is enabled. Revocations are staged as proposals behind a review window - 72 hours by default - and logged in Actions with who approved them. Until then the base connection is read-only and every candidate list still shows its live count.
Do we need E5 or Defender for Cloud Apps?
No. The inventory, access channels, reach counts and orphaned indicators run on standard Microsoft 365 licensing over the read-only connection, with no agent to install.
List the apps nobody registered.
Connect read-only and the app inventory builds itself the same day - including the hundreds that arrived through a consent screen and the 30-50 nobody uses anymore.
Or keep trusting the consent screen.