Back to All Cheatsheet Libraries cheatsheets

Rippling MDM

Device management driven by the HR record — hiring provisions the laptop and accounts, termination reclaims all of it automatically.

A different premise: the HR record is the source of truth

Every other MDM on this list starts from the device. Rippling starts from the employee. Because it's an HRIS first — payroll, benefits, onboarding — the device module inherits an authoritative answer to "who works here, in what role, starting when." Hiring someone triggers the laptop, the accounts, and the app access as one workflow. Terminating them reclaims all three.

That's the entire value proposition, and it's genuinely different. It's also why this page reads differently from the others — Rippling MDM is a module inside a platform, not a standalone device-management product.

Concept What it is Notes
Employee recordThe central object. Role, department, location, start and end dates.Everything else — device, accounts, app access — hangs off this rather than being managed separately.
Workflow automationRules triggered by HR events: hired, role changed, department transferred, terminated.This is the product. Device actions are one output among several.
Device management (MDM)Enrollment, configuration profiles, app deployment, encryption enforcement, remote lock and wipe.Covers the mainstream cases. Shallower than the specialists on platform-specific depth.
Identity / SSORippling can act as the identity provider, or integrate with an existing one.Account provisioning and deprovisioning across SaaS apps is tied to the same employee record.
Inventory & procurementAsset tracking, plus optional device purchasing and drop-shipping to new hires.Genuinely useful for distributed teams — the laptop arrives at the employee's home already enrolled.
App managementSaaS licence assignment and revocation driven by role.Reclaiming unused SaaS seats on termination is a real, measurable cost saving.

Onboarding and offboarding as one automated flow

The problem this solves is real: in most organisations, IT finds out about a new hire late and about a departure later still. Orphaned accounts and unreturned laptops are the normal outcome. Tying device actions to the HR record removes the handoff entirely.

1

Hire is entered once, in HR

Role, department, location, and start date. No separate IT ticket, no spreadsheet handoff — this is the trigger for everything downstream.

2

Device is procured and pre-enrolled

Order through Rippling or use existing stock. Either way the device is registered to your MDM and, for Apple hardware, assigned in Apple Business Manager so it zero-touch enrolls on first boot.

3

Role determines the configuration

An engineer and a salesperson get different app sets and access. Because role lives on the employee record, this is a rule rather than a manual decision each time.

4

Accounts and SaaS access provision in parallel

Email, SSO, and application seats are created from the same trigger. The new starter has a working laptop and working accounts on day one rather than day four.

5

Role changes re-evaluate access automatically

A transfer between departments adjusts app access without anyone remembering to raise a ticket. This is where access creep usually happens, and where automation pays off quietly.

6

Termination triggers a single coordinated shutdown

Accounts disabled, SaaS seats reclaimed, device remotely locked or wiped, and return logistics initiated — all from the HR event. This is the strongest argument for the model. Offboarding is where most organisations leak both access and hardware.

Get the offboarding sequence right
  • Order matters. Wiping a device before backing up local data destroys work product. Ensure data retention runs first.
  • Distinguish remote lock from wipe. Lock preserves the device pending physical return; wipe is irreversible.
  • For a device that won't be returned, lock plus Activation Lock bypass retrieval is the right order — clearing Activation Lock after a wipe is much harder.
  • Disable accounts before announcing the departure, not after. This is a security control, not an administrative formality.
  • Test the full offboarding workflow on a dummy employee record before trusting it with a real termination.
Rippling MDM fits when…
  • You already run Rippling as your HRIS. This is close to a precondition — the value is the integration, and the device module rarely justifies adopting the whole platform on its own.
  • You're a distributed or remote-first company where drop-shipping pre-configured laptops matters.
  • Headcount is growing fast enough that manual onboarding is genuinely painful.
  • Offboarding hygiene is a known weakness — orphaned accounts, unreturned hardware, unreclaimed SaaS seats.
  • Your device requirements are mainstream: encrypt, configure, deploy standard apps, wipe on exit.
Look elsewhere when…
  • You use a different HRIS. Without that integration you're evaluating a mid-tier MDM against specialists, and it won't win.
  • You need deep macOS management — Jamf or Mosyle.
  • You need Conditional Access tied to device compliance — Intune.
  • You manage servers, kiosks, or rugged devices — NinjaOne or Hexnode.
  • Viable hybrid: use Rippling for the HR-triggered lifecycle automation and a specialist MDM for actual device configuration, connected via API.

Gotchas

Concentration risk is real
  • Payroll, identity, app access, and device control in one platform means one compromised admin account is an extraordinarily large blast radius.
  • Enforce MFA on every administrative account, and use least-privilege roles — HR staff do not need device-wipe rights.
  • Review the audit log regularly, particularly for permission changes and device actions.
  • Understand the vendor's own security posture and incident history before consolidating this much into one place.
Bad HR data becomes bad device actions
  • If the employee record drives automation, an incorrect termination date can wipe a working employee's laptop.
  • Build a delay or approval step into destructive workflows rather than firing them instantly on an HR event.
  • Data-quality problems that were previously cosmetic become operational once automation depends on them.
Apple's rules still apply
  • APNs certificate expires annually; ABM/ADE and VPP tokens likewise. Renew with the same Apple ID.
  • Activation Lock is still the main cause of unusable returned Macs. Retrieve bypass codes before wiping, and consider disabling Find My on corporate hardware by policy.
  • Secure Token and Bootstrap Token behaviour on Apple silicon is unchanged — see macOS.
Consolidation makes exit harder
  • Leaving means untangling HR, payroll, identity, and device management simultaneously — far harder than swapping one MDM for another.
  • Confirm you can export employee, device, and configuration data in a usable format.
  • Model the switching cost honestly before consolidating, not afterwards.

Resources

Rippling device management Product overview for the MDM module and how it ties to the HR platform. rippling.com Rippling help centre Setup guides for enrollment, workflows, and offboarding automation. help.rippling.com Rippling API For the hybrid pattern — HR events driving a specialist MDM via integration. developer.rippling.com Apple Platform Deployment ADE, supervision, and Activation Lock — vendor-independent reference. support.apple.com MDM Fundamentals Vendor comparison and the platform-by-platform enrollment reference. build.ty1er.com macOS Mac Admin tabs Activation Lock checks, management-state commands, and onboarding scripts. build.ty1er.com

Rippling MDM is a module within Rippling's HR platform rather than a standalone product. Its value depends almost entirely on already using Rippling as your HRIS — see MDM Fundamentals for how it compares to dedicated MDMs.