Microsoft Intune Endpoint Security: A Practical Guide

Microsoft Intune is Microsoft’s device management platform: it enrols, configures, and enforces policy on devices across Windows, macOS, iOS/iPadOS, Android and Linux, whether they’re corporate-owned or bring-your-own. Endpoint security in Intune specifically covers the policies aimed at reducing a device’s attack surface and getting security telemetry off it, as opposed to the broader configuration and app management side of the platform.

If you’re setting this up for the first time, the confusing part usually isn’t Intune itself, it’s the number of overlapping policy types that all sound like they do the same thing. They don’t, and mixing them up is the most common source of policies that silently conflict with each other.

Compliance policies vs configuration policies: what’s the actual difference?

Compliance policies answer a yes/no question: is this device meeting the bar we’ve set? Minimum OS version, disk encryption enabled, a passcode set, not jailbroken or rooted. A device that fails a compliance policy gets marked non-compliant, and that status is what Conditional Access checks before deciding whether to let it access company resources. Compliance policies don’t configure anything on the device themselves, they only report a state.

Configuration policies (also called device configuration profiles) actually change settings on the device: Wi-Fi profiles, VPN settings, restrictions on camera or Bluetooth use, browser settings, and so on. Where compliance policies check, configuration policies do.

Endpoint security policies sit alongside both of these and are specifically focused on security controls: antivirus configuration, disk encryption enforcement, firewall rules, attack surface reduction rules, and endpoint detection and response settings. In practice they overlap in function with configuration policies but are managed through a separate, security-focused blade in Intune, aimed at a security admin rather than a general IT admin audience.

Can I use security baselines and endpoint security policies together?

Yes, and for most organisations this is the right approach rather than picking one. Security baselines are pre-configured groups of settings representing Microsoft’s recommended security posture for a given product (Windows, Microsoft 365 Apps, Defender for Endpoint), designed as a starting point you tune from rather than a rigid standard you must apply as-is.

Endpoint security policies are more granular and targeted at specific control areas. The practical pattern most organisations land on: apply a baseline first to get a sensible default posture across the board, then layer targeted endpoint security policies on top for anything the baseline doesn’t cover precisely enough, or where you need different settings for a specific device group. Where a baseline and an endpoint security policy configure the same setting, Intune’s conflict resolution applies, so it’s worth checking for overlap deliberately rather than discovering it through unexpected behaviour later.

Do I need Defender for Endpoint to use endpoint security in Intune?

Partially. Some endpoint security policy types work independently of Defender for Endpoint, including basic antivirus configuration (using Microsoft Defender Antivirus, which ships with Windows) and disk encryption policies for BitLocker or FileVault. You can deploy these with just an Intune licence.

Other endpoint security capabilities specifically require Defender for Endpoint: endpoint detection and response (EDR) policies, attack surface reduction rule reporting, and the security tasks and vulnerability management features that connect Intune to Defender’s threat and vulnerability management data. If your endpoint security strategy includes EDR, and for most organisations handling anything sensitive it should, you need Defender for Endpoint alongside Intune, not just Intune on its own.

Cross-platform reality: macOS and Android

Endpoint security in Intune isn’t Windows-only, though Windows still has the deepest policy coverage. macOS support has matured significantly and covers disk encryption (FileVault), firewall configuration, and Gatekeeper settings through dedicated macOS endpoint security profiles. Android is split between fully managed (corporate-owned) devices, which get the full policy set, and personally-owned devices enrolled through work profile, which deliberately have a narrower policy scope to respect the separation between personal and work data.

The practical implication: don’t assume a policy that works cleanly on Windows will have an exact equivalent on macOS or Android. Check platform-specific documentation before assuming feature parity, because the gaps are real and they change with every Microsoft 365 release wave.

Managed devices vs BYOD

Fully managed, corporate-owned devices get the complete Intune policy toolkit: compliance, configuration, endpoint security, and (where licensed) full EDR integration. Personal devices enrolled for work access typically go through Mobile Application Management (MAM) rather than full device enrolment, applying policy at the app level (Outlook, Teams, OneDrive) instead of the whole device.

This distinction matters for endpoint security specifically, because most of the deeper endpoint security controls, EDR, attack surface reduction, firewall management, only apply to devices under full management. A BYOD strategy built purely on MAM gets you data protection at the app boundary, not device-level security. That’s a legitimate choice for some organisations and genuinely insufficient for others, depending on what data those devices actually touch.

Getting started without overwhelming yourself

For a small team standing this up from nothing, the realistic sequence is: apply a security baseline to your Windows devices first, since that alone covers most of the ground quickly. Add BitLocker/FileVault disk encryption policies next, since they’re cheap to deploy and high value. Then layer in Defender for Endpoint and its associated EDR policies once you have licensing sorted. Compliance policies feeding Conditional Access come alongside or shortly after, since device compliance is one of the more valuable signals Conditional Access can act on.

Resist the urge to configure everything on day one. A smaller set of policies you actually understand and can troubleshoot beats a comprehensive set nobody on the team can explain when something breaks.

What can my employer actually see on a device managed by Intune?

This comes up constantly, especially with BYOD, and it’s worth answering honestly rather than glossing over it. On a fully managed corporate device, IT can see device compliance status, installed apps, and security configuration, and can wipe the device entirely if it’s lost or the employee leaves. On a personal device enrolled only through MAM (app-level management, not full enrolment), visibility is much narrower: your employer can see and control company data inside managed apps like Outlook or Teams, and can wipe that company data specifically, but it cannot see your personal photos, browsing history, or other apps outside that managed boundary. If you’re unsure which category your device falls into, check with whoever manages your organisation’s Intune tenant, the distinction genuinely matters for your privacy.