Delegated Permissions

Menu path: Observe → Application Governance → Delegated Permissions
URL: /en/insights/dashboard/appGov/delegated-api-permissions

Purpose

The Delegated API Permissions page analyses user-consented permissions - the permissions that applications request when a user signs in and grants the application access to act on their behalf. Unlike application permissions (which grant daemon/background access), delegated permissions are associated with a user's session and are limited to what that user can do.

Delegated permissions represent a different class of risk from application permissions. They cannot exceed the user's own privileges, but they can be used to exfiltrate data from a user's mailbox, calendar, files, or profile - and they can be granted by individual users without admin approval for lower-risk scopes. High-risk delegated permissions (such as the ability to reset passwords) require admin consent.

This page helps you understand your delegated permission landscape: which applications have been granted access to act on behalf of users, what level of access they have, and whether that access is appropriate given the application's usage patterns.

---

Observation Cards

Removal Candidates by Risk

Chart type: add example --> Donut chart
What it shows: 3 inactive or unused applications with delegated permissions, grouped by risk level (Low and High).

Why it matters: An inactive application that was granted delegated permissions means a user previously consented to give that application access to their account. If the application is no longer used, those consent grants should be revoked to reduce the attack surface.

Delegated Permission Risk Distribution

Chart type: add example --> Donut chart
What it shows: 19 total delegated permission grants across all applications, broken down by risk level (Low vs High).

Why it matters: The relatively small number (19) compared to app role permissions (79) reflects that this environment has very few user-facing applications that require delegated access. The presence of High-risk delegated permissions (such as password reset capabilities) warrants investigation.

---

Charts

Risk Exposure vs Access Control

Chart type: add example --> Bar chart
What it shows: For applications with high-risk delegated permissions, whether they have "Assignment Required" enabled (access control) or not.

Why it matters: An application with high-risk delegated permissions AND no assignment requirement means any user in the tenant could potentially use that application and its delegated permissions. High-risk delegated permissions should always be paired with "Assignment Required" to ensure only authorised users can trigger those permissions.

Delegated Permission Sprawl Over Time

Chart type: add example --> Time-series area chart
What it shows: How the count of delegated permission grants has grown over time, separated by risk level (Low and High).

Why it matters: A growing High-risk delegated permission line means more and more applications are being granted sensitive delegated access. If this growth is outpacing your review process, you may not be adequately overseeing what user-data access is being granted.

Risk by Application

Chart type: add example --> Bar chart (top 50)
What it shows: Which applications carry the highest delegated permission risk.

Applications Granted Scopes

Chart type: add example --> Bar chart
What it shows: How widely specific delegated scopes are used across the application estate.

---

The Delegated Permissions Table

Each row represents a delegated permission scope granted to an application:

• Principal - The application holding the delegated scope
• Risk Level - Low or High
• Value - The specific permission scope (e.g., User.Read, User-PasswordProfile.ReadWrite.All)
• Resource - The API (Microsoft Graph)
• Security ID - Tracking reference for security review
• Last Client Sign-In - When the application last authenticated

Understanding delegated permission risk

Low-risk delegated permissions (e.g., openid, profile, email, User.Read, offline_access): These are standard OpenID Connect scopes used for single sign-on and basic profile access. They allow the application to identify the user and read their basic profile - not their files, emails, or sensitive data. These are expected and normal.

High-risk delegated permissions (e.g., User-PasswordProfile.ReadWrite.All, User.EnableDisableAccount.All, UserAuthenticationMethod.ReadWrite.All, User.ReadWrite.All): These allow an application to modify user accounts, reset passwords, or change authentication methods on behalf of a user. These are unusual for typical end-user applications and require admin consent. Their presence should be carefully reviewed.

Key findings from the example data

From the 19 permissions listed:

• BeyondTrust - BeyondInsight holds three High-risk delegated scopes including User-PasswordProfile.ReadWrite.All, User.EnableDisableAccount.All, and UserAuthenticationMethod.ReadWrite.All. This makes sense for a Privileged Access Management (PAM) tool that needs to manage user credentials, but it underscores how critical it is that BeyondTrust itself is properly secured and access-controlled.
• Microsoft Graph Command Line Tools has User.ReadWrite.All as a delegated scope. This is the interactive Graph PowerShell/CLI tool - granting User.ReadWrite.All to this tool means a user running it can modify any user account's properties (within their own admin role limitations). This is appropriate for administrators but should not be consented to by standard users.
• Most other applications use only standard low-risk OIDC scopes - this is the healthy pattern.

Delegated permissions vs Application permissions - the key difference

	Delegated Permissions	Application Permissions
Requires a user	Yes - user must sign in	No - runs without a user
Bounded by	The signed-in user's own permissions	The permissions granted to the app
Can exceed user permissions	No	Yes (if admin-consented)
Typical risk	Lower (bounded by user)	Higher (can be tenant-wide)
Example	App reads the signed-in user's email	App reads ALL users' email