Microsoft Intune: The Engine Room Behind Modern Device Management

There’s a version of Intune that most people know — the place where you push apps and enforce a PIN policy. Then there’s the real Intune: a three-engine platform that controls how devices are managed, how policies are enforced, and how identity and access decisions get made. This article is about the second version.

The Device Management Engine

MDM vs MAM — two very different levels of control

Before anything else, you need to understand this distinction because it determines the entire relationship between Intune and a device.

MDM — Mobile Device Management — means Intune has full control over the device. It can wipe it, enforce encryption, push certificates, restrict hardware features, and collect compliance data. The device is enrolled, Intune owns the management channel, and policies apply at the OS level.

MAM — Mobile Application Management — means Intune only controls specific apps, not the device itself. No enrollment required. Intune wraps the apps it manages with a policy layer: it can wipe corporate data from Outlook without touching personal photos, enforce copy-paste restrictions between managed and unmanaged apps, and require a PIN to open the app. The device stays personal. Intune stays out of it except at the app boundary.

Why does this matter in practice? MDM is for corporate-owned devices. MAM is your answer for BYOD — bring your own device scenarios where employees use personal phones to access corporate email. You get data protection without touching their personal life. In most enterprise environments you’ll run both, applied to different device populations.

Enrollment types — Corporate vs BYOD

Corporate enrollment gives Intune full MDM control. On Windows, this typically happens through Autopilot — the device ships to the employee, they power it on, it joins Azure AD automatically and Intune enrolls it without IT ever touching the hardware. On iOS, it’s Apple Business Manager with Automated Device Enrollment. On Android, it’s Android Enterprise with fully managed device enrollment.

BYOD enrollment is lighter. On mobile, users download the Company Portal app and enroll their personal device to get access to corporate resources. Intune applies MAM policies to corporate apps but respects the personal boundary. On Windows, BYOD typically means Azure AD Registered rather than Azure AD Joined — the device shows up in Entra ID but Intune’s control is limited.

The enrollment type you choose determines what you can see, what you can enforce, and critically, what you can wipe when something goes wrong.

Enrollment profiles and restrictions

Enrollment restrictions are Intune’s gatekeeping mechanism. Before a device even finishes enrolling, restrictions determine whether it’s allowed in at all. You can block personally owned devices entirely, restrict enrollment to specific OS platforms, set minimum OS version requirements, or limit the number of devices a single user can enroll.

Enrollment profiles go further on the configuration side — they define the out-of-box experience for Autopilot deployments, set the device naming convention, determine whether the setup wizard is shown or skipped, and assign the device to a group automatically on enrollment. On iOS and macOS via Apple Business Manager, profiles define whether the device is supervised (which unlocks the most restrictive management capabilities Apple allows).

Compliance policies — the bridge between device state and access

Compliance policies are what define what a “healthy” device looks like in your environment. Is BitLocker on? Is the OS patched to the minimum required version? Is the device jailbroken or rooted? Is there an approved antivirus running? Each of these is a compliance condition.

When a device meets all conditions, it gets a Compliant status in Intune. When it fails any condition, it’s Non-compliant. This status is synced to Azure AD / Entra ID and becomes a signal that Conditional Access policies can act on — which we’ll get to shortly.

Compliance policies also have a grace period mechanism. You can configure a device that falls out of compliance to remain compliant for a defined number of days before being marked non-compliant and losing access. This is important for patch compliance scenarios where you don’t want users blocked immediately because Windows Update is running.

Configuration profiles — shaping device behavior

If compliance policies define what a device must be, configuration profiles define what a device must do. They push settings directly into the OS: disable USB ports, configure Wi-Fi and VPN profiles, deploy certificates, set screen lock timeouts, enable BitLocker, configure Windows Defender settings, restrict access to the camera, enforce specific browser settings.

Two template types matter here. Endpoint Protection templates are pre-built profiles specifically for security settings — Defender configuration, firewall rules, BitLocker enforcement, exploit protection settings. These are the profiles that overlap with MDE configuration and are part of the MDE-Intune integration story.

Settings Catalog profiles are the more modern approach — a searchable catalog of thousands of individual settings across every OS platform, letting you build granular profiles from scratch. If you know the specific setting you want, Settings Catalog is usually the right tool.

Device lifecycle in Intune

Every device in Intune goes through a lifecycle: enrolled → managed → monitored → eventually retired or wiped. Understanding this lifecycle matters for operations.

Retire removes corporate data and management from the device while leaving personal data intact — appropriate for BYOD offboarding. Wipe performs a factory reset — appropriate for lost or compromised corporate-owned devices. Fresh Start is Windows-specific and reinstalls Windows while keeping the device enrolled. Autopilot Reset is similar but also re-applies Autopilot configuration.

Knowing which action to take in which scenario is something you need to have decided before the incident happens, not during it.

The Policy Enforcement Engine

Remediation scripts — proactive fixing, not just detecting

Remediations (previously called Proactive Remediations) are one of Intune’s most powerful and least talked-about features. They consist of a detection script and a remediation script, both PowerShell, that run on a schedule on enrolled devices.

The detection script checks for a condition — say, a specific registry key is missing, a service is stopped, a required software version isn’t installed. If the detection script exits with a non-zero code (unhealthy), Intune automatically runs the remediation script to fix it. You get a report in the portal showing which devices were healthy, which needed remediation, and which remediation failed.

This turns Intune from a passive configuration pusher into an active self-healing system. Want every device to automatically re-enable a Windows security feature if it gets turned off? Write a remediation. Want to detect and fix a misconfiguration before it becomes a compliance issue? Write a remediation.

Win32 app deployment

