Fleet, MDM & Device Trust Deep Dive
Zero-touch provisioning across macOS, Windows, Linux, ChromeOS
Zero-touch provisioning
After this you can design hands-off device setup from unboxing to ready-to-work.
A new hire opens the box, powers on the laptop, signs in once and ten minutes later has every app, policy and access grant they need - and no one in IT ever touched the machine. That is the bar Cursor's loop will probe, because it is the difference between IT-as-engineering and IT-as-shipping-and-handling.
Interactive diagram. Tab through its regions; each focused region shows its detail in the panel below.
The IdP sign-in is the gate: it fuses the device record and the access grants into one identity event instead of two reconciled tracks.
Zero-touch provisioning means the device configures itself on first boot by phoning home to your MDM, which knows who the device belongs to before it has even shipped. The manual alternative - imaging machines, hand-installing apps, walking a new hire through setup - does not survive a hypergrowth headcount curve with a tiny IT team. So this section is really about removing yourself from the critical path.
The enrollment program per OSvendor-bound, not optional
Each platform has a first-party program that lets a device auto-enroll the moment it touches the internet, with no escape hatch for the user. Know the name and the binding mechanism for each.
- OS
- macOS / iOS
- Enrollment program
- Apple Business Manager + Automated Device Enrollment (ADE)
- How the device gets bound to you
- Apple ships hardware tied to your ABM org by reseller/Apple order; device checks ADE on activation and is force-enrolled to your MDM
- OS
- Windows
- Enrollment program
- Windows Autopilot (via Entra + Intune or partner MDM)
- How the device gets bound to you
- OEM or you register the hardware hash; OOBE pulls the Autopilot profile and joins the device to your tenant
- OS
- ChromeOS
- Enrollment program
- Chrome Enterprise zero-touch enrollment
- How the device gets bound to you
- Reseller flags the device for forced enrollment into your Google Admin org at first boot
- OS
- Linux
- Enrollment program
- No native MDM program; bootstrap via imaging + a config-management agent
- How the device gets bound to you
- Provisioning script or golden image enrolls the host into Ansible/Fleet/osquery on first boot
| OS | Enrollment program | How the device gets bound to you |
|---|---|---|
| macOS / iOS | Apple Business Manager + Automated Device Enrollment (ADE) | Apple ships hardware tied to your ABM org by reseller/Apple order; device checks ADE on activation and is force-enrolled to your MDM |
| Windows | Windows Autopilot (via Entra + Intune or partner MDM) | OEM or you register the hardware hash; OOBE pulls the Autopilot profile and joins the device to your tenant |
| ChromeOS | Chrome Enterprise zero-touch enrollment | Reseller flags the device for forced enrollment into your Google Admin org at first boot |
| Linux | No native MDM program; bootstrap via imaging + a config-management agent | Provisioning script or golden image enrolls the host into Ansible/Fleet/osquery on first boot |
macOS, Windows and ChromeOS all have a true zero-touch path; Linux you assemble yourself, which is worth saying out loud rather than pretending it has an ADE equivalent.
The end-to-end flowunboxing to productive
- 1Device is bound before it ships. Purchased through ABM/Autopilot/Chrome zero-touch so it appears in your console pre-assigned to the org, ideally pre-assigned to the hire.
- 2First boot enrolls automatically. The device contacts the MDM during setup, with no skip option for the user and pulls its assigned blueprint or profile.
- 3Config and apps apply. Disk encryption, Wi-Fi/VPN, security baseline and the role's app set install before the user reaches the desktop.
- 4User authenticates through the IdP. Sign-in uses Okta/Entra so the local account, MDM identity and SSOSingle Sign-On. One company login (usually via SAML or OIDC) instead of a separate password per tool. identity are the same person - not three disconnected records.
- 5Access provisions in parallel. Group membership from the IdP grants SaaS and the user lands productive with zero IT hands on the machine.
The senior move is binding device assignment and access provisioning into one event. When the laptop enrolls and the user signs in via the IdP, the same identity drives both the device record and the SaaS grants - so onboarding is one coordinated workflow, not a device track and an access track that someone has to reconcile later. This is also what lets offboarding be one clean reverse of the same event.
The metric that proves it worksday-one time-to-productive
- Day-one time-to-productive
- Minutes from first boot to having apps + access, not hours or a help-desk ticket
- IT touch count
- Zero hands-on the physical machine for a standard hire
- Drift on day one
- Device is compliant the moment it's handed over, not after a follow-up pass
- Failure mode
- A broken enrollment is visible in the console, not discovered by a confused new hire
This is the single most likely scenario prompt for the systems-design screen: "Design onboarding so a new hire is productive on day one." Answer with the flow above, but anchor it on the identity tie-in and the time-to-productive metric. Then name one real failure mode - a device bought outside ABM that never auto-enrolls - and how you'd catch it. Showing you've thought about the gap, not just the happy path, is the signal.
Takeaway. Zero-touch means the device binds to your org before it ships, force-enrolls on first boot via ABM/Autopilot/Chrome zero-touch and provisions access through the IdP in the same event - measured by day-one time-to-productive with zero IT hands on the machine.
Self-check
QA candidate describes zero-touch provisioning as "we image the laptops ahead of time and ship them pre-configured." Why is that not actually zero-touch and what's the better answer?
Modern MDM platforms
After this you can demonstrate hands-on depth with Kandji/Jamf-class tooling.
The job description names Kandji, Jamf or similar and the practical round leans hands-on. Interviewers can tell within two questions whether you've actually lived in an MDM console or only read about one - so depth on at least one platform is non-negotiable.
Modern MDM is built on the OS vendor's management protocol: Apple's MDM protocol for macOS/iOS, the Windows MDM/CSP stack for Windows, Google's policy API for ChromeOS. The platform (Kandji, Jamf, Intune) is the brain that decides what to push; the protocol is how it pushes. Knowing that separation lets you talk credibly about any platform even when Cursor uses one you haven't.
The core primitives you must know coldthe nouns of any MDM
Signed payloads the OS enforces: Wi-Fi, VPN, certificates, FileVault/BitLocker, restrictions, screen-lock.
Declarative - the device converges to the stated state and reports back.
Kandji blueprints and Jamf smart groups: dynamic membership by attributes (OS version, department, model).
A device lands in the right policy set automatically, no manual assignment.
Push managed apps and updates silently; pin versions for security-critical tools.
Handle both store and custom/in-house packages.
Policies that detect drift (encryption off, OS behind) and auto-remediate or flag.
This compliance state becomes the device-trust signal in the next section.
Console clicks vs. the APIwhere IT-as-engineering shows up
A help-desk admin configures MDM by clicking through the console. An engineer treats the console as the manual fallback and drives the platform through its API - because anything you do twice should be code. This distinction is exactly the automation-first bar Cursor is testing for.
- Task
- Enroll a batch of devices
- Help-desk way
- Add each serial in the console UI
- Engineer way
- Script the bulk import and assignment against the MDM API from a CSV or ABM sync
- Task
- Report on fleet compliance
- Help-desk way
- Read the console dashboard, screenshot for audit
- Engineer way
- Pull the device API on a schedule into a sheet/DB; generate audit evidence automatically
- Task
- Remediate a misconfig
- Help-desk way
- Find affected devices manually, re-push by hand
- Engineer way
- Detect via API/query, push a remediation script to the matched smart group, verify it converged
- Task
- Onboard a new app
- Help-desk way
- Upload + assign in the UI each time
- Engineer way
- Version the deployment config in git; apply via API so it's reviewable and reproducible
| Task | Help-desk way | Engineer way |
|---|---|---|
| Enroll a batch of devices | Add each serial in the console UI | Script the bulk import and assignment against the MDM API from a CSV or ABM sync |
| Report on fleet compliance | Read the console dashboard, screenshot for audit | Pull the device API on a schedule into a sheet/DB; generate audit evidence automatically |
| Remediate a misconfig | Find affected devices manually, re-push by hand | Detect via API/query, push a remediation script to the matched smart group, verify it converged |
| Onboard a new app | Upload + assign in the UI each time | Version the deployment config in git; apply via API so it's reviewable and reproducible |
You don't have to never touch the console - you have to reach for the API by default and keep the config in version control.
Self Service as the internal-customer experiencetreat employees as users
Kandji Self Service and Jamf Self Service give employees a curated app catalog they can install themselves - printer drivers, the design tool, a VPN client - with no ticket. It is the most visible part of IT for most of the company and it directly serves the JD's internal-customer-empathy theme.
"I'd be candid: I've run Jamf at config level - smart groups, profiles, extension attributes and the classic API for reporting. I haven't run Kandji's blueprint model in production, but the primitives map cleanly and because I drive MDM through its API rather than the console, ramping on a new platform is mostly learning its endpoints and policy objects. I'd expect to be productive in it within the first week."
Do not bluff platform depth. If you've only used one MDM, say which one, go deep on it and frame the ramp honestly - Cursor's flat, talent-dense culture rewards calibrated self-assessment and punishes overclaiming. "I know all of them" reads as a tell that you know none of them well.
Takeaway. Know one MDM at config level - profiles, blueprints/smart groups, app deployment, compliance - and drive it through its API with config in version control, because reaching for code over the console is the IT-as-engineering signal.
Self-check
Mixed-platform fleet management
After this you can reason about managing macOS, Windows, Linux and ChromeOS together.
Cursor's fleet is not one OS. The JD calls out macOS, Windows, Linux and ChromeOS by name and the fastest way to look junior is to be a single-platform admin who treats the other three as someone else's problem.
Each OS exposes a different management surface, so there is no single tool that does all four well. The skill is knowing where to unify and where to specialize: unify the intent (the compliance baseline every device must meet) and specialize the mechanism (the per-OS tooling that enforces it).
The management model per OSprotocol, tooling, agent
- OS
- macOS
- Management primitive
- Apple MDM protocol + profiles + scripts
- Typical tooling
- Kandji, Jamf
- Where it gets hard
- Keeping up with Apple's yearly changes and the shift to declarative device management
- OS
- Windows
- Management primitive
- Windows MDM/CSP + (sometimes) GPO
- Typical tooling
- Intune, partner MDM
- Where it gets hard
- Legacy GPO/AD overlap and a deeper, messier policy surface than macOS
- OS
- ChromeOS
- Management primitive
- Cloud policy via Google Admin
- Typical tooling
- Google Admin console / API
- Where it gets hard
- Genuinely simple - the risk is forgetting it exists in your posture model
- OS
- Linux
- Management primitive
- Config management + agents (no true MDM)
- Typical tooling
- Ansible, osquery, Fleet, MDM-lite
- Where it gets hard
- Heterogeneous distros, sudo/root realities and no force-enroll equivalent
| OS | Management primitive | Typical tooling | Where it gets hard |
|---|---|---|---|
| macOS | Apple MDM protocol + profiles + scripts | Kandji, Jamf | Keeping up with Apple's yearly changes and the shift to declarative device management |
| Windows | Windows MDM/CSP + (sometimes) GPO | Intune, partner MDM | Legacy GPO/AD overlap and a deeper, messier policy surface than macOS |
| ChromeOS | Cloud policy via Google Admin | Google Admin console / API | Genuinely simple - the risk is forgetting it exists in your posture model |
| Linux | Config management + agents (no true MDM) | Ansible, osquery, Fleet, MDM-lite | Heterogeneous distros, sudo/root realities and no force-enroll equivalent |
Three of the four have a real MDM story; Linux you manage like a server fleet, which is a feature if you already think in config management.
Unify intent, specialize mechanismthe architecture that scales
- One compliance baseline, written once. Disk encryption on, screen-lock under N minutes, OS within N versions of latest, firewall on, a known agent present - this is the same policy intent on every OS.
- Per-OS enforcement, mapped to that baseline. FileVault on macOS, BitLocker on Windows, LUKS/dm-crypt on Linux, default encryption on ChromeOS all satisfy the same "disk encrypted" requirement.
- One place to read posture. Normalize each platform's compliance signal into a single fleet view so you can answer "is the whole fleet compliant" without four separate consoles.
- One identity across all four. Every device ties back to the same IdP user so a leaver event reaches every platform at once.
Linux: manage it like infrastructurethe honest reality
There is no ABM for Linux laptops. You bootstrap with a golden image or a provisioning script, enroll the host into Ansible or a Fleet/osquery agent and treat configuration as code you converge on a schedule. Posture comes from the agent reporting back, not from an MDM compliance engine - and saying that plainly beats pretending Linux has a zero-touch program it does not.
ChromeOS is the easiest fleet to manage and the easiest to leave out of your zero-trust story. It enrolls and applies policy through Google Admin cleanly, but its device posture still has to feed the same access decisions as everything else. Naming ChromeOS unprompted - even just "and Chrome devices fold into the same posture model via Google Admin" - signals real breadth.
When you hit the edge of your direct experience, narrate the model instead of going quiet. "I've run macOS and Windows hands-on; for Linux I'd lean on config management since there's no native MDM and ChromeOS folds into Google Admin" shows the breadth Cursor wants and the honesty its culture rewards. Demonstrating a strategy to cover a gap beats pretending the gap isn't there.
Takeaway. Unify the compliance intent across all four platforms and specialize the mechanism per OS - and be honest that Linux is config-management-driven and ChromeOS rides Google Admin, since breadth plus calibrated honesty is what reads as senior.
Self-check
QHow should you handle a mixed fleet where one OS (say, Linux) has no true MDM program, while keeping a single compliance standard across everything?
Device trust as a zero-trust signal
After this you can connect endpoint posture to access decisions.
Managing devices is table stakes. The reason fleet work matters at Cursor is that device posture becomes an input to every access decision - a healthy, compliant, managed device is the price of admission to sensitive systems and a non-compliant one gets blocked or challenged.
This is where the JD's "zero-trust architectures with Security and Engineering" line lands on the endpoint domain. Zero trust assumes no implicit trust from network location, so it asks three questions on every request: who is this, what device are they on and is that device healthy? MDM is what makes the second and third answerable.
Three signals, evaluated togetherdefense-in-depth, not any one alone
Who is this, proven via the IdP - SSOSingle Sign-On. One company login (usually via SAML or OIDC) instead of a separate password per tool., MFA, passwordless.
Necessary but not sufficient: a valid login from an unmanaged box is still a risk.
Is this a managed, compliant, healthy endpoint?
Encryption on, screen-lock set, OS patched, MDM-enrolled, no malware flag.
Where and how - impossible travel, risky IP, anomalous time.
Drives step-up challenges rather than a hard binary.
The point of defense-in-depth is that any single signal can be fooled. Stolen credentials defeat identity alone; a managed device in the wrong hands defeats device alone. Requiring identity AND device AND a sane context together is what makes the overall decision hard to bypass.
How posture actually gates accessMDM → IdP/ZTNA loop
- 1MDM evaluates compliance continuously. Each device reports encryption, patch level, screen-lock and enrollment state against the baseline.
- 2The compliance state syncs to the IdP/ZTNA. Okta/Entra or the ZTNA proxy reads device posture as a condition, often via a device-trust certificate or an MDM integration.
- 3Access policy consumes it. A compliant device on a managed user flows through; a non-compliant one is blocked or forced into a step-up challenge.
- 4Remediation reopens the door. The user fixes the gap (re-enables encryption, updates the OS), MDM re-marks them compliant and access restores without a ticket.
The technical building blockswhat proves a device is what it claims
- Device certificate
- MDM-issued cert proves the device is managed and is the specific enrolled device, presented to the IdP/ZTNA
- Hardware attestation
- Secure Enclave / TPM-backed proof the device and its keys are genuine and not spoofed
- Compliance checks
- Disk encryption on, screen-lock under threshold, OS at/above minimum patch level, MDM-enrolled
- Health signal
- No malware/EDR flag, no jailbreak/root, agent reporting recently - a device that went dark is suspect
Certificates and attestation answer "is this really a managed device"; compliance and health answer "and is it safe right now."
When asked to design zero-trust access, resist making it all about the IdP. Lead with the loop: "MDM owns the truth about device health, that posture syncs to the IdP/ZTNA as a condition and access requires identity plus a compliant device plus sane context - with a self-service remediation path so it strengthens security without slowing people down." That last clause maps directly to the JD's security-as-enabler theme and signals you partner with Security rather than fight the business.
Takeaway. Device posture from MDM is the second pillar of zero trust: sync compliance state to the IdP/ZTNA so access requires identity AND a compliant, healthy device AND sane context - with self-service remediation so the control enables rather than blocks the business.
Self-check
QA valid employee logs in with correct credentials and passes MFA, but from a personal laptop that was never enrolled in MDM. In a zero-trust model with device trust, what happens and why?
Endpoint lifecycle & offboarding
After this you can own devices across their full lifecycle including secure return.
A device is not done when it's provisioned. You own it from purchase order to secure disposal and the moment that tests whether you truly own it is offboarding - when a leaver's laptop has to be locked, wiped, recovered and accounted for, all tied to the same departure event that kills their access.
Inventory is the spine of this. If you don't know which devices exist, who has them and what state they're in, every other lifecycle step degrades into guesswork. So asset management is a source of truth, not a spreadsheet someone updates when they remember.
The full device lifecyclePO to disposal
- 1Procurement. Buy through ABM/Autopilot/Chrome so the device is born bound to your org and lands in inventory automatically.
- 2Enrollment. Zero-touch first boot applies the blueprint and assigns the device to a user.
- 3In-use management. Ongoing config, app updates, patch enforcement and continuous compliance reporting.
- 4Repair / swap. Track the loaner and the original; keep the user's access continuous and the inventory accurate through the swap.
- 5Retirement / disposal. Wipe to a verifiable clean state, remove from MDM and inventory and sanitize or certify destruction for compliance.
Offboarding as one coordinated eventdevice + identity, not two tickets
The leaver workflow from the identity domain and the device offboarding here are the same event seen from two angles. When HRIS marks someone terminated, identity deprovisioning and device action should fire together - not as a manual handoff where one half gets forgotten.
- Trigger
- HRIS marks leaver
- Identity action
- Disable IdP account, kill active sessions, revoke tokens
- Device action
- MDM flags the device for offboarding
- Trigger
- Standard departure
- Identity action
- Deprovision SaaS via SCIMSystem for Cross-domain Identity Management. A standard for automatically creating and removing user accounts when people join or leave./API, transfer data ownership
- Device action
- Remote lock; remote wipe on return; release MDM/ABM record on confirmed disposal
- Trigger
- High-risk / hostile exit
- Identity action
- Immediate session kill and credential reset
- Device action
- Immediate remote lock/wipe, don't wait for the hardware to come back
- Trigger
- Hardware recovered
- Identity action
- Confirm no lingering access remains
- Device action
- Verify wipe, re-image or retire, update inventory to returned/retired
| Trigger | Identity action | Device action |
|---|---|---|
| HRIS marks leaver | Disable IdP account, kill active sessions, revoke tokens | MDM flags the device for offboarding |
| Standard departure | Deprovision SaaS via SCIMSystem for Cross-domain Identity Management. A standard for automatically creating and removing user accounts when people join or leave./API, transfer data ownership | Remote lock; remote wipe on return; release MDM/ABM record on confirmed disposal |
| High-risk / hostile exit | Immediate session kill and credential reset | Immediate remote lock/wipe, don't wait for the hardware to come back |
| Hardware recovered | Confirm no lingering access remains | Verify wipe, re-image or retire, update inventory to returned/retired |
One trigger, two coordinated tracks - the failure you're guarding against is killing access but leaving the laptop live or wiping the laptop while a forgotten SaaS token still works.
Inventory and patch cadence as standing practicethe unglamorous half of the job
- Inventory as source of truth. Live counts, current assignment, compliance state and lifecycle stage per device - reconciled against MDM, not hand-maintained.
- Patch and vulnerability cadence. A regular rhythm for OS and critical-app updates across all four platforms, with deferral windows but a hard backstop so nothing rots unpatched.
- Audit-ready reporting. Encryption coverage, patch compliance and assignment reports that regenerate on demand for SOC 2 / ISO 27001 evidence.
- Reclaim and reuse. Recovered hardware re-enters the pool clean, so spend tracks headcount instead of drifting upward.
The classic offboarding gap is the unreturned remote-worker laptop. If your only offboarding plan assumes the device comes back to a desk, a remote leaver leaves a live, unwiped machine in the wild. The answer is remote lock/wipe tied to the leaver event plus a documented recovery-or-remote-destroy path - and saying so unprompted shows you've run real offboarding, not just read the runbook.
"Offboarded" is a claim until you confirm it. A mature process verifies each leaver: account disabled, sessions killed, SaaS deprovisioned, device locked/wiped and inventory updated - ideally as an automated check that flags any half-finished offboarding. An access review that surfaces a terminated employee with a still-active token is the exact finding a SOC 2 auditor lives for.
Takeaway. Own devices from PO to verified disposal with inventory as the source of truth and make offboarding one coordinated event where identity deprovisioning and device lock/wipe fire from the same HRIS trigger - then verify both actually completed.