Guests with Elevated Access

The question it answers: Which guests hold a directory role or own a role-assignable group, an app registration or a Team?

External accounts should consume, not administer. A guest who holds a directory role, owns a role-assignable group, an app registration or a Team can change who has access - with an identity your organisation does not control and cannot MFA-enforce as tightly.

At a glance

Where in the app	Entra ID › Identity Hygiene › Guests with Elevated Access
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	No extra licence needed.
Report id (API and MCP)	entra.users.elevated-guests

Columns

Column	Key	Type
Guest	DisplayName	Link
Mail	Secondary	Text
Access type	Category	Status
Finding	Finding	Text
Role / group / Team	Detail	Text
Account	Value	Text

What it needs

Licence: No extra licence needed.

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

Permission	API	What it allows	Note
User.Read.All	Microsoft Graph	Read all users’ full profiles
User-LifeCycleInfo.Read.All	Microsoft Graph	Read all users’ lifecycle information
RoleManagement.Read.Directory	Microsoft Graph	Read all directory RBAC settings
Group.Read.All	Microsoft Graph	Read all groups
Application.Read.All	Microsoft Graph	Read all applications

Data sources it reads

• GET /v1.0/users
• GET /v1.0/roleManagement/directory/roleAssignments
• GET /v1.0/groups/{id}/owners (role-assignable groups, Teams)
• GET /v1.0/applications?$expand=owners

Through the API and MCP

GET /ir-api/v1/reports/entra.users.elevated-guests?size=100

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