Win32 app deployment lets you package and deploy traditional Windows applications through Intune — .exe and .msi installers wrapped in the .intunewin format. This covers the vast majority of enterprise software that doesn’t come as a Store app.

The deployment model is pull-based: the Intune Management Extension (IME) on the device checks in, sees that an app is assigned, downloads it from Azure CDN, and installs it using the command line you specified. You define detection rules — registry keys, file presence, MSI product code — that Intune uses to verify whether the app is actually installed after the attempt.

Assignment matters here: Required means the app installs automatically, Available means users can install it from Company Portal on demand, and Uninstall removes it. You can target assignments at device groups or user groups, which means the same app can be required for one group and unavailable for another.

PowerShell scripts

For one-time configurations that don’t fit the profile model, Intune can run PowerShell scripts directly on devices via the IME. These run once (or every time, if configured) under SYSTEM context or signed-in user context. They’re useful for initial setup tasks, registry modifications, enabling features, or anything that doesn’t map cleanly to a settings catalog entry.

The key limitation: there’s no native output or return value visible in the portal beyond success or failure. For ongoing monitoring with output, use Remediations instead.

Update rings — Windows Update for Business

Update rings define when and how Windows feature updates and quality updates are deployed to device groups. You define a deferral period (how many days after Microsoft releases an update before your devices receive it), a deadline (how many days before the device installs it regardless of active hours), and restart behavior.

A mature update ring strategy uses at minimum three rings: a pilot ring (IT and early adopters, no deferral), a broad ring (most devices, 7–14 day deferral), and a critical ring (servers and sensitive systems, 21–30 day deferral). This gives you time to catch update-related issues before they hit your entire fleet.

Settings Catalog vs Administrative Templates (ADMX)

Administrative Templates in Intune are the MDM equivalent of Group Policy. They expose ADMX-backed settings — the same settings you’d configure via GPO in an on-premises environment — through the Intune interface. If you’re migrating from GPO-managed devices to cloud management, ADMX templates help you replicate existing policies in Intune.

Settings Catalog is the modern replacement. It’s a single, searchable interface covering thousands of settings across Windows, macOS, iOS, and Android. It supports the same ADMX-backed settings as Administrative Templates plus many more. For new policy builds, use Settings Catalog. For migrating existing GPOs, ADMX templates can be a useful bridge.

The Identity & Conditional Access Engine

Azure AD Join vs Hybrid Join vs Registered

These three states describe the relationship between a device and Azure AD (now called Microsoft Entra ID), and they have significant implications for what Intune can do.

Azure AD Joined means the device’s primary identity is cloud-only. It authenticates directly to Entra ID, not to an on-premises Active Directory domain. This is the modern, cloud-native state for corporate Windows devices. Intune has full MDM control. Single Sign-On to cloud resources works natively. No dependency on on-premises infrastructure.

Hybrid Azure AD Joined means the device is joined to both on-premises AD and Azure AD. It gets a computer object in both directories. This is the transitional state for organizations that still have on-premises AD but want cloud management capabilities. MDM enrollment through Intune is possible but requires additional configuration. Many organizations land here during their cloud migration and stay longer than intended.

Azure AD Registered is the lightest state — typically BYOD personal devices. The device has an entry in Entra ID tied to a user, but it’s not domain-joined or fully managed. MAM policies can apply. Conditional Access can require this state as a minimum trust level.

Conditional Access policies — where identity meets security

Conditional Access is the policy engine that decides whether a user and device combination should be allowed to access a resource. It sits in Azure AD / Entra ID and evaluates every authentication attempt against a set of conditions before granting or denying a token.

A Conditional Access policy has three parts: assignments (who and what — which users, which cloud apps, which platforms), conditions (additional signals — device platform, location, sign-in risk), and access controls (what to do — grant access, block, or require MFA, compliant device, hybrid join, or a combination).

The power of CA is in combining signals. You can say: “Allow access to Exchange Online only if the user is on a compliant Intune-managed device AND not connecting from a risky location AND not flagged as a risky sign-in by Identity Protection.” Any condition that fails, access is blocked — regardless of whether the password is correct.

Compliance state as a Conditional Access condition

This is where Intune and Conditional Access directly connect. When you create a CA policy and add “Require device to be marked as compliant” as a grant control, Entra ID queries the device’s compliance status from Intune at every authentication attempt.

If the device is Compliant in Intune, access is granted. If it’s Non-compliant — BitLocker disabled, OS out of date, jailbroken — access is blocked. The user sees a message telling them their device doesn’t meet requirements, with a link to Company Portal where they can see which specific conditions failed.

This creates a continuous enforcement loop: device falls out of compliance → Intune marks it non-compliant → Entra ID blocks access to cloud resources → user is motivated to fix the issue → device returns to compliant → access restored. No manual intervention required.

Device trust levels

Not all devices in your tenant carry the same trust. Entra ID implicitly assigns trust based on device state, and your Conditional Access policies should reflect this hierarchy.

A corporate Azure AD Joined device enrolled in Intune and marked compliant is your highest trust tier. It has a known hardware identity, is managed, is patched, has security baselines applied, and is verified at every authentication. A Hybrid Joined device is slightly lower — it has on-premises identity but cloud compliance verification may lag. An Azure AD Registered BYOD device is the lowest trust tier for corporate resources — it’s a personal device with app-level protection only.

Designing your CA policies around this hierarchy means your most sensitive resources — admin portals, finance systems, code repositories — require the highest trust tier. Less sensitive resources like the company intranet can allow lower trust. This is Zero Trust in practice: never trust implicitly, always verify based on the full signal set.

That’s the full Intune engine room. In Part 3, we close the loop — how MDE and Intune talk to each other, how device risk scores flow from the EDR layer into Conditional Access decisions, and what the full integration architecture looks like end to end.