The Call That Changed Everything

It was a Monday morning in 2022. My phone rang at 7:43 AM — before I had even opened my laptop. The IT Director at a 3,000-seat financial services firm was on the line, and his voice told me everything before his words did.

“We’ve had a breach. A contractor’s unmanaged laptop. It was never in SCCM. We have no idea what was on it or what it accessed.”

That single call crystallized something I had been telling clients for years: you cannot secure what you cannot see, and you cannot manage what you have never enrolled. The contractor’s laptop existed outside every boundary the organisation thought it had built. No compliance policy had ever touched it. No patch had ever reached it. And now it had become the entry point for an attacker who spent eleven days inside the network before anyone noticed.

That firm became one of my most intensive Intune deployments — 3,200 devices, six enrollment profiles, four compliance rings, and a Zero Trust Conditional Access architecture built from scratch in ninety days. This article is the distilled version of everything I learned not just from that project, but from fourteen years of deploying endpoint management solutions across industries ranging from financial services to healthcare to manufacturing.

What Microsoft Intune Actually Is in 2026

Most engineers I interview can tell me that Intune manages devices. Very few can tell me the full scope of what that means in 2026. Let me give you the architect’s view.

Microsoft Intune is the unified endpoint management and security enforcement plane within the Microsoft 365 ecosystem. It sits at the intersection of three critical control surfaces: device management, identity governance, and security compliance. In 2026 it encompasses four distinct capability sets that most organisations treat as separate products — when in reality they are all within the Intune console.

The Complete Intune Setup Flow — Architecture Diagram

Before touching a single configuration in the Intune admin center, every enterprise deployment should start with a clear architecture map. After building this flow across dozens of organisations, here is the sequence that works — in order.

Enrollment Deep Dive — The Four Methods Explained

Enrollment is the foundation. If a device is not enrolled, nothing else in this article applies to it. That was the exact lesson from the breach story I opened with. Let me walk you through each enrollment method with real-world context from actual deployments.

Windows Autopilot — The Gold Standard for Corporate Devices

Autopilot is the method I specify for every greenfield corporate Windows 10/11 deployment without exception. It removes the need for imaging infrastructure entirely. A device ships from the OEM, the user powers it on, signs in with their corporate credentials, and Intune takes over — pushing configuration, apps, and security policies before the user reaches the desktop.

• User-Driven mode — User signs in with Entra ID credentials. ESP (Enrollment Status Page) holds the desktop until all required apps and policies are applied. Default for most corporate deployments.
• Self-Deploying mode — Zero user interaction. Device provisions itself using TPM attestation. Used for shared kiosks, meeting room devices, and digital signage.
• Pre-provisioned (White Glove) — IT or the OEM completes the device phase before shipping. User experience at unboxing is dramatically faster because the device-phase is already done.
• Autopilot for existing devices — Re-image existing devices with a task sequence that converts them to Autopilot-registered devices. Critical for migrations from SCCM-only environments.

Co-management — The Realistic Migration Path

For any organisation with an existing SCCM estate, co-management is not optional — it is the only sensible migration architecture. Co-management lets SCCM and Intune coexist and manage the same device simultaneously, with workloads slid progressively from SCCM to Intune over time.

BYOD with MAM-WE — App Protection Without Device Control

This is the most misunderstood enrollment scenario I encounter. When a personal device accesses corporate data through a Microsoft 365 app, you have a choice: enroll the full device (invasive, rejected by most employees) or apply MAM Without Enrollment (MAM-WE) — which wraps only the corporate apps with policy, leaving the personal side completely untouched.

• Data-at-rest encryption within corporate app containers
• Prevent copy-paste from corporate to personal apps
• Block save-as to personal storage locations (iCloud, Google Drive)
• Remote selective wipe — removes only corporate data when employee leaves, personal photos and apps remain
• PIN or biometric required to open corporate apps, independent of device lock screen

Compliance Policies — The Heart of Zero Trust Enforcement

A compliance policy in Intune is a set of rules that determines whether a device is considered healthy and trustworthy. The critical thing to understand is that compliance is not just an Intune concept — the compliance state from Intune flows directly into Entra ID, where Conditional Access uses it as an access control signal.

This is Zero Trust in action. The device proves it meets your security requirements. Entra ID verifies that compliance. Access is granted — or denied — based on that verified state, not on the assumption that “it is on our network so it must be safe.”

Zero Trust Architecture with Intune and Entra ID

Zero Trust is not a product you buy. It is a security philosophy with three principles: verify explicitly, use least privilege access, and assume breach. Microsoft Intune, combined with Entra ID, gives you the technical mechanisms to enforce all three at the endpoint layer. Let me show you how the architecture works in practice.

The Three Conditional Access Policies Every Organisation Needs First

• CA001 — Require compliant or Entra hybrid joined device: Applies to all cloud apps, all users (excluding break-glass accounts). This is the foundational policy — no compliant device, no access. Deploy in report-only mode first.
• CA002 — Require MFA for all users accessing Microsoft 365: Applies to Office 365 app, all users. Blocks sign-in without a second factor. The single most effective breach prevention control available.
• CA003 — Block legacy authentication protocols: Applies to all cloud apps, all users, filter condition: client apps = legacy authentication clients. Legacy auth bypasses MFA entirely — this policy closes that gap.

Security Baselines and Endpoint Security Policies

