Microsoft Graph Security API Response Integration via API

Purpose

This guide explains how to connect Microsoft Graph Security API to Logsign as a Response integration, so an analyst can look up and triage Microsoft Graph security alerts, and look up Microsoft Entra ID (Azure AD) user records, directly from a Logsign Incident. This is a query/action integration, not a log collection poller: it does not pull alerts into Logsign on a schedule. It only runs when an analyst calls one of its methods from Settings > Integrations > Responses > +Device.

Do not confuse this with the separate Azure Graph Security data collection (poller) integration, which ingests alerts as Logsign events on a schedule and is configured under Settings > Integrations > Data Collection. The two use the same underlying Microsoft Graph Security alert data, but they are configured in different places, use different credentials entries, and this Response integration additionally exposes Microsoft Entra ID user lookups that the poller does not.

Alerts API version: the alert methods in this integration (list-alerts, get-alert, update-alert) call Microsoft's /security/alerts_v2 endpoint. Microsoft retired the legacy /security/alerts endpoint on October 15, 2026, and it no longer returns usable data. Older Logsign versions still call the legacy endpoint, so their alert methods fail or return no alerts. Contact Logsign Support to confirm that your version includes the alerts_v2 update. The alerts_v2 resource has a different set of properties and different update fields than the legacy one; the method sections below describe the current behavior.

Prerequisites

You need a Microsoft Entra ID (Azure AD) tenant and permission to register an application and grant admin consent to it (Cloud Application Administrator or Global Administrator, or an equivalent custom role; see Step 1). You also need to know which of the five methods below you actually plan to use, because the Graph application permissions differ between the alert methods and the user methods, and Microsoft's own guidance is to grant only what a specific method needs.

This integration authenticates entirely with the OAuth 2.0 client credentials grant (an application identity, not a signed-in user), against the global Microsoft cloud only. It does not support delegated (signed-in user) authentication, and it is hardcoded to call https://login.microsoftonline.com for the token and https://graph.microsoft.com/v1.0 for the API itself. If your organization operates in a Microsoft national cloud (US Government GCC High/DoD, or the China cloud operated by 21Vianet), this integration will not work: those clouds use different login and Graph endpoints entirely (for example login.microsoftonline.us and graph.microsoft.us for US Government), and this integration has no field to change them. This was confirmed by reading the integration's source code, not by testing against a national cloud tenant.

Step 1: Register an Azure AD application with least-privilege Graph permissions

Do not reuse an application that already holds broad Microsoft Graph permissions for something else. Register a dedicated application for this integration so its permission grant stays auditable and minimal.

1. Sign in to the Azure Portal (or the Microsoft Entra admin center) with an account that can register applications. Registering the application itself does not require a tenant admin.
2. Go to Microsoft Entra ID > App registrations > New registration. Give it a descriptive name, for example "Logsign Graph Security Response", leave the default single-tenant account type unless your organization specifically needs otherwise, and click Register.
3. On the application's Overview page, copy and securely store the Application (client) ID and the Directory (tenant) ID. You will enter both in Logsign in Step 2.
4. Go to Certificates & secrets > Client secrets > New client secret. Give it a description and an expiration period, then click Add. Copy the secret's Value immediately; Azure only displays it once. Set a calendar reminder before the expiration date, since an expired secret fails authentication with no advance warning from Logsign.
5. Go to API permissions > Add a permission > Microsoft Graph > Application permissions, and add only the permissions for the methods you plan to use, from the table below. Application permissions (not delegated) are required because this integration authenticates as the app itself, with no signed-in user.

After adding the permissions, click Grant admin consent for <your tenant>. This step requires a Global Administrator, Privileged Role Administrator, or Cloud Application Administrator; a user without one of those roles can add the permission requests but cannot approve them. Application permissions are inert until admin consent is granted, so skipping this step is the most common reason this integration authenticates (gets a token) but then fails every actual API call with a 403.

If you set up this integration before the alerts_v2 update, the app registration probably holds only SecurityEvents.Read.All or SecurityEvents.ReadWrite.All. Add the matching SecurityAlert permission from the table above and grant admin consent again, otherwise the alert methods fail with 403.

Step 2: Configure the integration in Logsign

In Logsign, go to Settings > Integrations > Responses, search for Microsoft Graph Security API, click Configure, then +Device.

There is no Base URL or Scope field on this integration, and that is intentional, not a missing field. Both values are fixed in the integration's code rather than left for you to fill in:

• Base URL is always https://graph.microsoft.com/v1.0, the Microsoft Graph global commercial cloud endpoint. There is no regional or per-tenant variation to configure for Microsoft Graph the way there is for some other cloud APIs; every commercial-cloud tenant is reached through this same host. The only situation where this matters is the national cloud limitation described under Prerequisites: because the host is hardcoded, tenants in US Government or China clouds cannot use this integration at all, regardless of what credentials they enter.
• Scope is always https://graph.microsoft.com/.default. In the OAuth 2.0 client credentials flow, .default is not a single permission, it is a shorthand meaning "request a token for whatever application permissions have already been granted admin consent on this app registration." In practice this means the actual access your Logsign integration gets is entirely determined by which permissions you added and consented to in Step 1, not by anything you configure in Logsign. If a call fails with 403 Forbidden, the fix is almost always back in the Azure Portal (add the missing permission and grant consent again), not in this Scope value, because there is no Scope field to change.

