Endpoint and Device Management in Practice with Microsoft Intune

Endpoint and device management is the discipline of keeping a fleet of laptops, phones and tablets configured, compliant and recoverable without an administrator touching each device by hand. The core problem it solves is trust at scale: an organisation needs a way to prove that a device meeting a policy is safe enough to reach corporate data, and a way to change that policy for thousands of devices without visiting any of them. Microsoft Intune is one implementation of this model, built on top of Microsoft Entra ID

for identity and Microsoft Graph as the programmatic interface, sitting inside the broader 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

administrative foundation used across many enterprise environments.

This guide builds a mental model of how Intune enrolment, configuration and compliance actually work, then walks through a single bounded workflow end to end: scoping a configuration profile to a small test group, applying it, observing the evidence Intune produces, and safely rolling it back. Throughout, every action is tied to a reason, an expected observation and a recovery path, because in device management the cost of an unscoped mistake is measured in disrupted end users, not just failed commands. Before starting, confirm you are working in an isolated or non-production tenant, and confirm the exact Intune licence, role assignment and product version available to you, since portal navigation and feature availability change over time.

#Learning Objectives

• Explain the trust relationship between a managed device, Microsoft Entra ID and Intune.
• Describe how configuration profiles and compliance policies differ and how each produces evidence.
• Scope, assign and validate a configuration profile against a bounded test group.
• Diagnose common assignment and compliance failures using symptom-cause-response reasoning.
• Identify the permissions, security controls and escalation points required before repeating this workflow in production.

#Prerequisites

• Access to an isolated or non-production Intune tenant with an assigned administrative role (for example, Intune Administrator or a scoped custom role) confirmed before any change.
• A confirmed Intune licence and product version for the tenant in use; do not assume feature parity with documentation without checking.
• At least one enrolled test device or emulator, and a security group containing only that device or its user.
• Familiarity with basic identity concepts: users, groups and role-based access, as used in Microsoft Entra ID.
• Read-only access to Microsoft Graph PowerShell for evidence-gathering, if you intend to run the example queries.

#Content

#

What “endpoint and device management” means

An endpoint, in this context, is any device that authenticates to receive corporate resources: a laptop, a phone, a tablet. Device management is the set of processes that enrol that endpoint into a management authority, apply configuration to it, measure whether it stays compliant, and act on non-compliance. The mental model has three moving parts: an identity (who owns or uses the device), a management channel (how the platform talks to the device), and a policy engine (what state the device is meant to be in). Intune provides the last two; Entra ID provides the first.

#

Where Intune sits in the trust boundary

Intune does not manage a device directly through some proprietary always-on tunnel. Instead, each supported operating system exposes a management protocol (for example, the Windows MDM stack, or Apple’s device management framework) that periodically checks in with Intune’s cloud service, retrieves outstanding policy, applies it locally, and reports the result back. This means every configuration change is asynchronous: you assign a policy in the admin console, and the device applies it on its own schedule, not instantly. The trust boundary matters because a device can only be as trustworthy as its last successful check-in; a device that has gone offline is not necessarily non-compliant, it is simply unmeasured. Confusing “unknown” with “safe” or “broken” is one of the most common conceptual errors in this domain.

#

Core components and data flow

Four constructs do most of the work. Configuration profiles push settings (Wi-Fi, restrictions, certificates) to a device regardless of its current state. Compliance policies define pass/fail rules (encryption enabled, minimum OS version) and report a state rather than force one. Assignments bind either of these to Entra ID groups, which is how scope is controlled; assigning to the wrong group is the single most consequential mistake in this workflow. App protection and app configuration policies operate at the application layer rather than the device layer, and are out of scope for this guide. Every one of these constructs produces observable evidence in the Intune admin center or through Microsoft Graph: an assignment status, a per-setting result, and a timestamp. Treat that evidence, not your intent, as the source of truth for what actually happened.

#Examples

#

Worked example: scoping a configuration profile safely

Input: a new configuration profile that disables the camera on a test device, assigned to a security group named “intune-lab-test-group” containing exactly one enrolled test device.

Output: after the next client check-in, the profile’s Device status view shows one device with status “Succeeded”, and a Graph query for that profile’s assignments returns only the test group’s object ID, with no additional groups listed.

