Microsoft Intune Integration

Integration Guide for Microsoft Intune with BluSapphire SIEM

1. Prerequisites

Item	Details
Microsoft Intune tenant	Global Administrator or Intune Service Administrator role, plus access to Diagnostic settings on the Intune resource
Azure AD / Entra ID licensing	Microsoft Intune Plan 1 (or higher) with diagnostic export enabled for the tenant
Event Hub Namespace	Standard tier or higher (Basic tier does not support multiple consumer groups)
Event Hub	Dedicated Event Hub instance for Intune logs (recommended: separate from Activity Log / other workloads)
Shared Access Policy	A policy on the Event Hub with Listen permission for BluSapphire to consume
Consumer Group	Dedicated consumer group created for BluSapphire (avoid using $Default if other consumers exist)

2. Configuration Steps

Step 1 — Create an Event Hub Namespace and Event Hub

1. In the Azure Portal, go to Event Hubs → Create Namespace.

2. Choose Standard tier (minimum) to support multiple consumer groups and higher throughput.

3. Inside the namespace, create an Event Hub (e.g., intune-diagnostic-logs-eh).

4. Create a dedicated Consumer Group (e.g., blusapphire-cg) under this Event Hub.

Step 2 — Create a Shared Access Policy for BluSapphire

1. Navigate to the Event Hub → Shared Access Policies.

2. Create a new policy (e.g., blusapphire-listen) with Listen permission only (principle of least privilege).

3. Copy the Connection String – Primary Key; this will be used in BluSapphire's collector configuration.

Step 3 — Configure Diagnostic Settings in Microsoft Intune

1. Sign in to the Microsoft Intune admin center.

2. Go to Tenant administration → Diagnostic settings → Add diagnostic setting.

3. Name the setting (e.g., intune-to-blusapphire).

4. Select the log categories to stream: AuditLogs, OperationalLogs, DeviceComplianceOrg, IntuneDevices, and Windows365AuditLogs (see Section 6 — recommend enabling all five for full SOC visibility, at minimum AuditLogs and Windows365AuditLogs).

5. Under Destination details, select Stream to an event hub.

6. Choose the Event Hub namespace and Event Hub created in Step 1, and select the appropriate Event Hub policy name.

7. Save the configuration.

Note: Diagnostic settings in Intune are configured per tenant. If you manage multiple tenants (e.g., MSP/multi-tenant scenarios) in scope for SOC monitoring, repeat this for each tenant, or automate via Graph API/PowerShell for consistency at scale.

3. Intune Diagnostic Log Types — Description & SOC Importance

Log Type	What It Contains	SOC Importance	Why
AuditLogs	Records administrative and configuration changes made within Intune — policy create/update/delete, app assignment changes, role/RBAC assignments, Conditional Access-linked compliance policy edits, and who made each change	Critical	This is the primary control-plane trail for Intune. Nearly every high-impact action an attacker or malicious insider could take (disabling a compliance policy, adding a rogue app, changing enrollment restrictions, granting admin roles) is captured here. Essential for detecting unauthorized MDM configuration changes.
Windows365 Audit Logs (If Windows 365 is used)	Audit trail specific to Windows 365 Cloud PC actions — provisioning, deprovisioning, resize, restore, reprovision, and Cloud PC access/configuration changes	Critical	Cloud PC provisioning/deprovisioning and restore operations are high-impact, high-privilege actions with direct access to corporate data. Unauthorized or anomalous Cloud PC lifecycle actions (e.g., unexpected deprovisioning, unauthorized restores) are strong indicators of insider threat or account compromise and should be treated with the same priority as Administrative/AuditLogs activity.
Operational Logs (High in volume)	Operational telemetry for Intune service actions — device enrollment/de-enrollment events, policy deployment/sync results, app installation status, and other day-to-day service operations	High	Surfaces abnormal enrollment activity (e.g., mass enrollment from an unexpected location, repeated failed enrollments) and policy deployment failures that could indicate tampering or a misconfigured/compromised management channel.
Device Compliance Org (High in volume)	Organization-wide device compliance state and evaluation results — which devices are compliant, non-compliant, in grace period, and which compliance policy rules triggered the result	High	Directly reflects device security posture. A sudden shift of devices to non-compliant, or an unusual pattern of devices intentionally being taken out of a compliant state, can indicate endpoint compromise, jailbreak/root attempts, or policy tampering — all high-value SOC signals feeding Conditional Access decisions.
IntuneDevices	Device inventory and state data — device check-in details, device properties, last sync timestamps, ownership and management state	Medium	Primarily contextual/inventory telemetry rather than an active threat signal on its own. Valuable for enrichment (asset context, staleness detection — devices that stop checking in) and for correlating with alerts from other categories rather than for direct real-time alerting.

Priority Summary for SOC Onboarding

1. Must-have (Critical): AuditLogs, Windows365AuditLogs

2. Should-have (High): OperationalLogs, DeviceComplianceOrg

3. Good-to-have (Medium): IntuneDevices — mainly for inventory/enrichment context