Reading Endpoint and Device Management Evidence with Microsoft Intune

When a device enrols into Microsoft Intune, several distinct records begin accumulating evidence about that device: enrolment status, compliance policy results, configuration profile assignment state, and sign-in context from Microsoft Entra ID

. A graduate practitioner is frequently asked to “check whether the policy applied” without being told which of these records to read, or why they might disagree with one another. This guide builds the mental model needed to read that evidence correctly before changing anything.

The workflow bounded here is deliberately narrow: creating one compliance policy in a non-production tenant, assigning it to a test device group, and reading the resulting compliance evidence through the Intune admin centre. This is a read-and-validate workflow, not a fleet-wide rollout, and every step is designed to be reversible within the same lab session.

#Learning Objectives

• Explain the relationship between device enrolment, compliance policy evaluation and configuration profile assignment in Microsoft Intune.
• Identify the trust boundaries between the device, Microsoft Entra ID and the Intune service, and state what evidence crosses each boundary.
• Create and assign a bounded compliance policy in a non-production tenant and interpret the resulting compliance report.
• Diagnose common causes of delayed or missing compliance evidence and choose an appropriate escalation path.
• Describe the permissions and safeguards required before applying an equivalent change in a production tenant.

#Prerequisites

• Access to an isolated or non-production Microsoft 365
  The KBY Lexicon

  Microsoft 365

  Microsoft 365 defined at plain and technical depth, with architecture, operational relevance, an example and a common misunderstanding for practitioners.

  Read Full Context
  /Intune tenant intended for testing, not a production tenant.
• A test user account and at least one enrolled or enrollable test device (physical or virtual) assigned to that account.
• An account holding an Intune administrator or equivalent role scoped to the test tenant only.
• Confirmation of the current Intune admin centre version and licensing state for the test tenant before making any change, since navigation and policy options change between service updates.
• Basic familiarity with Microsoft Entra ID groups, since Intune assignment relies on group membership rather than direct device targeting in most cases.

#Content

#

The mental model: three cooperating systems

Microsoft Intune does not act alone. Three systems cooperate, and understanding the boundary between them explains most of the confusing evidence graduates encounter. First, Microsoft Entra ID authenticates the device and user and issues the tokens that let the device talk to Intune; this is an identity boundary, not a management boundary. Second, the Intune service holds policy definitions, assignments and the compliance/reporting pipeline; this is the control-plane boundary. Third, the device itself runs a management agent (built into Windows, or the Company Portal/MDM agent on other platforms) that pulls policy, applies it locally, and reports results back; this is the enforcement boundary, and it is the only place where the policy has real effect.

Because these are three separate systems with independent check-in schedules, evidence is never instantaneous. A policy can exist and be assigned in Intune while the device has not yet checked in to receive it. This is not a fault; it is the expected asynchronous behaviour of a pull-based management model, and it is the single most common source of “the policy isn’t working” reports that turn out to be reporting lag rather than failure.

#

What a compliance policy actually evaluates

A compliance policy is a declarative set of conditions (for example, minimum OS version, disk encryption state, or password requirements) that Intune asks the device to self-report against. The device agent evaluates the conditions locally and sends a result; Intune does not reach into the device to check state directly. This matters because a “non-compliant” result is evidence of what the device itself reported, filtered through whatever check-in interval and agent version was active at that time, not a live real-time measurement. Treating a compliance report as a live snapshot, rather than a recent self-report, is a frequent source of misdiagnosis.

#

Assignment and scope

Policies in Intune are assigned to Microsoft Entra ID groups, not directly to individual devices or users in most configurations. This indirection is deliberate: it lets an organisation manage scope through group membership rather than editing every policy when the target population changes. For a graduate exercise, this means the bounded blast radius of any test policy is exactly the membership of one test group, provided that group is not reused elsewhere in the tenant.

#

Declared assumptions for this guide

This guide assumes a dedicated non-production tenant or a clearly separated test collection within a tenant, current administrative permissions confirmed immediately before the exercise, and no reliance on cached documentation about menu locations, since the Intune admin centre is updated on a rolling basis by Microsoft and specific navigation paths are not treated here as stable, dated facts.

#Examples

#

Worked example: reading a compliance evidence trail

Input: A compliance policy named “Test-BitLocker-Required” is assigned to a group named “Test-Device-Group” containing one enrolled Windows test device. The policy requires disk encryption to be enabled.

