Microsoft Intune and device management

Microsoft Intune is the cloud endpoint management service in Microsoft 365. It enrolls devices, pushes policies and applications to them, and reports on compliance — all from a browser-based admin centre at intune.microsoft.com, with no on-premises servers to maintain. If Entra ID answers "who is this user?", Intune answers "what device are they on, and can we trust it?" — and those two answers together are the foundation of every serious Microsoft 365 security design.

Task pages: register devices for Autopilot, bulk-assign configuration profiles, deploy a Win32 app, require compliant devices, and remote wipe a lost device. Deeper topics include scripts and remediations, Microsoft Tunnel, Microsoft 365 Apps for Mac, Cloud Policy, the Office Deployment Tool, activation troubleshooting, Windows 11 annual servicing, and the virtual desktop pair Azure Virtual Desktop and Windows 365 vs AVD cost. For the Mac and cross-platform decisions, see Intune vs Jamf, Intune vs Kandji, and Intune vs Workspace ONE.

What Intune manages

• Windows 10/11 desktops and laptops, joined to Entra ID and enrolled in Intune.
• macOS devices, via Apple Business/School Manager and Intune.
• iOS and iPadOS devices.
• Android devices, including dedicated kiosks and frontline-worker scenarios.
• Linux has limited support, focused on compliance attestation.

You can manage corporate-owned devices end-to-end ("MDM" — mobile device management) and partially manage personal devices through app-level controls ("MAM" — mobile application management) so personal data stays out of IT's reach. The MDM/MAM distinction is the single most important design decision: full management of personal phones is both intrusive and unnecessary when app protection policies can wall off corporate data inside Outlook and Teams without touching the rest of the device.

How devices get enrolled

Enrollment is where Intune projects either succeed or stall, so it deserves its own plan:

• Windows Autopilot — the corporate-Windows pattern. Hardware ships from the vendor, the user signs in with their Entra ID account on first boot, and the device joins Entra ID, enrolls in Intune, and receives its apps and policies without IT ever touching it. Pair it with the Enrollment Status Page so users can't start working on a half-configured machine.
• Automatic enrollment — Entra-joined or hybrid-joined Windows devices enroll when the user signs in, controlled by MDM auto-enrollment settings. This is also the path for bringing existing devices under management.
• Apple Automated Device Enrollment — corporate iPhones, iPads, and Macs purchased through Apple Business Manager enroll supervised and non-removable.
• Android Enterprise — work profile for personal devices; fully managed or dedicated modes for corporate ones.

The trap to avoid: hybrid Entra join plus co-management with Configuration Manager is a transitional state, not a destination. New environments should go cloud-native (Entra join + Intune) and let the file-server-era patterns go.

What policies do

• Configuration profiles push settings: Wi-Fi, VPN, certificates, browser policies, Windows Update settings. On Windows, prefer the settings catalog over legacy templates — it's the maintained surface.
• Compliance policies define what "healthy" means — disk encrypted, OS up to date, antivirus running, Defender risk score under a threshold — and feed that signal into Conditional Access.
• App protection policies govern how corporate apps behave on personal devices: no copy-paste into personal apps, PIN required, remote wipe of corporate data only.
• App deployment installs and updates Microsoft 365 Apps, Edge, line-of-business apps, and Win32 packages. For anything complex, package as Win32 even if a plain MSI exists — the Win32 agent handles dependencies, detection rules, and supersedence far better.
• Endpoint security policies configure BitLocker/FileVault, firewall, attack surface reduction rules, and onboarding into Defender for Endpoint.

Target policies at Entra ID groups — user groups for things that follow people, device groups (often dynamic, based on enrollment attributes) for things that belong to hardware. Use the built-in All users / All devices virtual groups with filters deliberately and sparingly; a pile of overlapping assignments with contradictory settings is the most common reason Intune environments become undebuggable.

Intune and Conditional Access

The signal Intune publishes — "this device is compliant" — is the single most useful input to Conditional Access. A typical policy: only let users into corporate apps if they're signed in with MFA from a managed, compliant device. This pattern, often called zero-trust device posture, is the main reason organisations adopt Intune. It changes device management from a nice-to-have into an access gate: an unmanaged or drifting device simply can't reach Exchange Online or SharePoint, no matter whose credentials it presents.

Two practical notes. First, compliance evaluation isn't instant — devices check in periodically, so build a grace period into compliance policies rather than locking users out over a patch that installed an hour ago. Second, always pair device-compliance Conditional Access with a tested exclusion story (break-glass accounts, a fallback for enrollment day one), or you'll lock yourself out of the tools needed to fix the lockout.

Licensing

Intune is included with Microsoft 365 Business Premium, E3, E5, F3, and as a standalone product. It's also part of the Enterprise Mobility + Security (EMS) SKU. The Intune Suite add-on (or its individual components) unlocks Remote Help, Endpoint Privilege Management, Advanced Analytics, and enterprise app patching — genuinely useful, but adopt them for a named problem, not for completeness.

Where to start

For a green-field rollout, the order that works: enable automatic enrollment, define compliance policies (start lenient, tighten later), stand up Autopilot for new hardware, deploy the core app set, then — and only then — turn on the Conditional Access compliance gate, piloted on one group first. For Microsoft 365 customers, Intune is the natural and increasingly the only sensible answer for managing endpoints alongside the rest of the stack; third-party MDM tools now spend most of their effort re-integrating with the Entra and Defender signals Intune gets natively.

Worked example: rolling out the compliance gate without locking anyone out

A 200-user organisation already has every device enrolled and a compliance policy defined (disk encryption on, OS within N versions of current, Defender risk score below a threshold), but nobody has ever turned on the Conditional Access rule that actually requires it. IT enables the policy in report-only mode first — Conditional Access evaluates what would happen without blocking anyone — and lets it run for two weeks. The sign-in logs show 15 devices that would fail: eight are simply out of date and self-remediate once the user restarts, four are older devices missing disk encryption that IT enables remotely, and three are personal phones running mail via a native app rather than Outlook, which the app-protection-based MAM policy doesn't cover the same way. IT fixes the three genuine gaps, adds a documented break-glass account excluded from the policy, and only then switches the same Conditional Access policy from report-only to enforced — at which point the number of users actually affected on day one is zero, because every real gap was already found and closed during the report-only window.

MSP checklist

• Never enable a new device-compliance Conditional Access policy in enforced mode on day one — report-only mode for at least a week or two is what turns a lockout incident into a quiet rollout, on every client, every time.
• Confirm a tested break-glass account exists and is excluded from every compliance-gated Conditional Access policy before touching enforcement — the account that fixes a lockout must not itself be lockable by the policy it's meant to fix.
• Keep policy assignment scoped to real Entra ID groups per client, not the built-in All users / All devices virtual groups — a pile of overlapping assignments across a client's tenant is the most common reason an Intune environment becomes undebuggable during a support call.
• Flag any client still running hybrid Entra join with co-management as a transitional state to plan out of, not a steady-state architecture — new hardware for that client should go cloud-native from day one rather than extending the transitional pattern further.