A staff member finds a promising new tool. Maybe it is an AI assistant that summarizes meetings, a scheduling app, or an analytics dashboard. They sign in with their work account, a Microsoft window appears asking them to grant the app some permissions, and they click Allow. The tool works. Everyone moves on. This is how Microsoft app permissions innocently but insidiously open up security gaps across small businesses.
That single click is one of the most consequential security decisions made in most small businesses, and almost no one realizes it is happening. Depending on what was requested, that Allow button may have just handed an outside company standing access to your email, your files, your calendar, or in the worst cases, the data of every person in your organization.
This is not a reason to fear new software. The right tools make your team faster, and the productivity promise is usually real. But the permission screen is designed to be clicked through quickly, the wording is vague, and the difference between a harmless request and a dangerous one is invisible to the person making the call. After 22 years of running IT and Microsoft 365 security for Toronto businesses, this is one of the gaps we watch most closely, because the damage from getting it wrong is quiet and hard to undo.
What You Are Actually Approving
When an app asks to connect to your Microsoft 365, it is asking for permissions. There are two kinds, and the difference is the whole story.
Delegated permissions let the app act on behalf of the signed-in person, limited to what that person can already do. If you connect a tool this way, it sees your inbox, not your colleague’s. It reaches the files you already have access to, nothing more. When you leave the company and your account is disabled, the app’s access goes with it.
Application permissions are different. They grant the app its own standing access across the entire organization, regardless of who is using it or whether anyone is signed in at all. To put that in plain terms: an app granted application access to read mail can read every mailbox in the company, not just the mailbox of the person who installed it. The same logic applies to files and calendars.
The other detail worth knowing is scope. A request to read your own profile is about as low-risk as it gets. A request that includes the word “all,” such as access to read all files or all mail, is asking to reach everything, for everyone. Most apps do not need anything close to that to do their job. A meeting-notes tool needs to see your calendar and the meeting you point it at. It does not need company-wide mailbox access. When an app asks for far more than its function requires, that is the signal to stop and ask why.
A Scenario That Starts With Good Intentions
The following is a fictional scenario, but the pattern is real.
Scenario: An employee at a mid-sized firm adopts an AI tool that promises to organize the team’s documents. During setup, the app requests application-level access to read and write all files across the organization. The employee, focused on getting the tool working, clicks Allow. The request succeeds because the company never restricted who could approve app connections.
Result: Months later, the vendor behind the tool suffers a breach. Because the app held standing organization-wide access to files, the firm’s documents were reachable through that connection. The firm spends weeks determining what was exposed and explaining the incident to a client who asks how an outside app ever had that level of access.
The gap: No one reviewed the permission request, and any employee was allowed to approve it. The app was granted far more access than it needed, and that access did not depend on any single user staying with the company.
Prevention: Approval routed to IT instead of left to the individual, an app registered with the minimum permissions it actually needs, and delegated access used in place of organization-wide access. The tool still works. The blast radius is small.
Attackers know this pattern well, which is why consent phishing exists. Instead of stealing a password, the attacker sends a legitimate-looking request to connect an app, and the victim grants access themselves. Microsoft’s own guidance is direct about the risk and recommends restricting which apps users can approve on their own (Microsoft, “Protect against consent phishing“).
Microsoft Has Changed the Default in 2026
For years, the default setting in many Microsoft 365 environments let ordinary users approve app connections themselves, including requests for sensitive access. That has changed. In 2025-2026, Microsoft moved its recommended app consent policy so that approving third-party apps requesting access to company files and sites requires an administrator, not the individual user (Microsoft, “Configure how users consent to applications“). Existing tenants are being migrated to this stricter default, and Microsoft notified administrators of the change through the Microsoft 365 message center.
This is a good change, and it reflects how we have always set up client environments. But it only helps if someone is on the other side of the approval, reviewing requests and deciding what is reasonable. A blocked request with no one to evaluate it becomes a productivity problem, where staff cannot use the tools they need and start looking for workarounds. The change closes a dangerous default. It does not, by itself, give you a process.
How We Handle App Access
Managing what connects to your Microsoft 365 is part of the baseline we run for every client, not a separate service. A few principles guide it.
We do not hand over administrative control of your identity system. The ability to approve apps and create connections is powerful. Small mistakes here can become organization-wide incidents. We hold that control and act on your behalf, which keeps the potential for accidents contained.
When a tool genuinely needs to connect, we register it with the least access required to do its job. We prefer delegated permissions, so the app is limited to what the individual user can already reach, and we avoid organization-wide access unless there is a specific, justified reason for it. Where an app needs to tell the difference between, say, an administrator and a regular user, there are ways to handle that without granting the app permission to read your wider directory.
We also keep a current, approved applications list for each client and route new requests through a defined approval step. That way, the answer to “can I connect this tool” is not a guess made by whoever happens to be clicking, and it is not an automatic no that pushes people toward shadow workarounds. It is a quick, informed decision made by people who can see the whole picture. This is the practical difference between a trusted IT partner that knows your environment and a call centre.
The Honest Takeaway
You do not need to become an expert in Microsoft permissions, and your team should not have to interpret a vague approval screen under time pressure. What you need is a simple rule and someone accountable for it: new app connections get reviewed before they are approved, and apps get the least access required, not the most they ask for.
If you are not sure who can approve app connections in your environment today, or what already has access to your data, that is worth finding out, especially now that Microsoft’s stricter defaults are in effect. We can review what is connected to your Microsoft 365, tighten who is allowed to approve new apps, and put a sensible approval process in place so the right tools stay easy to adopt and the risky ones get caught. It is part of how we run IT for every client, and the first conversation is free.
Reach out to us today. Let’s schedule a free discovery call to discuss your small business IT management needs together.
FREQUENTLY ASKED QUESTIONS
What is the difference between delegated and application permissions in Microsoft 365?
Delegated permissions let an app act on behalf of the signed-in user and limit it to what that user can already access. Application permissions give the app its own standing access across the entire organization, independent of any user. Application permissions are far more powerful and should be granted only when a specific business need requires them, because an app with broad application access can reach everyone’s data.
Why should app approvals go through IT instead of individual employees?
A single approval can grant an outside app access to sensitive company data, sometimes across the whole organization. Routing approvals through IT means each request is reviewed against what the app actually needs and what the business is comfortable exposing, which prevents both accidental over-permissioning and consent phishing attacks where users are tricked into approving a malicious app.
Is Microsoft changing how app permissions work in 2026?
Yes. Microsoft has moved its recommended default so that approving third-party apps requesting access to company files and sites requires an administrator rather than the individual user, and existing tenants are being migrated to this stricter setting. The change reduces risk, but it works best when paired with a clear process for reviewing and approving legitimate app requests.
