Intune change events to a webhook

What does the native log export provide?

Microsoft supports routing Intune audit logs to Azure Monitor. That is an option when you want a native log-export pipeline. Decide whether your integration needs that broader source or the selected notification events delivered by a TenuVault alert before designing a receiver.

A webhook notification is an operational message with a defined event shape. It is not a full audit archive or a complete policy snapshot. Keep retention and investigation requirements separate from alert delivery, and retain configuration backups when recovery or exact setting comparisons are part of the intended workflow.

How do I send Intune change events to a webhook?

1. Prepare a public HTTPS receiver controlled by your organization. TenuVault refuses localhost and private network addresses as written. Use an ingestion endpoint that can authenticate requests and map fields into your own event pipeline.

2. In Alerts, Channels, add a Webhook destination. Configure a static secret header or request signing as appropriate for the receiver. Notifications require Pro. Keep the destination URL and secrets in the intended configuration stores rather than copying them into incident notes.

3. Add an Intune change alert, choose the webhook channel and enable Intune change watching. Start with a narrow approved policy scope. Review the interval and test the receiver before connecting automated downstream actions.

Which JSON fields should my receiver read?

The body is one event object with schema set to tenuvault.notification/v1. An Intune change uses type intune.change. Read the eventId for delivery deduplication and items[].change for machine-readable change details rather than parsing the human title or detail text.

Each change carries auditId, changeType, category, resourceName, resourceType and settings, plus resourceId when the audit event has one. The item’s at field records its event time. A collapsed group can include count, and settingsMore counts setting names beyond those shown. Treat absent optional fields as absent, not as an ingestion failure.

For example, an updated compliance policy can have changeType updated and settings containing PasswordRequired. Those are setting names, not the policy’s values. Creates, deletes and assignment operations name no changed settings, and Settings Catalog updates also lack setting names from the audit event.

How do I authenticate and deduplicate deliveries?

Request signing adds X-TenuVault-Timestamp in Unix seconds and X-TenuVault-Signature with the hex HMAC-SHA256 of timestamp, a period, and the raw body, keyed with your secret. Verify the signature against the exact received bytes before transforming JSON. Apply an appropriate timestamp acceptance policy in your receiver.

X-TenuVault-Event-Id repeats the body eventId. Delivery is at least once, so store that key and suppress duplicates in your downstream processing. Inspect Deliveries, View to compare the stored webhook JSON with your mapping. A failed delivery can retry with backoff and survive an app restart.

How can I try this on my tenant?

Download TenuVault and send a test alert to the receiver. Check signature verification, field mapping and duplicate handling before admitting the event into the production SIEM stream. Then make an approved edit to a test policy and confirm that the next poll produces the expected change type and resource identity.

The payload includes names, IDs, counts, timestamps and setting names. It excludes policy content, setting values, credentials and audit request bodies. Plan the receiver around that boundary. For exact before-and-after values, use a change report rather than trying to reconstruct them from a notification.

• Webhook and other alert channels
• Investigate an Intune change
• Understand saved configuration versions
• Microsoft native audit-log routing
• Download TenuVault