Delegated vs application permissions in Microsoft 365

Every third-party tool that plugs into your Microsoft 365 tenant uses one of two permission models. Delegated permissions let the tool act on behalf of a specific signed-in user, within that user's own access, and only while the user is present. Application permissions let the tool act as itself, tenant-wide, without any signed-in user. Both are valid, both have appropriate uses, and both carry different security consequences worth understanding before you consent to either. This piece is the vocabulary: what each model is, when each is appropriate, and what to ask a vendor before you grant consent.

Delegated permissions: acting as a user

A tool that uses delegated permissions asks the user to sign in to Microsoft directly. The user then consents (or an administrator consents on the user's behalf) to a specific scope, such as Files.Read.All or Mail.Send. Microsoft issues the tool an access token bound to that user and that scope. Every call the tool makes to Microsoft Graph or SharePoint uses that token, and Microsoft treats the call as if the user had made it themselves.

Three consequences follow.

• Scoped by the user's own access. A delegated tool can never do more than the user could do in a browser. If the user has access to three SharePoint sites, the tool has access to three sites. If the user's role is reduced, the tool's effective access is reduced.
• Requires the user's presence, at least intermittently. Delegated flows produce a refresh token that lets the tool obtain new access tokens without prompting for a password each time. That refresh token has a lifetime and can be revoked; if the user account is disabled, the refresh token stops working at the next attempt.
• Attributed to the user in audit logs. Microsoft's unified audit log records the user as the actor. Reconstructing who did what is straightforward. Ownership of an action does not disappear into the tool.

Delegated permissions are the natural fit for tools that a user actively interacts with, or that act on that user's own content: browser extensions, mobile apps, meeting plugins, per-user productivity tools, and file-access clients that map SharePoint into Windows Explorer.

Application permissions: acting as the app itself

A tool that uses application permissions authenticates as itself, not as any user. It presents a client secret or client certificate to Microsoft Entra ID, receives an access token that represents the application, and uses that token to call Microsoft 365 APIs. There is no signed-in user anywhere in the flow.

Application permissions can only be granted by a tenant administrator, and the grant covers the whole tenant by default. If the app has Sites.Read.All as an application permission, it can read every SharePoint site in the tenant, at any time, whether users are signed in or not.

Three consequences follow.

• Tenant-wide blast radius by default. The app can act across the whole tenant within its granted scope. Some newer scopes (such as SharePoint's Sites.Selected) allow admins to narrow application permissions to a named list of sites, but the tool has to support that model explicitly.
• Runs without a user. Nightly backups, org-wide reports, DLP scans and migration jobs all work fine when everyone is asleep. That is exactly what makes application permissions valuable, and also what makes them dangerous if the credential is compromised.
• Attributed to the application in audit logs. The unified audit log records the app as the actor, not any individual person. Reconstructing intent (who inside the vendor initiated a bulk export, and when) requires cooperation from the vendor's own logs.

Application permissions are the natural fit for automated, unattended, tenant-wide operations: backup and recovery tools, migration platforms, tenant analytics, DLP scanning, records-management indexers, and third-party identity or security services that need to observe the whole tenant.

Honest trade-offs, side by side

Neither model is universally safer. Each addresses a different problem. The trade-offs matter in real ways:

• Blast radius if the tool is compromised. A delegated tool holding one user's refresh token exposes one user's access. An application-permissions tool with tenant-wide scope exposes the whole tenant. A compromise of a vendor's certificate store is a very different incident to a compromise of one user's refresh token.
• Revocation. Revoking application consent is a single admin action that stops everything; it is also a decision people delay because "we still need the tool". Revoking delegated access can happen per-user (a leaver's account is disabled) or at the app level (remove consent for everyone); both take effect within an access-token lifetime, typically within an hour.
• Auditability. Delegated activity attributes to real people, which is what compliance and incident response want. Application activity attributes to the app, and reconstructing which internal vendor process (or vendor employee) drove a given action requires the vendor's own logs.
• User churn. With delegated permissions, when a user leaves and their account is disabled, the tool's access to their content ends automatically. With application permissions, leavers make no difference to the tool's access; you rely on the tenant-level consent staying appropriate over time.
• Consent friction. Delegated tools can (with admin approval) be granted per-user, which lets small pilots happen without full tenant commitment. Application permissions always require admin consent up-front, and always for the tenant as a whole.
• Scoping precision. Delegated permissions are naturally scoped by the user's own access. Application permissions default to tenant-wide and depend on the vendor to support narrower scopes such as Sites.Selected, specific mailboxes via ApplicationAccessPolicy, or per-group targeting.

When each model is appropriate

The right question is not "which is better" but "which is appropriate for what this tool actually does". A tool that needs to touch every mailbox at 03:00 without a signed-in user has to use application permissions; a tool that shows each user their own inbox in a side panel has to use delegated. Grey-zone cases exist (many analytics and governance products could go either way) and the choice often reflects the vendor's engineering convenience more than an architectural necessity.

Typical patterns by tool category

• Backup and disaster recovery: application. Tenant-wide, unattended, off-hours.
• Migration platforms: application. Full read/write across mailboxes, sites and OneDrive accounts, running in bulk.
• Tenant-wide analytics and reporting: application. Rolls up data across all users; no individual user context.
• DLP scanning and compliance indexers: often application, though the newer Sites.Selected model is becoming more common as a scoping mechanism.
• Records-management connectors (for example Laserfiche or OnBase Microsoft 365 integrations): typically application, because indexing runs continuously without user involvement.
• Third-party identity providers, MFA proxies, security telemetry: application. They have to run as their own identity to observe the tenant.
• Drive-mapping and real-time file-access clients (Cloud Drive Mapper and other tools in the category): delegated. Per-user file access is inherently user-scoped; the tool acts within the same rights the user has in a browser.
• Browser extensions and mobile apps: delegated. Users are always present and interacting.
• Meeting and calendar plugins: almost always delegated. Actions are per-user, initiated by the user.
• Line-of-business apps consuming a specific person's mailbox or files: delegated with per-user consent.

How to check what a vendor is actually using

Once you know the vocabulary the check itself is quick.

• Ask them plainly. A competent vendor answers cleanly: "delegated only", "application only with these scopes", or "both, and here is why". A vague answer is a signal.
• Read the admin consent screen carefully. When an admin consents to an app for the first time, Microsoft lists the scopes being requested and marks application-only scopes as running "without a signed-in user". Screenshot it. Save it.
• Inspect the app in Microsoft Entra ID. Go to Enterprise applications, open the app, and click Permissions. Application permissions and delegated permissions are listed in separate columns. Look for anything with .All in the scope name (for example Files.ReadWrite.All) as a flag for tenant-wide reach.
• Check the vendor's documentation. A reputable vendor documents its Microsoft 365 integration precisely: which flow, which scopes, why each is required. If the docs are silent on the permission model, treat that as an information gap you need to close before consent.
• Look for granular application scopes. Vendors that offer Sites.Selected, ApplicationAccessPolicy for Exchange, or per-group targeting are actively reducing the tenant-wide default. That is a good sign.

A few red flags worth pausing on: requests for permanent Global Administrator role assignment (almost never necessary), refusal to explain scope requests in plain language, docs that describe "the app just needs Microsoft 365 access" without listing scopes, and permission grants that were made in a hurry during a POC and never revisited.

Questions to ask before granting either

• What does this tool actually need to do that requires this permission level?
• If application, can the scope be narrowed (Sites.Selected, specific mailboxes, specific groups)?
• Where does the tool store its client secret or certificate, and how is that store protected?
• How do we revoke access if we need to, and how quickly does revocation take effect for in-flight tokens?
• What does this tool's activity look like in our unified audit log? Can we reconstruct who initiated a given action, or does it all attribute to the app identity?
• If your service is compromised, what would an attacker be able to do with our tenant?
• What is your process for rotating your client secret or certificate, and when did you last do it?
• Do we have to re-consent for new scopes, or can you silently add them under an existing consent?

None of these are hostile questions. They are the conversation that should happen once at consent time and then periodically as part of vendor review. A vendor that answers them cleanly is one you can trust with the permission grant they are asking for.

A short summary

Delegated permissions bind a tool to a user's own access, keep the blast radius small, and produce a clean audit trail. Application permissions let a tool run unattended across the whole tenant, which is essential for backups, migrations and org-wide operations, but concentrate risk into a single credential the vendor holds. Neither is universally better; both are appropriate for different jobs. What matters is that the tool's permission model matches the job it actually does, and that your team has the vocabulary to check.

Related solutions

• Zero-access architecture in Cloud Drive Mapper
• Seven questions to ask any Microsoft 365 vendor

← Back to all solutions