Microsoft Entra ID app registration

Every Microsoft connector in CICADA signs in the same way: a tenant ID, a client (application) ID and a client secret, using the client credentials flow. Each source takes its own tenant and client IDs, so you may use one registration for all of them or one per connector. This page lists each permission, the connector that needs it, and what CICADA does with it. It is an App registration in the Entra admin centre, not an entry under Enterprise applications.

Step by step: the app registration

1. In the Microsoft Entra admin centre open App registrations and choose New registration. Give it a name such as CICADA IR. Single tenant. No redirect URI is needed for the connectors (SSO is separate; see single sign-on).
2. From the overview page copy the Application (client) ID and the Directory (tenant) ID. These are the Client ID and Tenant ID fields on every Microsoft source in CICADA.
3. Under Certificates & secrets create a client secret. Copy the value at once; it is shown only then. Note the expiry date.
4. Under API permissions add the Application permissions from the tables below for the connectors you will use. Delegated permissions do not work; the appliance signs in as itself, not as a user.
5. Press Grant admin consent. This needs a Global Administrator or Privileged Role Administrator. Until it is done, CICADA's connection test reports Missing required API permissions. Please grant 'Organization.Read.All' or 'Directory.Read.All' permissions and admin consent. or Access denied: Missing API permissions or admin consent required.
6. In CICADA, open an investigation, go to Sources > Add Source, pick the connector, enter Tenant ID, Client ID and Client Secret, press Test Connection, then Save.

The appliance needs outbound HTTPS to login.microsoftonline.com, graph.microsoft.com, and for Microsoft 365 manage.office.com, for Defender for Endpoint api.securitycenter.microsoft.com. See Network Requirements.

Entra ID (sign-in and audit logs)

Source: Entra ID. Community tier. Token scope https://graph.microsoft.com/.default.

What it reads:

• Sign-in logs: /auditLogs/signIns
• Directory audit logs: /auditLogs/directoryAudits
• Risky sign-ins: /identityProtection/riskySignIns, as recorded by the connector (not yet confirmed against a tenant; see the note under the table)
• The connection test reads /organization
• User, group and device lookups when an analyst or the AI assistant names a target: /users, /users/<id>/registeredDevices, /groups and group members

The risky sign-in endpoint and IdentityRiskyUser.Read.All, and the three write permissions, are the values the connector records in its own code. They have not been confirmed against a tenant. The risky sign-in call matters most: any status other than 200 from it stops the collection, so if your tenant does not serve that endpoint or the permission is wrong, no sign-in or audit log is collected either. Microsoft's Graph reference may name a narrower least-privileged permission for writing a password profile or deleting app role assignments, and a password reset through an application permission can also need a directory role on the service principal. Check Microsoft's reference for each call before granting, and treat a 403 on the first run as the signal that something more is needed.

Response actions through Entra ID

Every response action goes through the approval queue. Approving needs Approve or deny actions and executing needs Execute actions on customer systems. IR lead and Admin have both by default. The AI assistant can only recommend.

Role assignments and group membership (for blast radius)

A second Entra adapter reads /roleManagement/directory/roleAssignments, /directoryRoles, /groups, group members and /servicePrincipals. It asks for RoleManagement.Read.Directory, Directory.Read.All, GroupMember.Read.All and User.Read.All. It is not offered as a source on the Sources page in the current release; grant the permissions now only if you want to be ready for it. Confirm with support before relying on it.

Microsoft 365 (unified audit)

Source: Microsoft 365. Enterprise tier. This connector does not use Microsoft Graph for its audit data. It uses the Office 365 Management Activity API with token scope https://manage.office.com/.default, so the permissions come from the Office 365 Management APIs entry in the API permissions picker, not from Microsoft Graph.

What it reads: it starts a subscription per content type and then lists and downloads the content blobs for your time window. By default it collects Audit.Exchange (mailbox audit), Audit.SharePoint (SharePoint and OneDrive file activity) and Audit.General (Teams and other services). Audit.AzureActiveDirectory is collected only when the source's event types name it. The connection test lists the active subscriptions.

One optional Graph permission: Files.Read.All (Microsoft Graph, Application). The playbook content-sampling step uses it to fetch a bounded sample of a file's bytes from SharePoint or OneDrive to classify its sensitivity. Without it the step records the file as not sampled and carries on.

Microsoft Defender for Endpoint

Source: Microsoft Defender for Endpoint. Community tier. This connector uses two APIs with the same app registration:

• Collection uses Microsoft Graph: alerts from /security/alerts_v2. The connection test reads the same endpoint.
• Device lookups and response actions use the Defender for Endpoint API at api.securitycenter.microsoft.com, with a second token scoped to https://api.securitycenter.microsoft.com/.default: /machines to find a device by name or IP address, then the action endpoints below.

Microsoft Defender for Identity

The connector reads identity alerts from Microsoft Graph /security/alerts_v2 filtered to serviceSource eq 'microsoftDefenderForIdentity', and asks for SecurityAlert.Read.All and SecurityEvents.Read.All (Microsoft Graph, Application). The same two permissions already cover it if you set up Defender for Endpoint. It is not offered as a source on the Sources page in the current release; confirm with support before planning around it.

SharePoint and OneDrive audit

A dedicated SharePoint audit connector reads sites and drives through Microsoft Graph (/sites, /sites/<id>/drives, drive items) and asks for Sites.Read.All and AuditLog.Read.All. It is not offered as a source in the current release. SharePoint and OneDrive file activity is collected today by the Microsoft 365 connector's Audit.SharePoint content type.

Microsoft Purview

Source: Microsoft Purview. Enterprise tier. Fields: Tenant ID, Client ID, Client Secret. Token scope https://graph.microsoft.com/.default.

• DLP alerts: /security/alerts_v2 filtered to alerts whose category contains DataLossPrevention. Permission: SecurityAlert.Read.All.
• The connector records InformationProtectionPolicy.Read for sensitivity label events.
• Access review findings: /identityGovernance/accessReviews/definitions. The connector does not record a permission for this call. Microsoft documents AccessReview.Read.All for it; confirm in your tenant that this is what the call needs before granting it.

Permission checklist

If you set up everything, the app registration ends up with these Application permissions:

• Microsoft Graph: AuditLog.Read.All, Directory.Read.All, IdentityRiskyUser.Read.All, User.Read.All, SecurityAlert.Read.All, SecurityEvents.Read.All; for response actions User.ReadWrite.All, UserAuthenticationMethod.ReadWrite.All, Application.ReadWrite.All; optional Files.Read.All, InformationProtectionPolicy.Read, AccessReview.Read.All (confirm in your tenant).
• Office 365 Management APIs: ActivityFeed.Read, ActivityFeed.ReadDlp.
• WindowsDefenderATP: Machine.Read.All; for response actions Machine.Isolate, Machine.StopAndQuarantine, Machine.Scan, Machine.CollectForensics, Ti.ReadWrite; optional Machine.LiveResponse. Not AdvancedQuery.Read.All: the connector never uses it.
• Then Grant admin consent once.

Grant only what you will use. A read-only deployment needs none of the write permissions; a response action that needs one can still be queued and approved, and fails with a permission error when it is executed.

Next

• Active Directory
• Troubleshooting: Microsoft Entra ID / Defender connection fails
• Back to the onboarding overview