Configuring the connectors
One Entra ID application, read-only, drives the whole audit. Configure it once, then verify each service with a real connection test before enabling it.
The Entra connector first
Automatic provisioning is the recommended path: an interactive sign-in with a Global Administrator, and EntraGUARD creates the application registration, generates a self-signed certificate stored locally, grants the read-only Graph permissions with admin consent, and records tenant ID, client ID and thumbprint. You authenticate once; every audit after that runs non-interactively. If your organisation registers applications centrally, point the connector at an existing app instead (tenant ID, client ID, certificate or client secret).
Every permission is .Read.All. Directory.Read.All, Policy.Read.All, RoleManagement.Read.All, Reports.Read.All, AuditLog.Read.All and a few service read scopes — plus Exchange.ManageAsApp for Exchange Online. No write scope is ever requested.
Exchange and Purview ride on the same certificate
The Exchange Online and Purview connectors reuse the Entra application and its certificate — no extra registration, nothing to generate. The Entra provisioning already attaches the Exchange certificate and roles; note that Exchange Online requires certificate authentication (a client secret is not accepted).
Test before you enable
Each service connector — SharePoint, OneDrive, Teams, Intune, Defender, Exchange, Purview — has a Test connection button that performs a real read call against the service. A connector can only be enabled after its test passes; a failed test disables and locks it until a test succeeds. Access errors are translated: the message names the exact missing Graph permission, or tells you the service is not licensed on the tenant (a classic with Intune on dev tenants).
The cycle is always the same: configure Entra → test the service → enable it. Nothing activates on its own, so what is enabled is exactly what has been proven to work.