Intune Diagnostics, Reporting & Audit Evidence

Why Intune diagnostics for CMMC

Intune's portal shows you current state — which devices are compliant right now, which app deployments succeeded today, which configuration profiles errored on a given device. For day-to-day operations that's enough. For a CMMC L2 assessment it isn't, because three control families ask questions the portal can't answer on demand:

• AU.L2-3.3.1 / 3.3.2 — Create and retain audit records; ensure actions of individual users can be uniquely traced. "Show me every administrative change to device policy in the last 90 days, who made it, and what the prior values were." The in-product audit log retains 1 year but is neither queryable nor exportable as an audit artifact — an assessor wants a KQL result set or CSV, not a screenshot of a paginated portal grid.
• CM.L2-3.4.1 / 3.4.2 — Establish and maintain baseline configurations. "Demonstrate the baseline is enforced on each device, and show me the drift signal when it isn't." The Devices > Monitor blade shows current compliance state; it does not show the timeline of when a device fell out of compliance, why, and when it returned. IntuneDeviceComplianceOrg does.
• IR.L2-3.6.2 — Report incidents to designated officials and authorities. "What's your operational alerting mechanism when a privileged Intune role gets assigned out of process?" "We watch the portal" is not an answer; "we have a scheduled query rule firing on this KQL signature against IntuneAuditLogs, with these escalation targets" is.

The Intune admin center retains data on the timescales Microsoft's product groups optimized for, not on the timescales an assessor needs. The diagnostic-settings export below is the mechanism that flips that — once Intune logs land in Log Analytics, every audit, compliance, and incident question above answers in KQL, with retention and alerting under your control rather than Microsoft's product defaults.

What an assessor asks

"Show me a query that lists every device that fell out of compliance in the last 30 days, the reason code, and time-to-return-to-compliant." If your environment has the diagnostic export below configured, this is a five-line KQL query against IntuneDeviceComplianceOrg and the answer ships in a screenshot. If it doesn't, the answer is "let me reconstruct that from helpdesk tickets" — a finding waiting to happen.

GCC-High mechanics

Diagnostic settings work identically in GCC High once the Log Analytics workspace is in an Azure Government region (USGov Virginia or USGov Texas). The Intune admin center is at intune.microsoft.us; the Azure portal is portal.azure.us. The category list (AuditLogs, OperationalLogs, DeviceComplianceOrg, Devices) is identical to commercial. The trap worth flagging: targeting a commercial Log Analytics workspace from a GCC High Intune tenant appears to save the diagnostic setting without error and no data flows. Verify the destination workspace is in Azure Government — not just any Azure subscription the admin happens to have access to — before assuming silence means success.

Reporting and Monitoring Setup

The Intune admin center has built-in reports and dashboards that meet most day-to-day operational needs, but two gaps matter once an environment has more than ~50 devices: retention (the in-portal audit log is 1 year, operational telemetry is shorter) and alerting (the portal does not natively notify you when something goes wrong — it shows state on demand). Both gaps close by exporting Intune diagnostic data to a Log Analytics workspace and configuring alert rules against it. The setup below is the proactive monitoring side; reactive troubleshooting is in Policy Troubleshooting, and turning the same data into auditor-ready evidence packages is later in the chapter.

Diagnostic Settings — Full Export to Log Analytics

The Intune admin center exposes a Diagnostic Settings page that sends Intune logs to Log Analytics, Event Hub, or Azure Storage. Most organizations need only Log Analytics — that's where KQL queries and alert rules live.

Path: Intune admin center → Reports → Diagnostic settings → Add diagnostic setting.

Category	Contents	Why export
AuditLogs	Every administrative action (Create / Update / Delete on policies, apps, role assignments, device wipes) with admin UPN, target object, and result	Tier-1 governance — who changed what, when; primary source for "policy modified outside change window" alerts
OperationalLogs	Enrollment events, policy assignment events, device check-in results, app deployment events, certificate connector events	Operational dashboards and alerts — failure rates, enrollment health, app rollout status
DeviceComplianceOrg	Per-device compliance state changes over time (Compliant ↔ Noncompliant transitions with reasons)	Compliance-trend reporting and alerting — the per-device timeline the portal does not retain in queryable form
Devices	Device inventory snapshots (enrolled, retired, pending) with hardware and OS metadata	Inventory reconciliation — match Intune-known devices against authoritative sources (HRIS, asset management)

