> For the complete documentation index, see [llms.txt](https://docs.siit.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.siit.io/integrations/mdm.md).

# MDM

### Why connect your MDM

Your MDM is the source of truth for every laptop, phone, and tablet in your fleet. Connecting it to Siit means:

* **A live device inventory.** Laptops, phones, tablets, and peripherals from your MDM appear in Siit's Equipment inventory with model, OS, serial number, owner, and last check-in.
* **Device context on every request.** When a request comes in, agents see the requester's assigned devices directly on the ticket — no copy-pasting serial numbers between tabs.
* **One-click remote actions from any request.** Lock, wipe, and open in MDM from the request side panel. No more juggling three consoles to resolve a lost-laptop incident.
* **Workflow-driven device lifecycle.** Use MDM actions in any workflow — automatic locks on reported theft, wipes on offboarding, reassignments during employee moves.
* **Audit and traceability.** Every MDM action triggered from Siit is recorded on the request timeline, so you always know who did what and why.

### What Siit syncs from your MDM

By default, Siit imports:

* **Devices** — model, serial number, OS + version, asset tag, MDM device ID
* **Ownership** — which user the device is assigned to
* **Status** — enrolled, in service, reserved, lost, retired
* **Last check-in** — when the device last reported to MDM
* **Lifecycle events** — enrollment, un-enrollment, ownership change

Devices are matched to people in Siit through the assigned user's email, so the full picture (requester → apps → devices) is available on every request.

### Supported MDM platforms

Siit integrates natively with the four most common MDM platforms. Each one follows the same connection pattern — install, authorize, pick the scope — but the exact steps and capabilities vary by platform.

* **Jamf** — for fleets standardized on Apple. Syncs devices and exposes Lock, Wipe, and Open in Jamf Pro actions.
* **Iru (formerly Kandji)** — modern Apple MDM. Full device sync with Lock, Wipe, and Open in Iru actions.
* **JumpCloud** — for teams using JumpCloud for device management in addition to (or instead of) identity. Syncs devices with Lock, Wipe, and Open in JumpCloud actions.
* **Microsoft Intune** — for mixed Windows / macOS / mobile fleets managed through Microsoft Endpoint Manager. Syncs devices with Lock, Wipe, and Open in Intune actions.

Using a different MDM (Mosyle, Hexnode, Workspace ONE, etc.)? Reach out via in-app chat — we're actively expanding MDM coverage and are collecting interest.

### What each integration covers

| Capability                          | Jamf | Iru (Kandji) | JumpCloud | Intune |
| ----------------------------------- | ---- | ------------ | --------- | ------ |
| Device directory sync               | ✓    | ✓            | ✓         | ✓      |
| Ownership sync (user → device)      | ✓    | ✓            | ✓         | ✓      |
| Lock device                         | ✓    | ✓            | ✓         | ✓      |
| Wipe device                         | ✓    | ✓            | ✓         | ✓      |
| Open device in MDM console          | ✓    | ✓            | ✓         | ✓      |
| Available in the request side panel | ✓    | ✓            | ✓         | ✓      |
| Available in workflows              | Soon | Soon         | Soon      | Soon   |
| Available for IT Agent              | Soon | Soon         | Soon      | Soon   |

### How the sync works

* **Initial import** — all enrolled devices and their assignments are imported the first time you connect.
* **Continuous sync** — Siit refreshes device data automatically every few hours, so ownership and status stay current.
* **Real-time actions** — Lock, Wipe, and other actions triggered from Siit execute immediately in the MDM.
* **Matching** — devices are linked to people in Siit via the assigned user's email. Unassigned devices still appear in inventory but aren't attached to a requester.

### Using MDM actions in the side panel

The fastest way to use an MDM integration is from the request side panel. On any request, the **Devices** section shows the requester's assigned devices. One click gives you:

* **Assign** — assign or reassign a device to a user.
* **Lock** — remotely lock the device (useful for lost or stolen devices).
* **Wipe** — remotely wipe the device (for confirmed loss, theft, or offboarding).
* **Open in MDM** — deep-link into the full device record in Jamf, Iru, JumpCloud, or Intune.

Every action is logged on the request timeline, and sensitive actions can require an explicit confirmation step.

### Connecting an MDM

Each MDM tool has its own connection flow, but the pattern is the same:

1. Go to **Settings → Integrations** and find your MDM in the library.
2. Authorize the connection — typically via an API key (Jamf, Iru, JumpCloud) or OAuth / app registration (Intune via Microsoft Graph).
3. Review the initial device import and scope (some customers want only corporate-owned devices, not BYOD).
4. Map device types to Siit's Equipment types (Computer, Smartphone, Tablet, Other) if not auto-detected.
5. Test by running a lock or open-in-MDM action from a sample request.

### Tips

* **Use a dedicated service account** where possible (e.g., a "Siit Integration" API key in Jamf). The integration inherits that account's permissions, and a service account survives admin turnover.
* **Gate Lock and Wipe behind approvals.** These actions are irreversible for the device owner. A quick manager approval in Slack adds five seconds and prevents a bad Monday.
* **Pair MDM with HRIS for full lifecycle control.** Day-1 assignment and Day-N wipe become fully automated once both are connected.
* **Keep Siit's Equipment records in sync as the source of truth for employees.** Siit is the friendly, employee-facing surface; the MDM is the technical execution layer. Both should tell the same story.