Case file · anonymized · OAuth · tenant hygiene · M365

Five OAuth grants nobody remembers.

A read-only sweep of a small home-care agency's Microsoft 365 tenant surfaced five third-party OAuth grants nobody at the business could name. One held 135 permissions across mail, files, users, groups, and Defender itself.

2026-07-14 · 5 min read · worked by the principal

The client is a Pennsylvania home-care agency. Owner-operated. Fewer than 50 users. Basic Microsoft 365 licensing. The kind of business that runs on scheduling software, a payroll service, and a Wednesday-night email newsletter.

The owner didn't ask for a pen test. He didn't ask for anything at all. He agreed to a fifteen-minute conversation while we ran a read-only sweep of what his Microsoft 365 tenant was already agreeing to.

Nothing was scanned. No endpoint was touched. No mailbox was accessed. Everything below came from Microsoft Graph's own record of what the tenant has already consented to, over years.

What was there

Five third-party OAuth grants across four different applications. All persistent. All still active. Every one of them held at least one privileged scope over user mail, files, calendars, or the directory itself.

Grant one — tenant-wide, 135 permissions

The first finding was the loudest. Somebody with global-admin rights, at some point in the tenant's history, had approved an unnamed application for all users at once. The grant covered:

• Directory.ReadWrite.All — modify every user account and group
• Files.ReadWrite.All — read and modify every file in OneDrive and SharePoint
• Mail.Send — send mail as any user without their knowledge or interaction
• Policy.ReadWrite.CrossTenantAccess — alter cross-tenant access policies
• SecurityIncident.ReadWrite.All — read and modify the Defender security incidents that would otherwise catch it
• Sites.FullControl.All — full administrative control of SharePoint
• DeviceManagementManagedDevices.PrivilegedOperations.All
• …110 more.

The owner didn't recognize the application. His current IT vendor didn't recognize the application. The user identifier that had approved it belonged to somebody who no longer worked at the business.

Legitimate tools can also hold god-mode. The question isn't whether the grant is malicious — the question is whether anyone at the business today knows why it's still there.

Grant two — a single user, forgotten

The second grant was scoped narrower — only one user's mailbox, calendar, and contacts. But it carried the full Mail.ReadWrite + Mail.Send pair with a persistent refresh token. Whatever it was, whoever added it, it could read the mailbox, change the mailbox, and send from the mailbox indefinitely.

The user is still on the payroll. When we asked what apps they'd connected to their work email, the answer was a shrug.

Grant three — a real consumer email client

The third grant was for a well-known consumer email app that lets users read their work mail from a personal phone. Real product. Not malware. Widely used. Not appropriate for a business that handles protected personal health information.

If the phone gets lost, stolen, resold, or if the personal account behind the app gets breached, an attacker reads business email. The owner had no policy about work mail on personal devices. Nobody had told him he needed one.

Grant four — a real scheduling tool

The fourth grant was a calendar-scheduling service that every small business owner has heard of. The scope was legitimate for its function. The finding wasn't "revoke this" — the finding was "confirm which user granted it, whether they still use it, and whether it's on your approved-vendor list." The owner didn't have an approved-vendor list.

Grant five — us

The fifth grant was our own read-only monitoring identity. Included in the report intentionally, disclosed explicitly, one click to remove. Transparency is the point. If the client walks away after the fifteen-minute conversation, our access ends with them.

What happens next

Nothing was scary. Nothing was compromised. Nothing on this list required an incident-response team.

What the finding did require was somebody who bothered to look. That's the entire eye-opener. The consent ledger has been sitting in every Microsoft 365 tenant since day one, factual and readable via the standard Graph API, and almost nobody in the small-business space has ever seen theirs.

The owner spent fifteen minutes reading a five-page report. He identified two of the four unknowns as tools that former employees had used and forgotten. He revoked those two grants himself, from the admin console, in about ten minutes. The other two we're still tracking down.

He then asked, for the first time in his business's history, how do we make sure this doesn't build back up over the next three years.

That is the entire product Envyously sells. Not a scanner. Not a scare tactic. A picture, once a month, of what your Microsoft tenant has consented to and whether anyone at the business remembers why.

How to do this yourself, at zero cost

If you're an owner-operator of a small Microsoft 365 tenant reading this and wondering what's on yours right now:

1. Sign into entra.microsoft.com
2. Go to Applications → Enterprise applications
3. Look at the app list. Anything you don't recognize, click on it → Permissions → note what it can do
4. Anything unfamiliar and holding scopes over Mail, Files, Directory, or Sites — click Remove permissions. The next time a real user needs the app, they'll be prompted to consent again. Nothing breaks.

Do it once a quarter. It's the equivalent of walking your building at night and checking the doors. Nothing exotic. Nobody who does this ever regrets it.

Seeing this pattern in your tenant? The person who worked this case answers the email. Originally published on the Envyously blog.