Export all four. The cost difference between subset and full is a few dollars per month at small-to-mid scale; the cost of missing a log when you need it is a 30-day investigation gap.

Workspace placement: for a small-to-mid IT shop without a dedicated SOC, an Intune-dedicated Log Analytics workspace is the cleaner fit — Central IT owns it, secondary teams (Helpdesk, Mobile Admins) get scoped reader access, and there's no Entra/Defender data overlap to manage RBAC for. Organizations with a Sentinel-tier SOC use a shared workspace and rely on Sentinel's RBAC for cross-source isolation.

Without Sentinel, Log Analytics alerts ARE your alerting infrastructure

For commercial customers without Microsoft Sentinel, Log Analytics workspaces support scheduled query alert rules with email, Teams webhook, and Logic Apps action destinations. This is the durable Intune alerting path — no Sentinel license required. Same KQL works later if Sentinel is adopted (see the alert patterns below).

Endpoint Analytics

Endpoint Analytics produces signal-rich operational telemetry the audit logs do not: device startup time, application reliability, work-from-anywhere connectivity health, and recommended hardware refresh signals derived from real performance data.

Enable: Intune admin center → Reports → Endpoint analytics → Start. Then opt every device collection in Settings → Data collection.

Signal	What it measures	Operational use
Startup performance	Boot + sign-in time, percentile distribution per population	Identify slow devices; correlate with hardware refresh decisions
Application reliability	App crash and hang counts, top offending apps per population	Surface a misbehaving app before helpdesk tickets pile up
Work-from-anywhere	Cloud-management readiness, Entra Join status, Autopilot enrollment readiness, M365 Apps readiness	Identifies devices whose modernization migration is incomplete
Recommended software	Outdated drivers and BIOS by manufacturer	Patch and BIOS update planning
Anomaly detection	Sudden change in startup time, crash rate, or sign-in failure rate against the rolling baseline	Early warning for a botched policy rollout or driver update

