Permission transparency

What the connector asks for

This is the complete list of application permissions the auto-managed Microsoft connector requests when your Global Admin consents — every one, what it is for, whether it reads or writes, and the two that deserve a plain-language explanation. It is generated from the same registry the provisioning code uses, and a test fails if the two ever differ.

Auto-managed connector setup Licence coverage

Permissions

across 4 Microsoft resource APIs

Read-only

classified by documented effect, not by name

Write-capable

2 of which can escalate to tenant admin

Monitor-only subset

everything except response actions; zero escalation paths

Required

Ingestion and detection (16)

Read the directory, sign-ins, audit logs, risk signals, security alerts and the Office 365 activity feed. Every detection, posture check and report is built on these.

Permission	Resource API	Why ITDR needs it	Class
`User.Read.All`	Microsoft Graph	User inventory	Read
`Directory.Read.All`	Microsoft Graph	Directory enumeration (groups, roles, org)	Read
`Organization.Read.All`	Microsoft Graph	Tenant metadata	Read
`Device.Read.All`	Microsoft Graph	Device inventory	Read
`AuditLog.Read.All`	Microsoft Graph	Directory audit + sign-in logs	Read
`Reports.Read.All`	Microsoft Graph	Reports API (license usage etc.)	Read
`Policy.Read.All`	Microsoft Graph	Conditional Access posture + auth methods	Read
`IdentityRiskEvent.Read.All`	Microsoft Graph	Risk detections	Read
`IdentityRiskyUser.Read.All`	Microsoft Graph	Risky users	Read
`SecurityAlert.Read.All`	Microsoft Graph	Defender alerts	Read
`SecurityIncident.Read.All`	Microsoft Graph	Defender incidents	Read
`SecurityEvents.Read.All`	Microsoft Graph	Secure Score reads	Read
`RoleManagement.Read.Directory`	Microsoft Graph	Identity risk checks: permanent vs PIM (JIT) role assignments	Read
`ActivityFeed.Read`	Office 365 Management APIs	Ingestion: O365 audit activity feed subscriptions + content	Read
`ActivityFeed.ReadDlp`	Office 365 Management APIs	Ingestion: DLP policy events on the audit feed	Read
`ServiceHealth.Read`	Office 365 Management APIs	Ingestion: M365 service health for the customer tenant	Read

Only if you want ITDR to act

Response actions (7)

Disable an account, revoke sessions, remove a group member, revoke an application's credentials or grants, lock or wipe a device. These are the only write permissions that touch users, and the only two that can escalate are here.

Permission	Resource API	Why ITDR needs it	Class
`User.EnableDisableAccount.All`	Microsoft Graph	Disable user response action	Write
`User.RevokeSessions.All`	Microsoft Graph	Revoke sessions response action	Write
`GroupMember.ReadWrite.All`	Microsoft Graph	Remove user from group response action	Write
`Application.ReadWrite.All`	Microsoft Graph	Application revocation: disable SP, remove credentials, remove role assignments, remove delegated grants	Write · can escalate
`AppRoleAssignment.ReadWrite.All`	Microsoft Graph	Response action: Remove app role assignment	Write · can escalate
`DelegatedPermissionGrant.ReadWrite.All`	Microsoft Graph	Response action: Remove OAuth consent and remove delegated permission grant	Write
`DeviceManagementManagedDevices.PrivilegedOperations.All`	Microsoft Graph	Response action: Lock / Wipe / Retire Intune-managed device	Write

Configuration reads

Posture checks (6)

Read tenant settings for the Microsoft 365 posture scan: hybrid sync state, SharePoint settings, Defender for Identity health, Exchange and Teams configuration.

Permission	Resource API	Why ITDR needs it	Class
`OnPremDirectorySynchronization.Read.All`	Microsoft Graph	Posture: hybrid identity sync state	Read
`SharePointTenantSettings.Read.All`	Microsoft Graph	Posture: SharePoint tenant settings	Read
`SecurityIdentitiesHealth.Read.All`	Microsoft Graph	Posture: Defender for Identity health	Read
`SecurityIdentitiesSensors.Read.All`	Microsoft Graph	Posture: Defender for Identity sensors	Read
`Exchange.ManageAsApp`	Office 365 Exchange Online	Posture: Exchange-as-application read	Write
`application_access`	Skype and Teams Tenant Admin API	Posture: Teams admin module access	Write

Scoped to itself

Credential self-rotation (1)

Lets the connector mint its own replacement secret before expiry. OwnedBy, not All: it can only touch applications it owns, which is only itself.

Permission	Resource API	Why ITDR needs it	Class
`Application.ReadWrite.OwnedBy`	Microsoft Graph	Self-rotation of own credential (managed by platform rotation worker)	Write

Read this part

Two permissions that can take over a tenant

Both are in the response-actions group. Neither reads as dangerous on Microsoft's consent screen, and most products in this category request them. We would rather you heard it from us.

Application.ReadWrite.All

What we use it for. Revoking a malicious application: disabling its service principal and removing its credentials and grants.

Why it matters. It can add a password or certificate to any application or service principal in the tenant, including ones that already hold administrative roles. Whoever holds it can therefore become any app in the tenant.

AppRoleAssignment.ReadWrite.All

What we use it for. Removing an app role assignment from a compromised or over-privileged application.

Why it matters. App role assignments are how application permissions are granted. Holding this permission means being able to grant any permission to any service principal, including oneself. Microsoft's own reference notes that it lets an app grant itself additional privileges.

What we do about it

How the exposure is limited

The app lives in your tenant, not ours

Auto-managed setup creates a dedicated app registration inside your Entra tenant with its own credential. There is no single shared credential across our customers, so a compromise of another customer's connector cannot reach you, and a compromise of our infrastructure is bounded by the per-tenant secrets it holds.

You can revoke us unilaterally

Delete the app registration, disable its service principal, or remove its credential in the Entra portal. It takes effect immediately, needs nothing from us, and there is nothing we could do to prevent it.

Everything is attributed in your audit log

Every call the connector makes is recorded in your own Entra audit log against that service principal. You can see exactly what ITDR did and when, without asking us.

The secret rotates itself, narrowly

A daily job replaces the secret when it is within 30 days of expiry using Application.ReadWrite.OwnedBy — scoped to apps the connector owns, which is only itself. No Global Admin session is needed after setup.

Failed setup leaves nothing behind

If any step of provisioning fails, the half-created app is deleted so an orphaned privileged identity is never left in your tenant.

Stored encrypted

Connector secrets are encrypted at rest with a key held separately from the database.

What it does not solve

Honest limits

The per-tenant model reduces blast radius; it does not reduce the privilege held inside your tenant. The connector is capable of full tenant control, because two of the response permissions are. If you will never use response actions you should be able to decline them, and today you cannot: every auto-managed connector receives the full set. A monitor-only tier is on the roadmap; until it ships, a bring-your-own app-only connector is the way to grant only what you want.
Some connectors provisioned before auto-managed mode existed run on a shared platform credential rather than a per-tenant one. The connector page in the app shows which mode each connector uses.
We do not measure detection precision yet. Nothing on this page, or elsewhere on this site, claims a false-positive rate.

The full analysis, including a method for auditing any vendor's permission footprint the same way, is in our technical paper on tenant privilege footprints. Ask us for it.