Interpretation: the “Succeeded” status is evidence that the device retrieved and applied the policy, not evidence that the administrator’s intent was correct; you must separately confirm the assignment target, because a profile can succeed perfectly while being scoped to the wrong population. This is why the exercise below checks both the applied result and the assignment target independently.

#Exercises

#

Exercise: create, assign and validate a bounded configuration profile

Objective: confirm that a configuration profile applies only to an intended, narrowly scoped test group, and that you can reverse it cleanly.

Setup: in your non-production tenant, create a security group containing only your enrolled test device or its assigned user. Create a configuration profile with one low-impact, reversible setting (for example, a custom device name prefix, or a non-destructive restriction). Assign the profile to the test group only.

Expected evidence: within one client check-in cycle, the profile’s Device status blade shows the test device as “Succeeded”; a read-only Microsoft Graph query against the profile’s assignments returns only the test group’s identifier.

Pass condition: the test device shows “Succeeded” and no group other than the intended test group appears in the assignment list.

Stop condition: if the assignment list shows a built-in group such as “All Devices” or “All Users”, or if any device outside your test group reports the profile, stop immediately and remove the assignment before investigating further.

Cleanup: remove the profile assignment from the test group (or delete the profile if it was created solely for this exercise), then confirm on the next check-in that the setting reverts on the test device.

#Validation Guidance

Validation in device management means correlating three independent signals rather than trusting any single one: the portal’s per-device status, a programmatic query against the same object, and, where feasible, direct observation on the device itself. Relying only on the portal’s summary count can hide a single mis-scoped device inside an otherwise healthy population.

• Check the profile’s Device status and User status tabs in the Intune admin center for per-device results, not just the aggregate success count.
• Run a read-only Microsoft Graph query against the profile or policy’s assignments to confirm the exact target group identifiers.
• Cross-check the device’s compliance state and last check-in timestamp to ensure the evidence is current rather than stale.
• Where possible, confirm the setting directly on the test device rather than relying solely on cloud-reported status.

#Common Mistakes

• Assigning a profile to a built-in group like “All Devices” while intending to target a small test group, because the assignment picker defaults are easy to click past.
• Treating a “Pending” status as a failure immediately, when it may simply reflect that the device has not checked in yet.
• Editing a shared production profile to test a setting, instead of cloning it or creating an isolated test profile.
• Assuming a compliance policy’s pass state proves a security control is enforced, when compliance only reports state and does not by itself block access without a linked conditional access policy.
• Deleting a profile to “undo” a change instead of reverting the assignment first, which can leave the last-applied settings in place until the next management cycle clarifies the removal.

#Production Bridge

Everything above assumes a lab tenant with a disposable test group. Moving this workflow into production changes the risk profile substantially. Confirm the specific Intune role assigned to your account and whether it is scoped by administrative unit or by group; an overly broad role can let a well-intentioned test become a tenant-wide change. Treat every assignment step as state-changing: before touching a live profile, record its current assignments and settings so you have a known-good baseline to restore. Any policy that affects authentication, encryption or conditional access should be reviewed by a second administrator before assignment, and rolled out to a small pilot ring before wider deployment. If you observe unexpected scope (a device outside your intended target reporting the policy), escalate to the Intune tenant administrator and, if conditional access or compliance-linked access is involved, to your identity and access management owner before making further changes, since compliance state can gate production access to email and other services.

#Key Takeaways

• Intune management is asynchronous: a device applies policy on its own check-in schedule, so “Pending” is not automatically a failure.
• Configuration profiles enforce settings; compliance policies report state; conditional access is what actually restricts access based on that state.
• Assignment scope, not policy content, is the most common source of unintended impact, so validate the target group independently of the applied result.
• Evidence should come from at least two independent sources (portal status and a programmatic query) before you trust a change.
• Every exercise here has a defined stop condition and cleanup step; carry that discipline into production, where the same mis-scoped assignment affects real users rather than a lab device.

Before repeating this workflow outside the lab, re-confirm your assigned role, capture the current state of any profile you intend to touch, and agree an escalation contact in advance; that single habit is what keeps a routine Intune change recoverable rather than disruptive.