Microsoft 365 apps: who can access your business data?

A new tool promises better meeting notes, easier scheduling or faster replies to customers. You can sign in with your existing Microsoft account. One click on “Accept” and the team is ready to work. That moment deserves more attention: signing in and authorising access to company information are different things.

For a Swiss SME, the important question is not simply which software is installed on its laptops. It is also which connected applications can use its email, files or calendars. A browser-based tool with no local installation may matter more to the business than an installed program. And a modest monthly subscription says little about the reach of its integration.

My recommendation is to treat application permissions as business mandates. Each needs a clear purpose, an accountable owner and a review date. This does not require a major programme. A focused first review of your most important integrations can already give you a useful basis for decisions.

Submitted on 3 August 2026, the research paper “Lost in Permissions” examines more than 8,000 third-party Microsoft 365 applications. Descriptions and permission information were both available for 1,069. The authors report inconsistent transparency and examples of overly broad access requests. This does not establish that every app is dangerous or that your business is affected. The preprint is a reason to review permissions, not an individual risk assessment.

My practical conclusion is that a familiar platform and a professional product website do not replace scrutiny of the permissions actually granted. This article therefore focuses on reviewing existing Microsoft 365 integrations. It is not an argument against external applications or a general debate about whether to adopt AI. Sources were checked on 16 September 2026; the priorities and working methods below are my recommendations.

Microsoft distinguishes delegated and application permissions. Delegated access acts on behalf of a signed-in user, within that user's rights. App-only access uses the application's own identity without a signed-in user. The actual permissions and resource scope matter in both cases. Administrative consent can also cover delegated permissions: “approved by an administrator” does not automatically mean app-only.

Management needs to understand this distinction, not become expert in its implementation. Technical assessment belongs with qualified IT staff. The decision record, however, should not contain permission codes alone. Translate them into a plain-language statement, such as reading a particular document collection or sending messages. Only then can the business owner meaningfully assess the scope.

The following table supports decisions; it is not a blanket approval list. Read-only access can still involve confidential information. Conversely, broad access may be justified for a clearly defined operational service. What matters is the relationship between the task and the access requested.

Ask the supplier to respond in writing. “Technically required” is the start of an explanation, not its conclusion. If narrower access is unavailable, make an explicit decision about additional value, additional controls or an alternative product. You do not need to understand every technical detail to ask for a coherent justification.

Microsoft publisher verification establishes the authenticity of the publishing organisation. It does not assess your particular use case. My recommendation is to use verification as one entry criterion, not as a substitute for reviewing permissions and data use.

Keep three procurement questions separate: who is the supplier, what can its application do technically, and what happens to the information it receives? A convincing answer to one does not answer the others. For an AI tool in particular, storage, deletion and the involvement of other service providers should be described clearly.

Do not demand a hundred-page response for a small application. A short, reliable record is more useful than a long questionnaire nobody evaluates. If a supplier cannot answer central questions about purpose and scope, defer approval. That is not a judgement about the supplier's intentions. It means the evidence needed for a decision is missing.

Start with a list of the integrations used for business. Record the business owner, IT contact, purpose, data scope, granted permissions and next review date for each. Include dependencies: which processes would stop working if the integration were disconnected? A simple register in an existing tool is sufficient to begin.

Microsoft's permission review guidance starts in Enterprise applications in Entra ID. Administrative and user consent should be examined separately. According to the documentation, revoking user consent requires Microsoft Graph or PowerShell. Have qualified staff make changes in a controlled way.

Do not work through the list alphabetically. Prioritise combinations of confidential information, write access and missing ownership. An unexplained entry is initially an open question, not automatically a security incident. Preserve the current configuration and establish how an integration is used before changing production access. A rushed cleanup could otherwise interrupt invoicing or a backup service.

Microsoft documents user consent policies, including restricted consent for verified publishers and selected permissions. Crucially, changing a policy does not retrospectively change existing consent grants. Reviewing earlier approvals remains a separate task.

For an SME, I would define a straightforward path. Employees describe the use case, IT assesses the technical scope, and the business owner confirms the value. Involve the appropriate privacy or security owner when sensitive information is involved. Assign a deputy and a realistic response time. A process that remains silent for weeks is unlikely to be regarded as helpful.

A rejection should include an explanation and, where possible, an alternative. An existing tool may be sufficient. The intended outcome may be achievable with less information. This turns approval into a product decision: which benefit justifies keeping which connection in operation? Technical consent is the final step in that decision, not a replacement for it.

Consider a fictional planning consultancy with 35 employees. The team wants to automate the preparation of project meeting summaries. Its pilot should process approved sample documents only. The proposed connector, however, requests substantially broader access than the pilot needs. Neither immediate approval nor a blanket declaration that the product is unsafe would be the right response.

The consultancy asks for a restricted configuration and initially tests the workflow without connecting its entire document estate. It evaluates summary quality, editing time and the information actually needed. Only then does it decide whether deeper integration is justified. This sequence is my recommendation, not a reported customer outcome.

If the supplier insists on broad access, discuss the benefit and the limitation together. A better summary does not justify every possible permission. Equally, a business-critical service may warrant greater assessment effort. Record when the decision must be revisited: for example, when functionality changes, new data sources are added or ownership moves to another person.

I suggest a bounded first review, not a complete security programme. The timing below is a working structure, not a promise that every environment can be cleaned up in ten days. A large application estate or missing documentation will require more time.

• Assign one person to coordinate the review.
• Assess permissions and actual business purpose together.
• Document changes before implementation and test affected workflows afterwards.
• Give outstanding questions an owner and a deadline.

Five applications is a practical starting point, not a security standard. Review a few relevant cases carefully rather than superficially checking a long list. The first pass should establish a repeatable way of working and make subsequent decisions easier.

Do not measure success simply by the number of applications removed. That might also mean useful workflows have been lost. Three questions are more informative: do the priority applications have a confirmed purpose and owner, are broad permissions justified, and are outstanding decisions completed by the agreed date?

One useful measure is the share of reviewed applications within the explicitly defined review scope. Always state that denominator. “All five priority integrations reviewed” is more honest than “Microsoft 365 secured”. Record which areas have not yet been examined. This helps management weigh the next review against other work.

Plan retirement as well: who coordinates technical disconnection, contract termination and the handling of data held by the supplier? Removing a connection and obtaining confirmation of data deletion are separate work packages. Assigning responsibility during implementation can prevent avoidable investigation later.

Microsoft 365 applications can remove useful amounts of work. The answer to unclear permissions is therefore not to stop using integrations, but to give each one a clear mandate. Review the most important connections first, translate technical permissions into business consequences and keep a record of the decisions.

The next useful step is small: select the five applications whose access you want to understand properly. If IT and the business can then give the same explanation, you have achieved more than another general security presentation would provide.