Endpoint Management

Your company hands out a laptop on day one. Three weeks later, when the laptop gets left in a cab, someone needs to be able to revoke it, confirm the disk was encrypted, and send a replacement with the same software stack already configured. That "someone" is MDM — mobile device management — and it's the muscle behind every "Access blocked: your device is not compliant" screen you've ever seen.

What an MDM actually does

An MDM server runs three loops, forever, against every enrolled device:

• Push — send a configuration profile ("turn FileVault on", "block USB mass storage", "install this VPN cert"). The device applies it and reports back.
• Enforce compliance — read the device's state and check it against a set of rules. If encryption is off, if the OS is three versions behind, if the firewall is disabled — flag the device as non-compliant.
• Act — when things go sideways, send remote commands: lock, locate, wipe (full or corporate-data-only), rotate the FileVault recovery key, rotate the BitLocker key.

All three are "best-effort, eventually consistent". Push isn't instant — a policy can take minutes to hours to land depending on whether the device is online, whether the user has dismissed the "Install this profile?" dialog, whether the push notification queue is backed up. Expect lag; never treat MDM as a real-time control plane.

User-assigned vs device-assigned enrollment

Who "owns" the policies on a given laptop?

• User-assigned — policies follow the user. Whoever logs in inherits the group's profiles. Common for shared iPads, training labs, hot-desk setups. Nice ergonomically, bad for keeping long-lived machine state (e.g. a VPN cert tied to one user).
• Device-assigned — policies are stamped on the hardware. The laptop has its own identity separate from whoever's typing. This is the default for corporate-issued MacBooks and ThinkPads because it gives IT a stable target even when the user changes.

Most real fleets are a mix — device-assigned for the baseline config, user-assigned layered on top for app entitlements.

Configuration profiles vs compliance policies

They look identical in the UI and they both live in the same admin console, but they do opposite things. They're two sides of the same coin:

• A configuration profile is a push. It sets a value on the device. "encryption = on", "proxy server = corp-proxy.internal", "min passcode length = 8". The MDM writes, the device applies.
• A compliance policy is a check. It reads a value off the device and decides pass/fail. "encryption must be on", "OS version must be ≥ 14.0", "firewall must be enabled".

Pair them: a push to turn encryption on, and a separate check that encryption is on. Real deployments keep them loosely coupled because the push can fail silently (user clicks "Not now" on the profile prompt) while the compliance rule still catches the gap.

What non-compliant actually gates

Non-compliant doesn't mean "wiped" — it means "blocked from corp resources". The muscle behind that is conditional access:

• Entra ID (née Azure AD) refuses to issue an access token for Outlook/Teams/Salesforce until the device reports compliant.
• Okta's Device Trust does the same for any SAML/OIDC app behind the Okta gateway.
• Google Workspace has Context-Aware Access policies tied to device posture.

The chain is always: MDM says non-compliant → identity provider refuses a token → app denies the request. Recomply the device and the next token mint works. That's why fixing a compliance failure is urgent — the user can't get into email until it lands.

Common policy categories

Nine out of ten policies fall into one of these buckets:

Category	Example rules
Encryption	FileVault (macOS), BitLocker (Windows), device-wide encryption (iOS/Android)
OS version	Minimum version, maximum version (for staged rollouts)
Firewall	On/off, specific port allow-lists
Password / passcode	Min length, complexity, rotation period, max wrong attempts before wipe
App inventory	Must-have apps, banned apps, jailbreak/root detection
Network	VPN config, trusted Wi-Fi profiles, proxy PAC
Update cadence	Auto-install major updates, defer 14 days, etc.

A useful heuristic: one rule per policy key. When a device fails, the remediation becomes actionable — "encryption: fail" points at one push. Stuff five rules into one policy and you lose that signal.

Real products

The pseudo-CLI in the playground is intentionally generic so the ideas transfer. The actual tools you'll work with:

• Microsoft Intune — Windows + cross-platform, deeply tied to Entra ID.
• Jamf — macOS + iOS, the incumbent Apple-shop choice.
• Kandji — macOS-first, modern UX, "zero-touch" onboarding a strong point.
• Mosyle — Apple-fleet MDM, popular with smaller orgs and schools.
• Workspace ONE (VMware / Omnissa) — cross-platform, heavyweight, big in regulated industries.
• Google Workspace / Endpoint Management — Chrome OS + Android natively, macOS and Windows through the Google Credential Provider.

All of them expose similar primitives — a catalog of policies, a device inventory, a Smart Group / Dynamic Group abstraction, a compliance dashboard — with different paint.

BYOD vs corporate-owned

The threat model diverges depending on who owns the device:

• Corporate-owned — full device management, full wipe, every app supervised. The device is a company asset.
• BYOD (bring-your-own-device) — the MDM manages a corporate workspace on the user's personal device. iOS "User Enrollment", Android "Work Profile", macOS "User Enrollment". Wipe = remove the corp partition only; personal photos stay.

Mixing them in one fleet is common and fine, but don't push BYOD users to the same policies as corporate laptops — you'll trigger user revolts when "rotate FileVault key" wipes the family photos.

Gotchas

A handful of classic MDM foot-guns:

• Locking users out of their own devices. A passcode policy too strict, or a screen-lock timer too aggressive, turns the laptop into a brick the user can't get in to re-authenticate. Test every passcode policy on a sacrificial device first.
• Over-aggressive patching. "Install macOS 15 within 3 days" works great until a critical Cisco AnyConnect update breaks a third of the fleet. Stage rollouts.
• Supervised-only profiles on unsupervised iOS. Some restrictions (e.g. "disable AirDrop") only apply if the device was supervised at enrollment — otherwise the push silently no-ops. The compliance rule still flags the device, the config profile does nothing, and you spend a week debugging before remembering this.
• Deleting a policy that fixes a compliance rule. If you push encryption via a config profile and delete that profile, the device doesn't un-encrypt automatically, but the enforcement is gone — a user turning it off will stick.
• Treating MDM as a security boundary. It's a control plane, not a hard perimeter. A motivated attacker who roots a device can lie about compliance state. MDM is one signal; pair it with app-level checks.

Playground

The console on the next tab is a toy MDM: ten devices across two OUs, five policies, a compliance headline at the top. Pick a device, pick a policy, assign it, advance a tick, and watch compliance flip. The devices in the seed fleet are deliberately half-broken — each one teaches a different remediation.

Visualizer

The compliance matrix paints every (device, policy) cell green, red, or grey. It's the exact shape of the dashboard widget every MDM ships. When rows turn red on a Tuesday morning, that's the picture.