What MDM Does + Intune vs Jamf vs Kandji vs Workspace ONE

Every laptop, phone, and tablet that touches company data is a control surface you are expected to manage and prove. When an auditor asks "how do you ensure company laptops are encrypted, patched, and locked when idle?", the honest answer cannot be "we tell people to do it." It has to be "our mobile device management platform enforces it, and here is the report showing 98% of the fleet is compliant." Mobile Device Management — MDM — is the system that turns a written device policy into an enforced, queryable reality.

This lesson explains what an MDM actually does, walks through the control surface it gives you, and compares the four platforms you will encounter most often: Microsoft Intune, Jamf, Kandji, and VMware Workspace ONE. By the end you should be able to read an MDM compliance report the way an auditor does — and spot the gap between "enrolled" and "actually compliant."

What MDM actually is

An MDM is a management server that talks to an agent built into the operating system of each device. Apple, Microsoft, and Google all ship a native management framework — Apple's MDM protocol, Windows' MDM/CSP stack, Android Enterprise — and the MDM platform sends instructions over those frameworks. The device checks in on a schedule (and on demand), receives configuration, reports its state back, and obeys commands.

That gives you four broad capabilities:

• Configuration — push settings the user cannot override: Wi-Fi and VPN profiles, certificates, a required screen-lock timeout, disabled USB storage, a mandatory password complexity policy.
• Application management — install, update, and remove apps; deploy a managed app catalog; block unapproved software.
• Policy enforcement and compliance — define what "compliant" means (encrypted, passcode set, OS at or above a minimum version, not jailbroken) and continuously evaluate every device against it.
• Remote actions — lock a device, wipe it, retire it (remove company data only), or reset the passcode when an employee is offboarded or a laptop is stolen.

The compliance and remote-action capabilities are what make MDM a security and compliance tool rather than just an IT convenience. The encryption status, patch level, and lock policy of every device become data you can query and export — which is exactly what evidence collection requires.

The control surface, concretely

It helps to see how an abstract control becomes a concrete enforced setting. Take a single, ordinary requirement and trace it through:

Policy (written): "Company laptops must lock automatically after no more than 15 minutes of inactivity and require a password with at least 8 characters to unlock."

In the MDM, that becomes a configuration profile with two settings: maxInactivity = 15 minutes and minLength = 8. The MDM pushes the profile to every laptop in the "Corporate macOS" group. Each device applies it, the user cannot change it, and each device reports back "profile applied: yes." Now the control is:

• Enforced — not a request, a setting the user cannot disable.
• Measurable — the MDM shows how many devices have the profile applied.
• Evidenced — you can export the report as proof the control operates across the fleet.

That chain — written control → enforced profile → compliance report → exported evidence — is the heart of why GRC Engineers care about MDM. Multiply it across encryption, OS updates, firewall state, and app controls, and the MDM becomes the system of record for endpoint compliance.

WRITTEN CONTROL              MDM CONFIGURATION           DEVICE STATE            EVIDENCE
┌────────────────┐           ┌────────────────┐         ┌──────────────┐       ┌──────────────┐
│ "Laptops lock  │           │ Profile:       │         │ 412 devices  │       │ Compliance   │
│  after 15 min, │  ──────►  │ maxInactivity  │ ──────► │ applied      │ ────► │ report       │
│  8-char pass"  │  author   │ = 15           │  push   │ 6 pending    │ query │ exported as  │
│                │           │ minLength = 8  │         │ 2 failed     │       │ CC6 evidence │
└────────────────┘           └────────────────┘         └──────────────┘       └──────────────┘
                                                                │
                                                        the 6 + 2 are the
                                                        audit finding

Supervised vs unsupervised enrollment

Not all enrollment grants the same control, and this distinction trips up new GRC Engineers. On Apple devices in particular, supervision is what unlocks the stronger controls.

• Unsupervised / user-enrolled devices (typically personal/BYOD) accept a limited set of management: a managed app catalog, email config, the ability to remove company data. The user retains control of the device, and many restrictions simply cannot be enforced.
• Supervised / automated-enrollment devices (corporate-owned, enrolled through Apple Business Manager or Windows Autopilot) accept the full control surface: non-removable management, OS update enforcement, deep restrictions, activation lock management, and remote wipe of the entire device.

When an auditor tests whether you can enforce a control, the answer often depends on enrollment type. "We require disk encryption on all corporate laptops" is only credible if those laptops are supervised/automated-enrolled so the setting cannot be peeled off. Knowing which enrollment mode a fleet uses tells you which controls are actually enforceable versus merely requested.

The four platforms compared

There is no single "best" MDM — the right choice depends on the device mix and the existing identity stack. These four cover the large majority of what you will see.

A practical pattern in mid-size companies: Intune for Windows and as the Conditional Access hub, plus Jamf or Kandji for the Mac fleet, with both feeding device-compliance signals into the identity provider. As a GRC Engineer you do not need to administer these tools, but you must be able to map a control to "which platform enforces this, for which devices, and where is the report."

What an auditor reads in an MDM

When a SOC 2 or ISO 27001 auditor evaluates endpoint controls, they are usually looking for four things, all of which the MDM produces:

1. Coverage — what percentage of the known fleet is enrolled and managed? Unmanaged devices are a gap.
2. Compliance state — of the managed devices, how many pass each policy (encryption, passcode, OS minimum, screen lock)?
3. Enforcement, not request — are the settings pushed and locked, or merely recommended? Supervised/managed configuration is the difference.
4. Remediation and timeliness — when a device drifts out of compliance, what happens, and how fast? Auto-remediation or a documented manual process both work; silence does not.

These map cleanly to framework controls: SOC 2 CC6.1 (logical access and device protection), CC6.6/CC6.7 (protecting against threats and securing data on devices), and ISO 27001 Annex A.8 controls covering user endpoint devices and configuration management. The same MDM report is reusable evidence across all of them — one of the highest-leverage artifacts in an endpoint program.

What to carry forward

MDM is the bridge between a device policy on paper and a device that actually behaves. It gives you configuration, app management, compliance evaluation, and remote actions — and it turns each of those into measurable, exportable evidence. The platform names matter less than the mental model: every device control you will ever audit lives as a setting in one of these consoles, with a compliance report attached.

In the next lesson you will watch an enrollment happen end to end — from a brand-new device to its first applied policy — so you can see exactly where the compliance evidence starts.