A calendar tool, CRM connector, or Teams add-in can keep access to company data long after the person who approved it has forgotten the consent screen. The access may include one user's calendar. It may also cover every mailbox, directory entry, file, or chat in a Microsoft 365 tenant.
New research gives administrators a reason to examine those grants. On August 3, 2026, four researchers published what they describe as the first systematic, security-focused measurement of permissions across the Microsoft 365 third-party application ecosystem. Their Microsoft 365 app study found inconsistent permission disclosure and identified apps whose requested access differed sharply from other tools with similar stated functions.
The practical consequence is narrow and useful. A listing in a Microsoft marketplace does not answer whether an app has the least access it needs. Canadian firms should treat each connected app as an identity with continuing access to business data, assign an owner, and review its permissions on a schedule.
The study found limited permission transparency
The researchers collected more than 8,000 applications from the Microsoft Teams catalogue, SharePoint store, Microsoft Marketplace, an automated test tenant, and an operational university tenant. Only 1,069 applications exposed both a usable description and a permission set, the two pieces needed to compare what an app says it does with what it can access.
That gap is one of the study's strongest findings. Microsoft 365 apps arrive through several channels, and those channels do not present permissions consistently. The researchers found that some stores disclosed detailed access, some disclosed only part of it, and some revealed permissions only after installation. In their September 2025 marketplace crawl, the team identified 8,232 add-ins, then successfully deployed 432 through its automated process. The final dataset combined those results with other sources.
An administrator cannot assume that a familiar install flow provides a complete risk assessment. The same app may appear in more than one catalogue, while its effective access is represented inside the tenant by a service principal. That object and its granted permissions are the records that matter after installation.
Application permissions can reach the whole tenant
Microsoft 365 integrations commonly use OAuth. Delegated permissions let an app act for a signed-in user within that person's existing access. Application permissions let software act without a signed-in user and may provide organization-wide access. Microsoft Graph names help show the difference. User.Read covers the signed-in user's profile, while User.Read.All can read profiles across the tenant.
This mechanism is also why an app grant deserves a different review from a staff account. Multi-factor authentication protects a person's sign-in, but software can continue using an approved token within the scopes it received. The earlier article on how app consent bypasses MFA explains how attackers abuse that process. The new research examines a separate problem: apps that users or administrators intended to install may still request access that is broader than their stated job appears to require.
Microsoft's own guidance tells administrators to review and revoke permissions granted to enterprise applications when an app has more access than necessary. The Canadian Centre for Cyber Security also says application accounts should follow the principle of least privilege, with permissions removed when they are no longer required.
An anomaly is a review signal, not a verdict
The researchers grouped the 1,069 applications into 24 topics based on their descriptions, then compared the permissions requested by apps with similar stated functions. Three anomaly-detection methods agreed on 139 applications, or 13 percent of the analysed dataset, whose permission profiles departed from their peers.
Some examples were difficult to reconcile with the marketplace description. The paper reports a project-management app requesting permission to read and modify authentication methods for every user. A vacation-tracking app requested organization-wide calendar access and the ability to change mailbox settings. Manual reviewers judged six of eight inspected anomalous cases to include permissions that appeared excessive or hard to justify.
Those examples need restraint. The paper is a preprint and has not yet completed peer review. Its marketplace data was largely collected in 2025, so the findings do not describe every app available in August 2026. The models compared declared functions with static permission sets. They did not observe how each app used data at runtime, and the authors state that an anomaly does not demonstrate malicious intent. Rare, tightly scoped permissions were sometimes flagged because good least-privilege design was unusual among peers.
The 13 percent figure therefore cannot be read as the share of Microsoft 365 apps that are unsafe. It shows how many apps in the usable dataset deserved a closer look under the study's conservative, peer-based method. For an administrator, that is still valuable. Permission count alone can miss one uncommon, powerful scope, while a familiar app name can make broad access feel routine.
Small firms need an owner for every connected app
Professional-services firms often connect scheduling, document signing, accounting, backup, CRM, and AI tools to the same tenant that holds client correspondence and files. A small team may approve those integrations during setup and never return to the list. Staff departures and vendor changes then leave service principals active without a business owner.
The result is cumulative exposure. One abandoned connector may retain mailbox access. Another can read SharePoint files. A third may hold directory permissions that help it enumerate users and groups. This resembles the privilege sprawl described in too many Global Administrators, except the identities belong to software and may keep working without an interactive sign-in.
Microsoft provides two levels of response. Every tenant can review enterprise applications and the admin or user consent attached to each one. Firms with Defender for Cloud Apps licensing can also use app governance insights to identify highly privileged, unused, and overprivileged apps, including permissions that have not been used in 90 days. Those automated labels help prioritize work, although an administrator still needs to confirm the business purpose and likely effect before disabling a production integration.
New requests need the same discipline. The U.S. Cybersecurity and Infrastructure Security Agency's Microsoft Entra secure configuration baseline calls for administrator-only application consent and an admin consent workflow so requested permissions receive a risk review. That approach gives staff a supported way to request a useful app while keeping tenant-wide grants out of an ordinary click-through decision.
Review the tenant before approving another integration
Open Microsoft Entra admin centre, go to Enterprise apps, and export the current application list. For each non-Microsoft app, record the business owner, publisher, last use, permission type, resources available to it, and the date access should be reviewed again. Pay close attention to application permissions, any scope ending in .All, access to authentication methods, and grants that can read or change mail, files, chats, calendars, or the directory.
Removing an unknown app without checking dependencies can interrupt a working process, so confirm its owner and activity first. If nobody can explain why it exists or why its broadest permission is required, suspend approval for new access and investigate the integration. The same ownership check should cover old file-sharing paths described in the review of anonymous share links.
Teclara's managed security and compliance service includes Microsoft 365 identity, application, and data-access reviews. This week, export the enterprise application list and require a named owner to justify every tenant-wide permission.