Unused Delegated Consents

The question it answers: Which apps hold delegated consent to users’ data but have not signed in on anyone’s behalf for 90 days?

Apps that users (or an admin, for everyone) granted access to their data, but that have not signed in on anyone’s behalf for 90 days. The permission is still live: revoking it removes the risk without affecting anyone.

Note

‘No delegated sign-in recorded’ also covers apps idle since Microsoft started collecting this data. Rows with high-impact scopes (mail, files, directory write) are listed first.

At a glance

Where in the app	Entra ID › Identity Hygiene › Unused Delegated Consents
Workload	Entra ID
Kind	Table
Data	Built from the tenant data IntensiveReports keeps in memory and refreshes in the background, so it opens at once.
Licence	Microsoft Entra ID P1 (service principal sign-in activity).
Report id (API and MCP)	entra.security.unused-consents

Columns

Column	Key	Type
App	DisplayName	Link
Consent	Category	Status
Granted by	Value	Text
Finding	Finding	Text
Last delegated sign-in	Date	Date
Scopes	Detail	Text
App ID	Secondary	Text

What it needs

Licence: Microsoft Entra ID P1 (service principal sign-in activity).

Application permissions on the IntensiveReports app registration (all permissions):

Permission	API	What it allows	Note
Directory.Read.All	Microsoft Graph	Read directory data
Application.Read.All	Microsoft Graph	Read all applications
AuditLog.Read.All	Microsoft Graph	Read all audit log data

Data sources it reads

• GET /v1.0/oauth2PermissionGrants
• GET /v1.0/servicePrincipals
• GET /beta/reports/servicePrincipalSignInActivities

Through the API and MCP

GET /ir-api/v1/reports/entra.security.unused-consents?size=100

An AI assistant reads it with the MCP tool get_report and the id entra.security.unused-consents. The client needs the Read grant for Entra ID. See Using the API.