Output observed in the Intune admin centre, Devices > Monitor > Compliance report view: The device row shows a compliance state, a “last check-in” timestamp, and a per-setting breakdown showing which individual condition (in this case, disk encryption) passed or failed.

Interpretation: A “Compliant” state with a recent check-in timestamp is reasonably strong evidence that the device met the condition at that check-in. A “Non-compliant” state paired with an old check-in timestamp is weaker evidence about current device state and stronger evidence about a connectivity or check-in problem; the correct next step is to force a device sync rather than immediately assuming the policy failed to apply. A state of “Not applicable” indicates the device fell outside the policy’s platform or configuration scope entirely, which is a targeting issue rather than a device fault.

#Exercises

#

Exercise: create, assign and validate a bounded compliance policy

Objective: Observe the full cycle from policy creation to compliance evidence for one test device, without affecting any other device or policy in the tenant.

Setup: Confirm you are operating in the non-production tenant and that “Test-Device-Group” contains only your intended test device. Confirm your account has Intune administrator rights scoped to this tenant. Note the current time before starting, to interpret check-in timestamps afterwards.

Steps: Create a new compliance policy for the test device’s platform with one clearly observable condition (such as a minimum OS version already known to be satisfied). Assign it only to “Test-Device-Group”. On the test device, trigger a manual sync from the Company Portal app or Settings sync option rather than waiting for the default interval, so evidence appears within the lab session.

Expected evidence: Within the Intune admin centre compliance report, the test device shows a compliance state, an updated check-in timestamp close to the time of the manual sync, and a per-setting result matching the condition you set.

Pass condition: The device shows “Compliant” with a check-in timestamp after your manual sync trigger, and the per-setting breakdown attributes this to the specific condition you configured.

Stop condition: If the device shows no check-in activity at all after two manual sync attempts and a wait of at least fifteen minutes, stop and move to the diagnosis guidance in Common Mistakes rather than repeating the same action; repeated forced syncs without diagnosis waste time and can mask a connectivity problem.

Cleanup: Delete or unassign the test compliance policy, and remove the test device from “Test-Device-Group” if the group is not intended for reuse. Confirm the policy no longer appears in the device’s assigned policy list before ending the session.

#Validation Guidance

Validation here means confirming that the evidence you are reading reflects the change you made, not a coincidental prior state. Check the policy’s assignment tab to confirm the group membership is exactly as intended. Check the device’s “Device configuration” or “Compliance” blade for a check-in timestamp newer than your change. Cross-reference the per-setting result, not just the overall state, since an overall “Compliant” result can mask a setting that is “Not applicable” rather than genuinely passing.

#Common Mistakes

Symptom: Compliance state remains “Not evaluated” long after assignment.
Cause: The device has not checked in since assignment, or the assignment group evaluation itself has not propagated.
Diagnosis: Confirm group membership is correct and check the device’s last check-in time.
Correction: Trigger a manual sync on the device and re-check after a short wait.
Recovery/Escalation: If check-in remains absent after multiple attempts, escalate to whoever manages the tenant’s device enrolment health, since this may indicate a broader connectivity or enrolment problem rather than a policy issue.

Symptom: Policy shows as assigned but device reports “Not applicable”.
Cause: Platform or OS-version scoping in the policy excludes this device.
Diagnosis: Compare the policy’s platform requirements against the device’s actual platform and OS version.
Correction: Adjust scope or accept that the device is correctly outside this policy’s intended population.
Recovery/Escalation: No escalation needed if scoping is intentional; document the exclusion if it was unexpected.

#Key Takeaways

• Intune compliance evidence is a recent self-report from the device agent, not a live measurement, so timestamps matter as much as states.
• Assignment happens through Microsoft Entra ID groups, which bounds blast radius but requires careful group hygiene.
• A bounded, group-scoped test policy in a non-production tenant is fully reversible within one lab session.
• Distinguishing “Non-compliant”, “Not applicable” and “Not evaluated” is essential to correct diagnosis; treating them as interchangeable leads to wrong conclusions.

#Production Bridge

In a production tenant, the same workflow requires an Intune role scoped by Role-Based Access Control to only the intended device or user groups, not tenant-wide administrator rights. Any compliance policy change should be piloted against a small, named pilot group before wider assignment, with a documented rollback of removing the assignment (not necessarily deleting the policy) as the first recovery action if unexpected non-compliance appears at scale. Escalation paths should be confirmed with the team owning tenant-wide Intune configuration before any assignment beyond the pilot group, and any change with security implications, such as compliance-driven Conditional Access enforcement, should be reviewed by that team before rollout.