Every small business has spent years being told to turn on multi-factor authentication, and that advice is correct. It protects one specific thing: a person logging in. It does nothing about the other door into your Microsoft 365, which is the set of applications you have granted standing access to, usually years ago, often at somebody's request, and almost never reviewed since. This is how to find that list and understand what it says.
Why app access is a separate problem
When you click Accept on a consent screen, you grant an application permission to act against your tenant. From then on it authenticates with its own credential, not a person's, so there is no password prompt and no multi-factor challenge in its path. If that credential is stolen, the attacker inherits whatever you granted. That is exactly how a backup product signed in to 173 tenants in October without triggering anyone's MFA.
The arithmetic is awkward: the more useful an integration is, the broader the access it asks for, and the more valuable its credential becomes to someone else.
Delegated versus application permissions
This is the single most useful distinction to learn, because it decides how much the grant matters.
Delegated permissions let an app act as the signed-in user, limited to what that user can already do. If the user cannot see the finance folder, neither can the app. Access ends when their account is disabled.
Application permissions let an app act as itself, across the whole tenant, with no user involved. An app with application-level mail access can read every mailbox, including yours, whether or not anyone is signed in. These are the grants worth auditing carefully, because disabling an employee's account does not touch them.
Permission names tell you the scope. Mail.Read delegated means this user's mail. Mail.Read as an application permission means all mail in the organization. Anything ending in .All deserves a second look, and Directory.ReadWrite.All means the app can modify your directory, including creating accounts and changing permissions.
Where the list lives
In the Microsoft Entra admin centre, under Enterprise applications, set the filter to show all applications rather than only the ones Microsoft published. For each app, Permissions shows what was granted, who consented and when. Users and groups shows who is actually assigned. In Google Workspace the equivalent lives under Security, then API controls, then App access control.
Expect the list to be longer than you remember. A typical small business finds somewhere between fifteen and sixty entries: the backup tool, the e-signature service, the CRM connector, a scheduling app, three AI meeting note-takers somebody trialled, a PDF tool, and several things nobody can identify.
How to read it without a security background
Go through the list once with four questions per app.
- Do we still use this? The fastest wins are apps nobody has opened in a year. Remove them.
- Who approved it, and when? The consent record names a person and a date. An app consented by someone who left is a specific kind of finding.
- Is it delegated or application-level? Application-level grants are your priority list, especially anything with
.All. - Would we grant this today? Trialled tools get consented and never removed. The trial ended; the access did not.
Check the credentials, not just the permissions
Each application registration can hold client secrets and certificates, and adding one is how an attacker establishes a way back in that survives everything else you do. In the app's Certificates and secrets section, look at what exists and when it was created. A secret added recently that you cannot account for is the finding, not a curiosity. Note the dates of the ones you expect, so next time you have something to compare against.
Read the sign-in logs for applications
Most people who look at sign-in logs filter for users. Entra records service principal sign-ins separately, which is where application activity appears: which app, from where, how often. This is the category almost nobody looks at and it is where unusual app behaviour shows up. You do not need to watch it continuously. Glancing at it quarterly, and after any vendor announces an incident, is enough.
Turn off the open door
By default, ordinary users in many tenants can consent to applications accessing their own data. That means an employee can grant a tool access to their mailbox without asking anyone. The better configuration for a small business is to restrict user consent and route requests through an admin consent workflow, so a new app becomes a thirty-second decision rather than a discovery six months later. It is one setting, under Enterprise applications, then Consent and permissions.
Make it a quarterly twenty minutes
Open the list, remove what is unused, look at anything application-level, scan for new secrets, glance at service principal sign-ins. Write the date on the file. The value is not in any single review, it is in having a baseline, because the second time you look you can see what changed. Treat it as part of your SaaS inventory, since it is the same question asked from the tenant's side.
What this means for your business
If a vendor announces tomorrow that one of their application credentials was stolen, there are two possible positions to be in. Either you can answer within ten minutes whether that app was in your tenant and what it could reach, or you spend a week finding out while deciding whether to rotate everything. The difference is one list, reviewed four times a year, and it is work we set up with clients once so the quarterly pass takes twenty minutes.