Getting Intune logs into Sentinel — there's no connector

Bringing Intune into the SIEM is one of the highest-value, lowest-glamour integrations you can do: once device-compliance state and configuration changes sit next to your identity and email telemetry, you can finally answer questions that span the seam — "did this account compromise happen before or after the device fell out of compliance?" — in one query. The only thing standing in the way is that the setup doesn't look like every other Sentinel source.

01The method: Diagnostic Settings, not a connector

Intune admin center → Reports → Diagnostic settings → Add. Pick the log categories, point them at the Log Analytics workspace that has Sentinel enabled.

In the Intune admin center, go to Reports → Diagnostic settings → + Add diagnostic setting. Under Logs, select the categories you want — AuditLogs, OperationalLogs, DeviceComplianceOrg, and Devices are the core four (newer optional categories like Windows365AuditLogs show up here too). Under Destination details, choose Send to Log Analytics workspace and select the workspace your Sentinel instance sits on. Save.

02The four tables, and what each is for

Selecting all four categories streams four tables into the workspace. Know which one answers which question before you write a rule.

Table	Holds	Hunt it for
IntuneAuditLogs	Admin actions — Create, Delete, Patch, assignments — on Intune configuration	Who changed a policy, and when (out-of-hours config drift)
IntuneOperationalLogs	Enrollment success/failure and non-compliant-device detail, with user context	Enrollment-failure spikes; devices going non-compliant
IntuneDeviceComplianceOrg	The organisational compliance report — state per device	Posture drift across the fleet by state and OS
IntuneDevices	Device inventory — the managed-estate snapshot	Enrichment; "which devices does this user actually have?"

03The cost decision hiding in "all four"

Those four tables land in the Analytics tier — the priciest one. For a chatty source, "select all categories" is also "opt into the premium meter for all of it."

This is where the data-foundation piece pays off. IntuneAuditLogs is genuinely detection-driving — config changes are exactly what you want hot, in Analytics, feeding rules. But IntuneDevices and the operational/compliance tables are higher-volume, mostly-forensic inventory you'll query occasionally, not alert on every minute. That's the classic split: keep audit hot, and for the verbose inventory tables consider a cheaper table plan (Basic/Auxiliary) or routing the bulk to the lake, so you're not paying Analytics rates to store a device inventory you read once a week.

04The gotchas that cost an afternoon

None of these are in the happy-path docs, and all of them have burned someone.

• No backfill — ever. Diagnostic settings only capture data going forward. There's no historical import, so the day you wish you'd had Intune logs is the day you find out you turned it on too late. Enable it before you need it, on every tenant, as baseline hygiene.
• Roles are split. You need Intune Administrator to create the diagnostic setting and Log Analytics Contributor on the workspace to write to it — two different grants, and missing the second fails quietly.
• Right workspace, not just any workspace. Point it at the Log Analytics workspace that actually has Sentinel enabled. Sending to a bare workspace gets you tables with no SIEM on top.
• Schemas drift. The Intune table columns aren't perfectly stable across tenants and OS mixes — verify field names in your workspace before you harden a rule around them.

05What to do with it once it's flowing

The payoff is correlation. A few starting hunts — the full set lives in the library.

The first hunt most teams want is configuration change outside business hours — the quiet window to weaken a compliance policy:

IntuneAuditLogs
| where TimeGenerated > ago(7d)
| extend Hour = datetime_part("hour", TimeGenerated)
| where Hour >= 20 or Hour < 7
| where OperationName has_any ("Create","Delete","Patch")
| project TimeGenerated, OperationName, Identity
| sort by TimeGenerated desc

And posture drift — a rise in non-compliant devices, which can be a broken policy or tampering:

IntuneDeviceComplianceOrg
| where TimeGenerated > ago(1d)
| where ComplianceState != "Compliant"
| summarize Devices = dcount(DeviceId) by ComplianceState, OS
| sort by Devices desc

These two live in the KQL Library alongside the identity, email, and endpoint hunts — and the real value is joining them: an Intune config change correlated against the sign-in and mailbox activity of the actor who made it, in one timeline.