For comparison, some other Microsoft Graph-based Response integrations in Logsign, such as Microsoft Entra ID Response Integration, do expose a visible Scope field where you paste in the same fixed value manually. This integration does not; the equivalent value is simply built into the code. Functionally the two approaches end up requesting the same kind of token, an application-only token scoped to whatever was admin-consented, this integration just does not surface that as an editable field.

Save the device, then use Test to confirm the integration can obtain an access token from login.microsoftonline.com with the credentials entered. Based on a review of the integration's code, the test call only exercises the token request; it does not call a real Graph endpoint such as /security/alerts_v2 or /users, so a successful test confirms your Tenant ID, Client ID and Client Secret are valid together, but does not confirm that the app has been granted (and consented to) the specific permission a given method needs. Run an actual method, for example list-alerts or list-users, after saving to confirm permissions end to end. This was not independently verified against a live Logsign UI for this guide.

Separately, the integration's underlying configuration structure includes an optional proxy URL field in the Go source code, but that field is not declared in the current asset manifest that drives the Logsign UI form. In practice this means there is currently no way to set an outbound proxy for this integration from the standard configuration screen, even though the code has a code path that would use one if it were populated. Flag this to Logsign support if your environment requires the integration to call Microsoft Graph through a proxy.

Available Methods

Every method below is invoked from within an Incident's Responses panel by selecting the configured Microsoft Graph Security API device and the method name.

list-alerts

Lists Microsoft Graph security alerts (aggregated across connected Microsoft security products such as Microsoft Defender for Endpoint, Microsoft Defender for Cloud Apps, Microsoft Entra ID Protection and Microsoft Sentinel) via GET /security/alerts_v2. Requires application permission SecurityAlert.Read.All (or SecurityAlert.ReadWrite.All, which also covers this). Each returned alert uses the alerts_v2 property names, for example tenantId, actorDisplayName, classification, determination and resolvedDateTime, instead of the legacy azureTenantId, activityGroupName and closedDateTime. Update any playbook that reads the legacy property names.

get-alert

Retrieves a single alert by ID via GET /security/alerts_v2/{alertId}. Requires application permission SecurityAlert.Read.All (or SecurityAlert.ReadWrite.All).

update-alert

Updates editable properties on an existing alert (assignment, status, classification and determination) via PATCH /security/alerts_v2/{alertId}. Requires application permission SecurityAlert.ReadWrite.All.

The legacy update fields closed_date_time, comments, feedback, tags, vendor_provider, vendor_provider_version, vendor_sub_provider and vendor_name have no equivalent on alerts_v2. If a playbook still sends a non-empty value for any of them, the integration does not call Microsoft and returns an error such as update-alert: "feedback" is not supported by alerts_v2; use status, classification, determination or assigned_to. Remove these fields from the playbook and use the fields in the table above.

list-users

Lists Microsoft Entra ID user objects via GET /users. Requires application permission User.Read.All.

get-user

Retrieves a single user by ID or userPrincipalName via GET /users/{id}. Requires application permission User.Read.All.

Notes and Limits

• This is a query/action integration, not a log collector. It does not ingest Graph Security alerts or Entra ID user data into Logsign's event store on its own; each call returns data only for the specific request an analyst makes at that moment.
• The alert methods (list-alerts, get-alert, update-alert) use Microsoft's alerts_v2 API. Microsoft retired the legacy alerts API on October 15, 2026. Playbooks built against the legacy API must use the alerts_v2 property names and update fields described above.
• Throttling: Microsoft Graph enforces service-specific and tenant-level rate limits and returns HTTP 429 Too Many Requests with a Retry-After header (in seconds) when exceeded. Based on a review of the integration's code, it does not read or honor the Retry-After header and does not retry automatically; a throttled call simply returns as a failed response to Logsign. If you run a high volume of calls (for example, bulk alert lookups from a playbook loop), build a delay into the playbook itself rather than relying on this integration to back off automatically. Microsoft's exact numeric limits for the Security API and for /users are not published as fixed per-minute figures and can vary by tenant and licensing; this was not independently load-tested for this guide.
• Authentication is entirely OAuth 2.0 client credentials against the Microsoft global commercial cloud. There is no support for delegated (signed-in user) auth, and no support for Microsoft national clouds (US Government, China), because both the token endpoint and the Graph base URL are hardcoded in the integration.
• The client secret has an expiration date you set in Azure. This integration has no mechanism to warn you before it expires; an expired secret fails every call with an authentication error until you generate a new secret in Azure and update the Client Secret field in Logsign.
• A proxy URL field exists in the integration's underlying configuration structure but is not exposed in the current asset manifest, so it cannot currently be set from the standard Logsign configuration screen. See Step 2.

Troubleshooting