What happened
On August 3, 2026, researchers published a privacy- and security-oriented measurement of the Microsoft 365 third-party application ecosystem. Researchers crawled over 8,000 Microsoft 365 applications. Only 1,069 applications exposed both descriptions and permission sets. The study reports inconsistent transparency across official distribution channels, meaning tenant administrators may not receive a complete, standardised explanation of requested access through the information presented with an application.
The researchers combined marketplace information with automated tenant-side deployment, then used topic-aware anomaly detection to compare requested permissions with declared application functions. Their manual review found a correlation between anomalous permission profiles and the risk associated with requested permissions. That result does not prove that an anomalous application is malicious; it identifies candidates whose permissions diverge from functional peers and therefore require additional assurance.
Many applications requested tenant-wide scopes, including directory-wide read/write access. Such grants can place an external application inside the Microsoft 365 control plane with access that persists beyond a user’s interactive session. The operational question is therefore not whether an application came from an official marketplace, but which effective permissions the tenant granted, which identity owns the decision and what evidence supports continued access.
SentinelOne’s 2026 outlook cites August 2025 abuse of Salesloft Drift OAuth rights to harvest cloud-service and SaaS credentials. That historical context is not evidence against the applications measured in the new paper, but it shows how delegated SaaS access can become an intrusion path when an integrated provider or application is compromised. Attribution posture: The Microsoft 365 measurement does not identify a malicious application or attribute abuse to a threat actor. No application IDs, service-principal IDs, tenant IDs, domains, hashes or malicious redirect URIs are published in the cited abstract. The cited source did not publish the specific indicators described as The cited abstract does not publish hunt-ready application or infrastructure identifiers.
Why this matters now
Microsoft 365 application consent can grant durable access to mail, files, calendars, chats and directory information without creating the same operational visibility as a conventional user account. If application purpose, permissions and ownership are inconsistent or opaque, security teams cannot reliably answer which third parties can reach sensitive tenant resources or revoke access during an incident.
The research provides a practical prioritisation method. Applications with permissions that diverge from peers performing similar functions can be reviewed before lower-risk, well-understood grants. That does not replace business context, but it gives identity teams a defensible way to reduce a large consent backlog without treating every integration as equally risky.
Marketplace presence should be treated as distribution evidence rather than tenant-specific security approval. Effective access depends on the granted scopes, whether application or delegated permissions are used, the persistence of tokens or credentials, and downstream data reach. Those decisions remain the tenant’s responsibility even when the software is commercially established.
The control also supports incident readiness. A current application register allows responders to identify exposed integrations, revoke consent, remove service-principal credentials and monitor reauthorisation. Without that register, third-party identity containment becomes an emergency discovery exercise during a breach.
The decision for security leaders
Create a tenant application-grant register that records canonical application name, application and service-principal identifiers, business owner, vendor, declared function, effective permissions, consent authority, credential type, last use and review date. Unknown ownership or purpose should trigger revocation or a time-bound exception.
Define high-risk permission classes for directory write, broad mailbox or file access, persistent offline access, application-only access and privilege-management functions. Require security review and reapproval when an application enters one of those classes or its permissions change materially.
Monitor consent grants, service-principal creation, credential additions, permission elevation and administrative reauthorisation. Incident playbooks should include both revoking tenant consent and invalidating associated credentials or sessions; removing a marketplace application from user view is not sufficient containment.
Evidence of closure
- A tenant register maps every application to owner, purpose, permissions and review date.
- High-privilege grants have documented necessity and approved compensating controls.
- Ownerless and unused applications are revoked or placed under time-bound exception.
- Monitoring detects new consent, permission elevation and service-principal credential changes.
The Security.io assessment
The study’s strongest contribution is measurement, not accusation. It demonstrates structural opacity and frequent broad access while explicitly stopping short of identifying malicious applications. Enterprises should preserve that distinction: anomalous permission profiles are review signals, not proof of compromise or vendor wrongdoing.
Attribution posture: The Microsoft 365 measurement does not identify a malicious application or attribute abuse to a threat actor. SentinelOne’s historical Salesloft Drift example provides relevant risk context, but it should not be used to infer that applications in the measured dataset were involved in the same activity.
The issue belongs in identity governance because OAuth grants and service principals can operate as privileged non-human identities. Procurement approval, marketplace listing and user demand do not answer whether the effective tenant permissions are proportionate, monitored and rapidly revocable. The CISO should make that assurance requirement explicit.
Our assessment is that enterprises should begin with ownerless applications and tenant-wide write access, then progress to broad read and persistent delegated permissions. Closure requires a governed register and monitoring evidence, not a one-time application count or consent cleanup.
Questions for the morning meeting
- How many third-party applications can read or modify tenant-wide data?
- Which grants rely solely on marketplace descriptions for assurance?
- Who can approve application consent with persistent offline access?
- How quickly can the tenant revoke a compromised application and its sessions?