The control plane for enterprise device management
Build device management into your product, or run your own fleet from the tools you already use. You describe what should be true. Smplify keeps it true across Apple, Windows and Linux, and handles the protocol work underneath.
›
Cells are a representative sample; the counts are exact.
Legacy MDM solved a problem from a decade ago
Most MDM products were designed to do one thing: get a configuration file onto a device. When posture changed once a quarter and a person clicked every button, that was enough.
Fleets are mixed now. Threats move in hours. And software has started making changes to infrastructure faster than anyone can review them. A tool built around pushing config has no answer for who approved a change, whether it still holds a week later, or what should happen when an agent asks to wipe something at 3am.
What stops the agent from unenrolling 500 devices?
Any platform that lets software act on your fleet has to answer this. Scoping a token limits which devices an agent can reach. It says nothing about whether a destructive action should wait for a person.
Approval Gates sit on the execution path itself, so they apply whether the request came from the console, the CLI, the API or an agent. A gated action doesn’t run. It becomes a signed request waiting on someone with authority to approve it. The rule underneath is one line: the requester can never be the approver. Agent identities are never granted approval privileges, so “the AI needs a human” is just what the rule produces. Nobody had to write a special case for robots.
Tiers are a property of the action, not the role. A tenant can tighten them, never loosen.
Bulk is one decision
Approving 500 unenrollments is one approval on the intent, not 500 clicks. Approver fatigue is what actually kills this control, so the design refuses to create it.
Scope changes the tier
One device unenrolled is routine. Fifty is not. Tiers tighten automatically on cardinality, on the production tag, on tenant class, even on time of day.
Collusion is watched
Self-approval is hard-blocked. Delegate pairs are blocked. A decision arriving from the requester’s own session or IP is flagged and forced to step-up auth.
The agent says what it is waiting for
A gated action can’t be a silent 202 the agent swallows. The MCP response carries a human-readable summary, the approver pool, and guidance on how to say it, so the wait state reaches the person who asked.
Agent, to the human“I tried to remove that profile but it needs Sarah’s approval — I’ve sent her the request and will let you know when it’s resolved.”
- Status
- pending_approval
- Notified
- 3 approvers · email, Slack, in-app
- Expires
- 24h, then audited as expired
Truly agentless. And still the full vendor spec.
Agentless usually means a thinner product. No binary on the endpoint, and quiet gaps where the vendor supports something the product never got around to.
Ours are schema-driven. The settings you can configure are generated from what Apple, Microsoft and the distros publish themselves, so coverage follows the vendor instead of our roadmap. Nothing of ours runs on the device, which means nothing of ours fights the agent you already ship.
Underneath, everything is a connector. You send one request. The platform works out which connector can carry it out for that device, that OS and that enrollment type, and runs it. You never pick a transport or write protocol code, and adding a platform doesn’t change anything you wrote.
- Source
- Vendor schemas, synced
- Coverage
- Whatever the platform exposes
- On device
- Nothing of ours
- Conflicts
- None with your existing agent
- ADE / ABM zero-touch enrollment
- Configuration profiles & Declarative Device Management
- VPP app management
- Account-driven BYOD enrollment
- CIS, DISA and NIST compliance baselines
- Enrollment and CSP configuration profiles
- BitLocker and Defender
- OS update management
- Remote lock, wipe and restart
- MSI application deployment
- Purpose-built declarative layer, not agent scripting
- Endpoints and servers, same model
- Firewall, SELinux, AppArmor, SSH, PAM, auditd
- Disk encryption and kernel parameters
- Drift auto-remediation, approval-gated
Linux is the one to look at twice. Nobody else ships declarative configuration for Linux; the incumbents ship scripts and read-only queries. Android is on the roadmap, and we don’t claim it yet.
Your workflow. Not our console.
Everything the platform does is reachable from the CLI and the API. Device management stops being somewhere you log into and becomes a step inside things you already run: CI, an onboarding script, an incident playbook.
Your engineers’ existing tools can drive it too. Point Claude Code, Codex or Cursor at the CLI or the MCP endpoint and it can run a fleet end to end. Approval Gates decide how far it gets on its own.
- Interface
- CLI · REST · MCP
- Drives
- Claude Code, Codex, any agent
- Runs in
- CI, runbooks, your product
- Console
- Optional
Watch the fleet and act on it, without leaving your tools
Device events stream out live in OCSF, so they land in your SIEM next to everything else you already correlate. That part is table stakes.
The useful part is that the stream goes both ways. An analyst who spots something can pull that device’s posture, then isolate it, lock it, or push a configuration change, from the same console they were already looking at. No second tab, no ticket to the endpoint team, no waiting until morning.
Anything destructive still goes through an Approval Gate. The audit trail shows who asked, who approved, and what actually ran.
- 01Alert firesYour SIEM correlates a Smplify event with everything else it sees.
- 02EnrichPull live posture for that device through the API or MCP.
- 03ActIsolate, lock, or reapply policy from the tool you are already in.
- 04ApproveDestructive steps wait for a second person. Everything is logged.
Multi-tenant for real, not teams in one database
A lot of products call a label on a group of devices multi-tenancy. Once you actually need customers isolated from each other, that turns into one deployment per customer, forever.
A real hierarchy
PARTNER → CUSTOMER, with an isolated database per tenant. Manage down the tree; approvals and scope respect every hop.
Privilege-grade RBAC
Custom roles and fine-grained privileges, not a fixed set of seats. A junior admin can request what a senior admin must confirm.
Built into your product
Your customers use your product. Smplify is the device management running inside it, reached through your own interface, on your own terms.
Separation of duties as a control, not a runbook
SOC 2 CC6 and CMMC L2 AC.L2-3.1.4 both expect separation of duties on privileged operations. Most platforms satisfy that with documentation and process. Auditors would rather see the platform enforce it and hand them the log.
- Audit
- Every request, decision, expiry and replay is immutable and hash-chained per request for tamper evidence.
- SIEM
- Events map to OCSF and stream to your own destination. Break-glass is always alertable.
- Break-glass
- Grantable, seeded to zero principals, and force-disabled for CMMC L2 tenants.
- Baselines
- CIS, DISA STIG and NIST, evaluated continuously rather than at audit time.
We have shipped this before
Between the two founders: the enrollment platforms Apple ships, and the first cloud-hosted Jamf environment.
- Apple
- Built Apple School Manager and Apple Business Manager, and zero-touch enrollment at scale.
- Prior
- 15+ years across MobileIron, SOTI, Automox, Addigy, Scalefusion and Apple.
- Built
- Six device-management platforms, end to end, before Smplify.
- NIST
- Invited by NIST and Apple Federal Architects to present an Agentic mSCP 2.0 implementation.
- Founded
- Forget Computers in 1998, one of the first Apple-focused MSPs. Acquired by Ntiva.
- Built
- Robot Cloud, the first cloud-hosted Jamf environment.
- Also
- Vision-Bot, a dashboard over Jamf, Addigy and Zendesk. SupportMenu for macOS.
- Years
- 25+ running businesses whose margins depended on device management working.
Tell us what you’re building
Whether you’re embedding device management in a product, running thousands of endpoints in-house, or managing fleets for other people, we’d like to hear the shape of it.
- You’ll talk to the people who built the platform, not an SDR
- API access and technical docs on the first call
- No credit card, no procurement gauntlet to look around
- 01Tell us what you’re building. One short form, name, company, and the shape of your fleet.
- 02We read it, not a bot. One of the founders replies, usually same day.
- 03You get API access and docs. Enough to build something real before any commercial conversation.