A Claimed World First Exposes a Microsoft 365 Blind Spot
What IT Teams Should Check Before Migrating
Published 20 August 2026
Microsoft 365® migrations can look wonderfully orderly in project plans: Assess the source. Map the destination. Move the data. Test the result. Cut over. Celebrate with the least suspicious treat in the office snack cupboard.
Real environments are less obliging. Behind the migration plan’s neat boxes and arrows sits a dense ecosystem of third-party applications, OAuth (Open Authorization) permissions, linked spreadsheets, embedded objects, shortcuts and informal workflows. Many have become essential without ever being formally recognized as such.
A newly released study has taken a close look at one part of that ecosystem: the permissions that third-party apps request when they connect to Microsoft 365.
This paper raises a valuable question for IT managers, migration consultants and MSPs …
Submitted to arXiv (a free open-access platform where researchers share papers before they go through peer review) on August 3, 2026, Lost in Permissions: Exploring the Microsoft 365 App Ecosystem presents what its authors describe as the first privacy and security-oriented measurement of Microsoft 365 third-party applications.
That wording matters. To be clear, this is a fresh preprint rather than a peer-reviewed journal article, so its findings deserve attention without being overstated.
This paper raises a valuable question for IT managers, migration consultants and MSPs: Does the access an app requests actually make sense for the job it claims to do? And how secure is it?
Before I cover their revealing and extremely interesting findings, I’ll first briefly summarize some of the main points the study examined. If you’re a “just give me the final score” kinda person, skip down to the “What Did They Find?” section.
What Were the Researchers Looking For?
As you no-doubt know, Microsoft 365 supports a large ecosystem of third-party apps. To work, many of those apps need permission to access protected resources. A calendar tool might reasonably need calendar access. A document-management app may need permission to read files, to give just a couple of simple examples.
Microsoft doesn’t simply assign a standard permission package to every type of app. Developers specify the permissions their software needs. Depending on how the app is designed, delegated permissions can be configured in advance or requested dynamically, while application permissions let software operate without a signed-in user and require administrator consent.
That gave the researchers something useful to compare. An app’s description tells you what it says it does. Its permissions tell you what it is asking Microsoft 365 to let it do.
If those two stories appear not to match, the app may deserve closer scrutiny.
I want to emphasize that this doesn’t automatically make the app malicious. It may have poorly described features or legitimate technical requirements. But unusually broad access is worth understanding.
Apps have become an integral part of life, but how can you tell if their access is excessive?
Building a Picture of the App Ecosystem
Gathering the necessary information wasn’t as simple as browsing a single Microsoft app store. Microsoft 365 applications reach users through several distribution channels, including the Teams® and Office add-in stores, Microsoft Marketplace and third-party integrations.
The researchers used these various sources to identify apps and collect descriptions of what they claimed to do. Their September 2025 Marketplace crawl identified 8,232 unique apps across Teams, Outlook®, Word™, Excel™, PowerPoint™ and SharePoint®.
The harder part was collecting permissions data. That information is presented inconsistently across different channels, so the researchers installed hundreds of apps in a dedicated Microsoft 365 test tenant and inspected their effective OAuth permissions through Entra ID (a cloud-based identity and access management service, formerly known as Azure Active Directory). They supplemented this with anonymized information about apps used in an operational university tenant.
After matching descriptions with permission sets, removing duplicates and filtering unsuitable records, they arrived at 1,069 apps for which they had both a usable description and associated permissions.
That was the dataset used for the main anomaly analysis.
What Did They Find?
The researchers grouped the 1,069 apps into 24 categories according to their stated functions, then compared apps performing broadly similar jobs. A scheduling app should be compared with other scheduling apps, not with a backup platform, for example.
What gives the figure more weight is what happened next.
They were looking for permission patterns that stood out from those of an app’s functional peers. Using several anomaly-detection methods, they flagged 139 apps, or about 13% of the analyzed dataset, as essentially having something unusual or uncommon about their permissions compared with other apps of the same type.
There is no established Microsoft 365 benchmark telling us whether 13% is high or low. That’s partly because the authors describe this as the first systematic privacy and security study of the Microsoft 365 third-party app ecosystem.
What it doesn’t mean is that 13% of Microsoft 365 apps are necessarily dangerous. An anomaly simply means the requested permissions looked unusual compared with those of similar apps. What gives the figure more weight is what happened next.
The researchers manually inspected eight anomalous apps in a blind review. In six of these cases, reviewers found permissions they considered excessive or difficult to justify from the apps’ stated purposes. The paper also describes examples involving broad access to directories, calendars, chats and files.
Eight apps is far too small a sample to establish an ecosystem-wide failure rate. It does, however, show why all apps deserve investigation. Then, those with unusual permission patterns warrant an even closer look.
“It was already installed” is not a security assessment.
Why This Matters During a Migration
Migrations expose assumptions that everyday operations let us ignore. An app may rely on permissions granted years ago. A workflow may run through a service account nobody currently owns. A departmental process may depend on a tool that somehow escaped pilot status through sheer persistence.
Then the environment changes. Tenants are consolidated. Accounts are retired. SharePoint sites are rebuilt. File shares move. Security groups change. Apps may need to be reauthorized.
Suddenly, hidden dependencies stop being hidden.
That makes migration an excellent time to review third-party apps. Ask the useful questions: Who owns this app? What process does it support? Which users depend on it? What can it access? Does that access still make sense? Will it still be needed after migration?
A tool used by 500 people deserves attention, but so does the one used by a single person who produces the month-end financial report.
Who does it belong to? What does it do? Do you need it after the migration?
Access Is Only One Dependency Layer
There’s another connection here that matters enormously during data migration. Permissions determine who or what can access a resource. Links determine whether information inside that resource can still reach something else.
Consider a tightly secured finance workbook. Access is restricted. Its audit trail is pristine. However, after migration, its links still point to spreadsheets and reports on a retired file server.
Yes, the document is secure, but it’s also virtually useless.
Files often contain relationships that ordinary inventories miss. Excel workbooks reference other spreadsheets. Word documents contain linked objects. PowerPoint presentations rely on external media. Access databases connect to external tables. Shortcuts lead to files, folders and applications.
Change a server, path, folder name or platform and those links stop landing where they should. A migration can, therefore, move every file successfully while ultimately leaving users with documents that no longer work correctly.
Recommended: Build Two Dependency Maps
I believe that a well-prepared migration needs two connected views.
Broad permissions can be legitimate, but they should never be hidden or mysterious.
The first is an access map. It identifies which users, groups and applications can reach organizational resources and what permissions have been granted.
The second is a content dependency map. It identifies links inside files, the resources those links depend on and the locations likely to change.
One helps control exposure. The other helps preserve functionality. Neither replaces the other.
Five Checks Before Cutover
1. Inventory connected apps
Confirm each application’s owner, publisher, purpose and current usage. Old trials and abandoned projects have a remarkable ability to outlive their retirement parties.
2. Review permissions
Compare the access each app requests with the job the business expects it to perform. Broad permissions can be legitimate, but they should never be hidden or mysterious.
3. Discover links in critical files
Scan important content before migration, especially files used in finance, operations, compliance, engineering and customer-facing processes.
4. Protect links before files move
LinkFixer Advanced™ can protect working links before files and folders are migrated or renamed, and automate link management across large collections of files. That turns link preservation into a planned migration task rather than a massive helpdesk exercise after cutover.
5. Test what actually works
Post-migration validation should go beyond file counts. Confirm that approved applications retain appropriate access, retired apps do not, and open a representative set of files to test whether the links are still working.
LinkFixer Advanced can also repair broken links in bulk when damage has already occurred.
Remember that a file that exists in the destination is not necessarily a file that works.
Turn Migration Into a Controlled Reset
For clarity, I want to repeat that the new app study does not prove that the Microsoft 365 marketplace is packed with dangerous apps. Its much more useful message is that some apps request access that looks unusual when compared with their peers, and that permission information can be difficult to see consistently.
Its conclusions should still be treated with caution. The paper has not yet been peer-reviewed. Its main analysis covered 1,069 apps and its manual assessment involved only eight.
But the principle behind it is solid: Trust should be examined rather than simply inherited.
With the correct software, the data connections that users rely on remain intact during migration, preventing downtime and disruption.
Applications should have access that matches a clear purpose. Files should retain the links they need to remain useful. A migration should preserve valid dependencies while removing obsolete ones.
Migration isn’t simply a relocation project. It’s a chance to understand an environment that may have evolved for years without a full inspection. Before your next migration, ask two questions:
- Who or what can access our data?
- What will still connect to it after we move?
The first protects security. The second protects continuity. Together, they help prevent a migration that looks flawless in the dashboard but develops an entirely different personality on Monday morning.
By Ed Clark
LinkTek COO
Ed Clark
Feel free to share this article on your social media:
Recent Comments
- No recent comments available.
ChatGPT,
Gemini,
Claude and
Copilot
Leave a Comment