Right now, in your tenant, there’s an application reading mail that nobody remembers integrating. You can’t name it. You can’t remember who consented to it. And here’s the part that should actually worry you: it doesn’t need anyone to log in to keep working. Mine is the Alexa app, that I gave consent to when that functionality was first released about 5 years ago. Just ask Nic, he’ll tell you.
That’s how Nicolas Blank and I opened our latest webinar, and I want to walk you through why that single sentence is truer than most admins are comfortable admitting. This isn’t a hypothetical. It’s the state of most Entra ID tenants I’ve looked at, and it’s almost certainly the state of yours.
If you'd like to watch the on-demand webinar or clips, you can do so here: On-Demand Webinar - The Hidden Risks of App Permissions in Entra ID.
Every integration, every script, every SaaS connector you’ve ever approved is an identity, and that identity holds permissions. Most of them outlive the person who created them. It's an invisible population living in your tenant, and nobody’s watching what they can touch.
The industry estimate, and I’d encourage you to verify this against your own tenant rather than take it as gospel, is 45 non-human identities for every human in a typical enterprise cloud estate. Sit with that ratio for a second. For every person in your org with a badge and a manager, there are 45 apps, scripts, and service principals quietly holding access.
None of them got in by breaking a rule, either. That’s what makes this so hard to see:
Every one of those is normal, sanctioned behavior. That’s the trap. Sprawl doesn’t happen because someone made a mistake. It happens because a hundred small, reasonable decisions never got revisited.
So, here’s a question worth asking yourself honestly: how many app registrations are in your tenant right now? Under 100? A few hundred? A few thousand? If your honest answer is “I don’t really know,” you’re not alone. That’s the answer most admins give, and it’s the whole problem in one sentence.
Here’s where I want you to slow down, because this is the part of the webinar we spent the most time on, and for good reason. Two apps can hold the exact same permission name. In the Entra ID portal, they can look almost identical. And yet the blast radius between them can be the difference between “one user’s inbox” and “every mailbox in the company.”
The difference is whether the permission is delegated or application.
Delegated permissions require a user to be present. The app acts on behalf of whoever’s signed in, and it can never do more than that person could do alone. Mail.Read as a delegated permission reads the inbox of whoever’s logged in. That’s it. Bounded, contained, tied to a human.
Application permissions run headless, 24/7, with no user and no context. The app acts as itself, across the entire tenant, around the clock. Mail.Read as an application permission reads every mailbox in the company. No login required. No one has to be awake for it to work.
Put them side by side, and the picture gets uncomfortable fast:
|
|
Delegated |
Application |
|
Acts as |
The signed-in user |
The application itself |
|
User must be present |
Yes – interactive |
No – headless, 24/7 |
|
Consent |
User or admin |
Admin only |
|
Scope |
That user's own access |
Tenant-wide, every object |
|
If abused |
Bounded by one user |
Unlimited, unattended, invisible |
That last row is the one I want you to remember. If a delegated app gets abused, the damage potential is one user. If an application-permission app gets abused, it’s unlimited, unattended, and invisible.
A handful of application permissions, if you find them sitting on an app you can’t fully account for, deserve your immediate attention:
A single over-permissioned application, if compromised, is a full breach on its own. No password to steal. No MFA prompt to trigger. No user to phish. Just a token, working quietly in the background, doing exactly what a consented app is supposed to do.
I don’t need to reach for a hypothetical here, because we have a documented, real-world case study, and it happened to one of the most security-conscious companies on the planet.
In January 2024, Microsoft disclosed that Midnight Blizzard – the nation-state actor also known as APT29 or Nobelium, had compromised their corporate systems. The anatomy of that breach, according to Microsoft’s own Security Response Center, ran like this:
Read step two again. A legacy test OAuth app with elevated access was the pivot point. That’s not exotic tradecraft. That’s the exact sprawl I just walked you through above, sitting in one of the world’s most scrutinized environments.
This is, without question, the single most important idea in this whole post, so let me say it twice: OAuth grants live independently of user credentials. Password resets don’t revoke them. MFA doesn’t apply to them. An app you never noticed can hold access long after the account that created it is gone.
Do password resets or MFA revoke a malicious app’s permissions?
No. An OAuth app with application permissions holds its own token that lives independently of any user’s password or MFA. Resetting every password in your tenant does not revoke app-only OAuth grants. To stop the access, you have to remove the consent or delete the app itself.
I’ll ask you the same question we asked our audience live: if you reset every password in your tenant tonight, are you safe tomorrow?
No. You’re not. Resetting every password does nothing to app-only OAuth grants, and that gap is exactly why most incident-response playbooks miss this class of compromise entirely.
Nobody is safe. Even Linus Tech Tips lost their YouTube channels in 2023, and not because someone guessed a password. Malware stole a browser session token that walked straight past MFA. Different mechanism from an OAuth grant, same lesson: tokens outlive the credentials they came from.
Here’s why your existing defenses didn’t even flinch:
MFA doesn’t apply. App-only tokens have no user to challenge. There’s nothing for MFA to prompt.
EDR sees nothing. Endpoint tools watch devices. This is a cloud API call from nowhere in particular.
It looks legitimate. A consented app reading mail is exactly what a consented app is supposed to do.
Your defenses were built for users. They’re blind to apps. That’s not a criticism of your stack – it’s a genuine, structural gap, and it’s why app-layer governance has to sit alongside identity and endpoint controls, not replace them and not be replaced by them.
You can’t stop apps from existing. You shouldn’t want to; they’re how modern work gets done. What you can do is make sure not one of them holds power you didn’t grant on purpose. That comes down to four disciplines, working together as a system rather than a checklist.
Prefer delegated over application permissions wherever a user can realistically be in the loop. Scope down – Mail.Read beats Mail.ReadWrite; a single mailbox beats the whole tenant. Treat broad grants as exceptions that must be justified, not defaults handed out “just in case.” How many of your apps have Directory.ReadWrite.All “just in case”? Be honest.
Every app needs a named business owner/sponsor, not a team alias, a person accountable for why it exists. Owners re-confirm on a schedule: still needed, still correctly scoped, still ours. No owner is a finding, not a formality. Orphaned apps, where the creator left the company years ago, are where the worst sprawl hides.
Review apps the way you review users. Non-human identities deserve the same recurring scrutiny. Hunt for scope creep and unused grants – permissions requested once and never actually used. Make it recurring and automated, because a one-time cleanup decays back into sprawl within months. I’ve watched it happen.
Apps need a defined path: request and justify, provision at least privilege with an owner, and an expiry, monitor and attest on a schedule, and – the step everyone skips – decommission. Most sprawl isn’t a bad decision. It’s a missing last step. Tie an app’s retirement to its owner’s offboarding or technology offboarding, and you close the gap that Midnight Blizzard walked through.
The most proactive control most organizations overlook is simply governing consent itself. Most sprawl begins with a single user clicking “Accept” – and that’s a setting you control.
Restrict user consent to verified publishers and low-risk scopes,a or turn it off entirely. Route requests through an admin consent workflow instead of a dead end – send them to a reviewer, and keep the business moving rather than blocking it outright. And communicate the 'why': tell users what changed and how to request apps, so you get friction without surprises.
Then keep watching, continuously, for the signals of abuse: new secrets or certificates added to an old app, sudden consent to high-privilege scopes, spikes in mail-read or Graph API volume, application permissions appearing where none belonged before. Across thousands of apps, that’s not a spreadsheet you keep by hand. It has to be continuous, and it has to scale.
Where are you, honestly? I like giving people a way to self-locate, so here’s the maturity ladder we use:
0 – Blind. No inventory. You can’t name the apps or their permissions.
1 – Aware. A one-time inventory exists – already going stale.
2 – Scoped. Least privilege applied; broad grants trimmed.
3 – Governed. Owners, attestation, and recurring access reviews in place.
4 – Continuous. Monitored at scale. Abuse signals surface automatically.
Most organizations I talk to are sitting at 0 or 1. If that’s you, you’re not behind some unusual curve – you’re the norm. The goal is level 4, and getting there starts with knowing exactly where you’re standing today.
Before you fix anything, get the picture. Answer these for yourself, honestly:
How many apps hold application permissions right now?
Which ones can read or write mail or the directory?
How many have no owner – or an owner who’s left?
When was the last access review of any of them?
Can a regular user consent to an app without an admin in the loop?
If you can’t answer those today, that itself is the finding.
You don’t need a project plan to start. You need to know where you stand, and then take five moves that cost nothing but attention:
Pull an inventory of apps with application permissions.
Flag Mail.*, Directory.*, and full-access grants.
Find orphaned apps and assign owners.
Review your user consent setting today.
Run the AppGov Score to baseline everything.
Three things, and I want them to actually stick:
Application permissions are tenant-wide, unattended, and invisible.
App grants outlive passwords, MFA, and the people who made them.
You can’t govern what you can’t see. Start by getting the picture.
The risk was always there. Now you can see it, and you know the first move.
Run a free assessment with AppGov Score and get the answers to all five questions in one pass – exactly which rung of the ladder your tenant is actually on. No rip-and-replace. Just answers. Run it this week.