Microsoft quietly dropped a compliance reporting clarification in the May 2026 Intune service release that’s easy to scroll past โ€” but if your organization uses custom compliance policies or Android app configuration reporting, you’ll want to understand exactly what changed and why it matters for your security posture.

The short version: device-reported values in compliance reports are informational, not authoritative. Here’s what that means in practice.

What Changed

In the Week of May 18, 2026 update, Microsoft updated documentation to clarify how administrators should interpret the Setting column that appears in certain compliance reports. This column surfaces values reported directly by the device โ€” and Microsoft’s guidance now explicitly states these should be treated as informational only, with new security considerations added for reviewing device-reported data.

The affected scenarios are:

  • Custom compliance policies โ€” where PowerShell scripts or other probes gather device state and return values to Intune for evaluation
  • Android app configuration reporting โ€” where managed apps return configuration data that appears in compliance-adjacent reports

Why This Distinction Matters

This isn’t just documentation housekeeping. It’s a signal about how Microsoft wants organizations to think about the trust boundary in their compliance architecture.

Here’s the architecture that matters: Intune is the compliance evaluator. It deploys policies, collects device signals, runs the evaluation, and writes a binary isCompliant flag to the device object in Microsoft Entra ID. Conditional Access then reads that flag when making access decisions โ€” it never queries the device directly at authentication time.

Device-reported values in the Setting column are the raw claims the device made during that evaluation. They’re what the device said, not what Intune independently verified.

Why does that matter? A compromised device could theoretically return fabricated values. The authoritative compliance signal is the server-side evaluation result โ€” not the device’s self-reported data. By clarifying that these values are informational, Microsoft is reinforcing a critical principle: you can’t trust a device to accurately report its own compliance state.

What Organizations Should Do

If you’re using custom compliance policies:

  • Your script return values shown in reports are diagnostic context, not proof of compliance
  • Review your scripts to ensure they’re measuring meaningful, hard-to-spoof signals
  • Cross-reference anomalous device-reported values with other signals: Defender for Endpoint threat levels, Entra risk scores, and hardware attestation data
  • Document which parts of your compliance posture rely on device-reported data vs. server-evaluated signals

If you’re using Android app configuration reporting:

  • App-returned configuration data in reports helps you understand device state, but the compliance decision belongs to Intune’s evaluation engine
  • Don’t use these values as the primary signal for access policy decisions without server-side corroboration

For all environments:

  • Treat unusual device-reported values as a trigger for investigation, not as a pass/fail verdict
  • Consider layering hardware attestation (TPM-backed signals, device health attestation) to supplement script-based custom compliance
  • Ensure your Conditional Access policies enforce compliance through the isCompliant flag in Entra, not through app-level workarounds

What Has NOT Changed

It’s worth being explicit about what this update doesn’t change:

  • Compliance enforcement still works the same way. Intune evaluates compliance, writes the result to Entra ID, and Conditional Access reads it. The pipeline is unchanged.
  • Custom compliance policies still function normally. Your scripts still run, their output is still evaluated, and the compliance status is still written to Entra. Microsoft just wants you to treat the raw reported values as context, not gospel.
  • Android app configuration policies are unaffected. The policies themselves, their deployment, and their enforcement behavior haven’t changed.

The Bigger Picture

This update is part of a broader pattern in how Microsoft is hardening its Zero Trust story. Zero Trust’s “never trust, always verify” principle applies to devices too โ€” including managed ones. The compliance architecture Microsoft has built routes device trust through multiple layers of server-side evaluation precisely because self-reported device data is a weak link.

By making this explicit in documentation, Microsoft is nudging organizations to think about their compliance programs more carefully. Are your custom compliance scripts measuring signals that are genuinely hard to fake? Are you layering multiple signals? Are your Conditional Access policies enforcing the right controls?

The answer for most mature environments is yes โ€” but this is a good prompt to audit your compliance policies and verify your Zero Trust controls are working as intended, not just showing green in the admin center.

This guidance also connects to Microsoft’s ongoing investment in device health attestation and the deeper integration between Intune, Defender for Endpoint, and Entra ID Conditional Access. The direction of travel is clear: more server-side validation, more layered signals, less reliance on what devices say about themselves.

Need Help Navigating Intune Changes? Big Hat Group helps organizations design, deploy, and manage Microsoft Intune environments โ€” from compliance policy architecture to Zero Trust strategy. Whether you’re building out custom compliance policies or hardening your Conditional Access controls, we can help you get it right. Reach out here.

Big Hat Group is a Microsoft partner specializing in modern endpoint management, Microsoft Intune, and Microsoft 365 deployments.