A security baseline in Intune is a pre-configured group of settings recommended by Microsoft based on guidance from the Microsoft security team, NIST, and CIS benchmarks. They are versioned, so you can track what changed between baseline versions and make deliberate decisions about which settings to adopt.

As of 2026, Intune offers the following official baselines:

SCCM to Intune Migration — The Architecture I Use

This is where I spend most of my consulting time. The majority of enterprise environments I enter are SCCM-dominant, with Intune partially configured or not configured at all. The migration is not a cutover — it is a phased workload transition with SCCM and Intune running in parallel throughout.

The Twelve Most Common Intune Mistakes I See in the Field

Entra ID Deep Integration — What Most Engineers Miss

The relationship between Intune and Entra ID is not an integration — it is a single unified identity and device control plane. Most engineers I mentor understand Intune for device management and Entra ID for identity. Very few understand that the compliance signal, the device object, and the access token are all part of the same evaluation chain.

Dynamic Device Groups — The Automation Layer

Manual Intune assignments to static groups do not scale. In any deployment over 200 devices, the assignment architecture should be built entirely on Entra ID dynamic device groups — membership rules that automatically place devices in the correct group based on device properties.

• OS version targeting: (device.operatingSystemVersion -startsWith "10.0.226") — target only Windows 11 22H2+ devices
• Autopilot device targeting: (device.devicePhysicalIds -any (_ -contains "[ZTDId]")) — automatically targets all Autopilot-registered devices
• Corporate vs personal: (device.deviceOwnership -eq "Company") — separate management profiles for corporate vs BYOD
• Department targeting: (device.extensionAttribute1 -eq "Finance") — use extension attributes synced from HR to apply finance-specific hardening

Entra ID Conditional Access — Named Locations and Sign-in Risk

Beyond the three foundational CA policies I described earlier, there are two additional controls that complete the Zero Trust picture at the identity layer:

• Named Locations policy: Block access attempts from countries where your organisation has no employees. Reduces credential stuffing noise dramatically. Configure named locations with your trusted IP ranges and country whitelist.
• Sign-in risk policy (Entra ID P2): When Entra ID Protection detects anomalous sign-in behaviour (atypical travel, leaked credentials, anonymous IP), it generates a sign-in risk score. A CA policy can require step-up MFA or block access when risk is Medium or High.

Licensing — What You Need for Each Capability

Practical Field Notes — Real Deployments, Real Lessons

What Worked

• Dynamic group architecture first: Before enrolling a single device in co-management, we built the full Entra ID dynamic group structure. This meant the moment a device enrolled, it was automatically placed in the right group and received the right policies — no manual assignment backlogs.
• MDE connector before compliance policy: We deployed the MDE connector and onboarding package two weeks before adding the MDE risk level requirement to compliance policies. This gave all devices time to appear in the Defender portal and settle to their baseline risk level before being evaluated.
• Report-only CA for 30 days: Running all CA policies in report-only mode for a full month before enforcing them revealed 23 legacy service accounts and 4 shared mailbox accounts that were being used for interactive sign-in. We had time to fix them properly rather than discovering them via a P1 lockout.
• Pilot ring with IT champions: We onboarded the helpdesk team in the first pilot ring. They became expert troubleshooters before any business users were impacted, which reduced L1 ticket volume by roughly 40% in the first month of broad rollout.

What We Had to Fix

• SCCM client and Intune co-management conflict on firewall profiles: The Windows Security Baseline we deployed via Intune conflicted with an existing SCCM firewall GPO. The SCCM GPO was winning on some machines, Intune on others, creating inconsistent compliance states. Resolution: slide Endpoint Protection workload fully to Intune and block the SCCM GPO via group policy loopback.
• BitLocker recovery key escrow failure on pre-existing encrypted devices: Devices that were already BitLocker encrypted before Intune enrollment did not automatically upload recovery keys to Entra ID. We had to deploy a PowerShell script via Intune to silently re-back-up keys for all pre-encrypted devices.
• Autopilot hash registration delay: For existing devices converted to Autopilot using the SCCM task sequence method, hardware hash upload to the Autopilot service could take up to 24 hours to sync to Intune. Build this delay into your deployment window or pre-stage hashes during a maintenance window.

Final Thoughts — Intune Is Your Zero Trust Foundation

After fourteen years of working with endpoint management platforms — from SCCM 2007 to ConfigMgr Current Branch to Intune — I can say with confidence that Microsoft Intune in 2026 is the most capable endpoint management and security enforcement platform available to organisations running Microsoft 365.

But capability is not the same as implementation. The organisations that get the most out of Intune are not the ones with the most licences — they are the ones that understand the architecture, build it in the right order, and treat device compliance not as an IT checkbox but as a live security signal feeding into every access decision across the enterprise.

• Enroll everything — you cannot secure what you cannot see. Unmanaged devices are your biggest risk surface.
• Build compliance policies before you build Conditional Access — sequence matters more than speed
• Treat MDE risk level integration as mandatory, not optional — it is automated incident response built into your access control layer
• Run all CA policies in report-only mode for at least 30 days — the sign-in logs will surprise you every time
• Dynamic groups are not a shortcut — they are the scalable architecture that makes everything else maintainable
• Co-management is a journey, not a cutover — slide workloads progressively, validate each phase before moving on

The next articles in this series go deep into each phase: a full Autopilot deployment lab, the Settings Catalog GPO migration guide, Endpoint Privilege Management for replacing local admin rights, and the MDE + Intune security operations workflow.

Upcoming in This Series