Baseline configuration: Reports → Endpoint analytics → Baselines. Compare against either the organizational median (your own population over time) or the industry median (Microsoft's anonymized cross-tenant baseline). Most organizations start with industry, then flip to organizational once a stable internal baseline exists (~30–60 days of data).

Per-scope baselines for specialized populations

A 24/7 dispatch terminal runs very different workload patterns than an office workstation — no idle hours, dispatch software always foreground, different reboot cadence. Endpoint Analytics baselines are scoped by Entra group, so create separate baselines per population (Public Safety, Standard, Kiosk, VDI) rather than a single tenant-wide baseline; one population's noise will mask another's signal otherwise.

Licensing: most features are included in Intune Plan 1 (E3-equivalent). Application Reliability for in-tenant LOB apps and the Anomaly Detection module require Intune Plan 2 or the Intune Suite — verify Plan 2 status before assuming the advanced features are available.

Reports Center

The Reports center consolidates the operational and organizational reports otherwise scattered across Intune blades. The two report families behave differently:

Type	Refresh	Format	Examples
Operational reports	Real-time, last 30 days	In-portal view + CSV export on demand	Device compliance, App protection status, Apps install status, Discovered apps, Feature update report
Organizational reports	Daily snapshot, historical	In-portal view + CSV export, some support email subscription	Device inventory, Compliance trends, App inventory

Path: Intune admin center → Reports → [Operational reports | Organizational reports].

Email subscriptions (where supported): the report's main page → Subscriptions tab → Create subscription. Currently supported on a subset of organizational reports — the list grows as Microsoft promotes more reports out of preview. Subscription emails are sent from the tenant's default Microsoft sender; check inbound spam filtering before relying on them.

Operational Dashboard — Devices > Monitor

For day-to-day operational visibility, Devices → Monitor is the canonical dashboard. It surfaces real-time signal across the categories that drive helpdesk tickets:

Tile	Watch for
Configuration profile assignment status	Profiles with elevated error rates — sign of a recent change that didn't land cleanly
Compliance policy assignment status	Sudden compliance regression — common cause: a Conditional Access change broke an attestation
Software updates	Update ring lag (devices stuck > N days behind), iOS/Android version distribution
Discovered apps	New apps appearing in the inventory that aren't in the catalog — shadow installations
Threat agent status	MDE agent rollup — devices showing Inactive or with elevated risk levels

Pin this blade as a browser bookmark for the Helpdesk lead — the per-tile drill-down is the fastest path from an alert symptom to the affected device list.

Role-Based Monitoring

Each admin team should have a different daily-monitoring routine matched to their scope. Pin these as browser bookmarks for the team lead:

Team	Pin / Watch	Source
Tier 1 / Central IT	Audit log filtered to admin-modify events; tenant-wide compliance trend; license usage; app deployment health rollup	Audit logs (KQL); Reports > Compliance trends; Tenant administration > Tenant status
Helpdesk	Troubleshoot + support blade (per-user device + policy view); per-device check-in age (filter for LastSyncDateTime > 7d ago); Devices > Monitor > Compliance noncompliant view	Tenant administration > Troubleshoot + support; Devices filters; Devices > Monitor
Mobile Admins	iOS/Android device-state filter; Apple/Android Enrollment health (Apple > Enrollment program tokens, Android > Managed Google Play sync status); App protection wipe history	Devices > [filter by OS]; Devices > Enrollment > [Apple/Android]; Apps > App protection policies > Reports

The diagnostic-settings export earlier feeds the KQL queries used for custom dashboards and alerts. See Intune RBAC & Governance for the role boundaries that scope each team's view.

Intune-Native Alerting Patterns (Log Analytics-based)

Once Intune logs are flowing into Log Analytics, alert rules run directly against the workspace. No Sentinel is required.

Path: Log Analytics workspace → Alerts → Create → Alert rule. Each alert below is the rule logic; configure evaluation frequency and threshold per the organization's tolerance.

Alert 1 — Compliance regression. Fires when a previously-compliant device transitions to noncompliant. The join distinguishes a real regression from a newly-enrolled device that has not yet evaluated.

IntuneDeviceComplianceOrg
| where TimeGenerated > ago(1h)
| where ComplianceState_s == "noncompliant"
| join kind=inner (
    IntuneDeviceComplianceOrg
    | where TimeGenerated between (ago(7d) .. ago(1h))
    | where ComplianceState_s == "compliant"
    | summarize PriorCompliantTime = max(TimeGenerated) by DeviceId_g
) on DeviceId_g
| project TimeGenerated, DeviceName_s, UserPrincipalName_s, ComplianceState_s, PriorCompliantTime
| order by TimeGenerated desc

Alert 2 — Configuration profile failure rate. Fires when a config profile's error rate across its assigned devices exceeds 5% — typical signal of a change that broke a population.

IntuneOperationalLogs
| where TimeGenerated > ago(15m)
| where Category == "DeviceConfiguration"
| extend Result = tostring(Properties.ResultStatus)
| summarize Total = count(), Errors = countif(Result == "Error") by ProfileName_s
| extend ErrorRate = todouble(Errors) / todouble(Total)
| where Total > 10 and ErrorRate > 0.05
| order by ErrorRate desc

Alert 3 — Privileged action by non-Tier 1 admin. Fires when an admin outside the Tier 1 group performs a Create, Update, or Delete on a policy, role, or scope tag.

let Tier1Admins = dynamic([
    "alice.admin@contoso.com",
    "bob.admin@contoso.com"
]);
IntuneAuditLogs
| where TimeGenerated > ago(15m)
| where OperationName has_any ("Create", "Update", "Delete", "Patch")
| where Category in ("DeviceConfiguration", "DeviceCompliance", "Role", "ScopeTag")
| where Identity !in (Tier1Admins)
| project TimeGenerated, Identity, OperationName, Category, ResourceId
| order by TimeGenerated desc

Alert 4 — Policy modified outside change window. Fires when an admin modifies a policy outside business hours. Adjust the Eastern Time offset and weekday range to match the organization's change window.

IntuneAuditLogs
| where TimeGenerated > ago(15m)
| where OperationName has_any ("Update", "Delete", "Patch")
| where Category in ("DeviceConfiguration", "DeviceCompliance")
| extend ETHour = datetime_part("Hour", datetime_add('hour', -5, TimeGenerated))
| extend ETDay = dayofweek(datetime_add('hour', -5, TimeGenerated))
| where ETDay == 0d or ETDay == 6d
    or ETHour < 9 or ETHour >= 17
| project TimeGenerated, Identity, OperationName, ResourceId
| order by TimeGenerated desc

Alert 5 — App deployment failure spike. Fires when an app's install failure rate against a target population exceeds 10% over a 1-hour window.

IntuneOperationalLogs
| where TimeGenerated > ago(1h)
| where Category == "Apps"
| extend Result = tostring(Properties.InstallResult)
| summarize Total = count(), Failures = countif(Result == "Failed") by AppName_s
| extend FailureRate = todouble(Failures) / todouble(Total)
| where Total > 20 and FailureRate > 0.10
| order by FailureRate desc

Same KQL works in Microsoft Sentinel

The five queries above execute in Microsoft Sentinel without modification — Sentinel reads from the same Log Analytics workspace. The only difference is rule type: Log Analytics calls them scheduled query rules, Sentinel calls them analytics rules, but the KQL body is identical and the action group / playbook hookup is the same. Adopting Sentinel later requires no rule rewrites.

Alert action groups: appropriate options are email (Helpdesk and Tier-1 distribution lists), Teams webhook (a dedicated #intune-alerts channel), or Logic Apps (for ticket creation in ServiceNow if the connector is configured). Reserve full PagerDuty / on-call paging for security-incident-grade signals — the alerts above are operational.

Microsoft Tunnel Gateway Monitoring

If Microsoft Tunnel is deployed for iOS/Android VPN, server health, session counts, and failed-authentication rate become operational signals worth monitoring. Skip this section if Tunnel is not in use.

Health dashboard: Intune admin center → Tenant administration → Microsoft Tunnel Gateway → [server] → Status.

KQL for failed-auth spike (against the Log Analytics workspace receiving Tunnel diagnostic data):

IntuneTunnelGatewayLogs
| where TimeGenerated > ago(15m)
| where AuthenticationResult_s == "Failed"
| summarize FailureCount = count() by UserPrincipalName_s, ServerName_s
| where FailureCount > 5

---

Policy Troubleshooting

Policy Delivery and Check-In

Intune policies push to devices on check-in, which occurs approximately every 8 hours. A check-in can also be triggered manually without waiting for the scheduled interval.

Force a check-in on device: Settings → Accounts → Work or school → Info → Sync

Force a check-in from Intune portal: Devices → [Device] → Sync

Check-in status is visible per profile at: Devices → [Device] → Device configuration. Each profile listed shows its assignment status — Succeeded, Pending, Error, or Conflict.

Diagnosing Policy Conflicts

A policy conflict occurs when two policies configure the same setting with different values. Intune reports the setting as "Conflict" and does not apply either value — the setting is effectively unmanaged until the conflict is resolved.

Finding conflicts:

1. Navigate to Devices → [Device] → Device configuration
2. Filter the profile list by "Conflict" status
3. Drill into the conflicting profile to identify which specific setting is in conflict

Resolution: Determine which policy should own the setting and remove or reconcile the conflicting setting from the other policy. For settings managed by Security Baselines, note that baseline settings take precedence — a custom profile that overlaps with a baseline will frequently conflict.

Filter Troubleshooting

Assignment filters allow targeting based on device properties (OS version, manufacturer, Entra group membership) without creating additional groups. A filter that evaluates to false silently skips policy assignment — this is one of the most common causes of a policy not applying despite correct group membership.

Testing a filter: Tenant administration → Filters → [Filter] → Device preview — enter a specific device to see whether it matches the filter criteria and why.

MDM Diagnostic Report

The MDM Diagnostic Report is a full snapshot of all policies applied to a specific Windows device, generated on the device itself.

Generate on device: Settings → Accounts → Access work or school → [Account] → Info → Create report

This produces a ZIP file at %TEMP%\MDMDiagReport containing:

File	Contents
MDMDiagReport.xml	All MDM policies applied, their values, and error codes
MDMDiagHtmlReport.html	Human-readable summary of enrollment status, configuration policies, compliance results, certificate profiles, Wi-Fi and VPN profiles
DeviceEnrollment.log	Enrollment events and errors

The HTML report is the fastest way to confirm what policies are applied and whether any returned errors. Share this file with the help desk or use it during remote troubleshooting sessions.

Remote Log Collection

For devices that cannot be physically accessed, Intune supports remote diagnostic log collection without user involvement.

Trigger from portal: Devices → [Device] → Collect diagnostics (Windows)

This instructs the device to collect and upload a log bundle to Intune. Logs are available for download from the portal within 15–30 minutes.

Collected logs include:

• Windows event logs: System, Application, Security, MDM
• Registry exports for common MDM keys
• Scheduled task status
• Installed applications list

Use remote log collection when investigating a policy failure or enrollment issue on a device at a remote site.

---

Intune Audit Log

The Intune audit log records all administrative actions taken in the Intune portal or via API — policy creation, modification, deletion, device wipes, compliance policy changes, and app assignments.

Access: Tenant administration → Audit logs

Key fields per entry:

Field	Description
Date	Timestamp (UTC)
Initiated by	UPN of the admin who performed the action
Activity	Action type (e.g., Create, Update, Delete, DeviceWipe)
Target resource	Policy name, device name, or app name
Result	Success or Failure

Retention: Intune audit logs are retained for 1 year by default. For longer retention, export to Azure Monitor Log Analytics or Azure Storage via Diagnostic Settings.

Export to Log Analytics:

In the Azure portal: Intune → Diagnostic settings → Add diagnostic setting → select AuditLogs and OperationalLogs → route to a Log Analytics workspace.

GCC High (CMMC)

For GCC High, route diagnostic logs to a Log Analytics workspace in Azure Government. The ingestion endpoint uses the *.ods.opinsights.azure.us domain. Confirm your Log Analytics workspace is deployed in an Azure Government region (USGov Virginia or USGov Texas) before configuring the diagnostic setting.

Commercial

For commercial tenants, route diagnostic logs to any Log Analytics workspace in the standard Azure regions. The ingestion endpoint uses the *.ods.opinsights.azure.com domain.

---

Device Compliance Audit Evidence

Compliance policy results are per-device, per-policy, and time-stamped. This is the primary evidence source for demonstrating that managed devices meet configuration baselines.

Access: Devices → Monitor → Device compliance — provides an overview and supports per-policy drill-down.

Exporting compliance state:

# Using Microsoft Graph — works for both commercial and GCC High with the appropriate environment parameter

# GCC High
Connect-MgGraph -Scopes "DeviceManagementManagedDevices.Read.All" -Environment USGov

# Commercial
# Connect-MgGraph -Scopes "DeviceManagementManagedDevices.Read.All"

$devices = Get-MgDeviceManagementManagedDevice -All
$devices | Select-Object DeviceName, ComplianceState, LastSyncDateTime, OperatingSystem, OSVersion |
    Export-Csv -Path ".\DeviceCompliance_$(Get-Date -Format 'yyyy-MM-dd').csv" -NoTypeInformation

Per-device compliance evidence: Devices → [Device] → Device compliance — lists every compliance policy assigned to the device and each policy's result: Compliant, Noncompliant, or Not applicable. This per-device view is the configuration evidence an auditor typically requests.

---

Configuration Profile Evidence

Configuration profiles define the security baseline applied to each device. Profile assignment status and compliance state constitute evidence that security controls are enforced.

Access: Devices → Configuration profiles → [Profile] → Device status — lists every device the profile is assigned to and the application result per device.

Key evidence artifacts:

Artifact	Location	Purpose
Profile name and settings	Configuration profiles → [Profile] → Properties	Documents the security controls configured
Device assignment list	Configuration profiles → [Profile] → Device status	Shows which devices received the profile and whether it applied successfully
Per-device status	Succeeded / Error / Conflict / Not applicable	Confirms recency of enforcement and identifies failures
Last report time	Device status → Last report column	Confirms the profile state is current

For audit packages, export the profile assignment report and supplement with a screenshot or Graph API export of the profile settings.

---

Intune Diagnostics — Compliance Control Mapping

GCC High (CMMC)

CMMC Evidence Requirements

The following Intune artifacts directly satisfy CMMC Level 2 assessment objectives:

NIST Control	Assessment Objective	Intune Evidence
CM.L2-3.4.1 — Baseline configurations	Demonstrate a baseline configuration is established and applied	Configuration profile export; device profile assignment report showing Succeeded
CM.L2-3.4.2 — Security config enforcement	Demonstrate baseline is enforced and deviations are identified	Device compliance report; noncompliant device list; compliance policy settings export
CM.L2-3.4.6 — Least functionality	Demonstrate unnecessary services and features are disabled	ASR rules policy export; app control policy; configuration profile showing disabled features
CM.L2-3.4.9 — User-installed software	Demonstrate controls on user software installation	Endpoint Privilege Management policy; Win32 app blocklist policy export
SI.L2-3.14.1 — Flaw remediation	Demonstrate patches are applied	Windows Update for Business ring configuration; device update compliance report
SI.L2-3.14.2 — Malicious code protection	Demonstrate AV is deployed and active	Defender for Endpoint onboarding policy status; Tamper Protection configuration
AC.L2-3.1.1 — Authorized access	Demonstrate only authorized devices access the system	Entra device compliance state in Conditional Access; Intune compliance policy list
AU.L2-3.3.1 — Audit records	Demonstrate audit logging of admin actions	Intune audit log export (1 year)

CMMC Evidence Package — Intune Artifacts

For a CMMC assessment, prepare the following exports from Intune:

1. Configuration profile export — screenshot or Graph API export of every configuration profile showing the security settings applied
2. Device compliance report — CSV export of all managed devices with compliance state (target greater than 95% compliant; document exceptions for any noncompliant devices)
3. Compliance policy settings export — the conditions each device must meet: encryption, Secure Boot, OS version minimum, and others
4. Audit log export — 90-day export of the Intune audit log showing administrative actions with initiator identity
5. Enrollment report — all managed devices with enrollment date, OS, and last check-in, demonstrating that all in-scope devices are under management

Commercial

NIST SP 800-171 and SOC 2 Evidence

For commercial organizations undergoing SOC 2 Type II audits or NIST SP 800-171 assessments, the same Intune artifacts apply but the framing differs.

SOC 2 Type II — Relevant Trust Service Criteria

TSC	Criteria	Intune Evidence
CC6.1	Logical and physical access controls	Device compliance policy; Entra Conditional Access requiring compliant device
CC6.6	Logical access security measures	Configuration profiles enforcing encryption, screen lock, and USB disable
CC6.8	Prevention of unauthorized software	App control policies; Endpoint Privilege Management
CC7.1	Configuration monitoring	Noncompliant device alerts; compliance policy enforcement
CC7.2	Monitoring for anomalies	Intune noncompliance notifications; integration with Microsoft Sentinel

NIST SP 800-171 Rev. 3 Control Mapping

Control	Intune Evidence
3.4.1 — Baseline configurations	Configuration profile assignments with Succeeded status
3.4.2 — Configuration change control	Intune audit log showing configuration changes with initiator identity
3.4.6 — Least functionality	ASR rules policy; disabled services configuration
3.14.1 — Flaw remediation	Windows Update ring compliance report
3.14.2 — Malicious code protection	Defender policy assignment and device status

For SOC 2 auditors, export the Intune audit log for the audit period (typically 12 months) and the device compliance state as of the audit date. Most SOC 2 auditors accept Intune portal screenshots supplemented by a Graph API CSV export as sufficient evidence for configuration management controls.

---

Diagnostic Tools Reference

Tool	Access	Use
Intune portal — Device diagnostics	Intune → Devices → [Device] → Collect diagnostics	Remote log collection without user involvement
MDM Diagnostic Report	On device: Settings → Work account → Info → Create report	Full policy report on the device
Intune Troubleshooting blade	Intune → Troubleshoot + support → Troubleshoot → select user	See all devices, policies, and app assignments for a specific user
Graph Explorer	graph.microsoft.com (commercial) or graph.microsoft.us (GCC High)	Query device compliance, configuration, and audit data via API
CMTrace	Included in Configuration Manager client; works on standalone systems	Parse Intune log files in real time with color-coded error and warning indicators