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.

    1,284Devices, one control plane
    1Intent, every platform
    0Endpoint agents required
    mcp.smplify.com — agent sessionLive

    One intent → three dialects1,284 devices

    Cells are a representative sample; the counts are exact.

    The thesis

    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.

    ThenPush a configOne platform. Quarterly cadence. A human at every keyboard.
    NowEnforce an intentEvery platform. Continuous drift correction. Agents acting at machine speed, gated by people.
    Governance

    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.

    AUTOCommits immediately. Audited.
    NOTIFYCommits, but interested parties are told.
    APPROVEHolds. One eligible approver must decide.
    TWO_PERSONHolds. Two distinct approvers, neither the requester.
    DENYStructurally unavailable in this tenant.

    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.

    In the conversation

    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
    No agent, no ceiling

    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
    AppleProtocol-native
    • ADE / ABM zero-touch enrollment
    • Configuration profiles & Declarative Device Management
    • VPP app management
    • Account-driven BYOD enrollment
    • CIS, DISA and NIST compliance baselines
    WindowsNative MDM
    • Enrollment and CSP configuration profiles
    • BitLocker and Defender
    • OS update management
    • Remote lock, wipe and restart
    • MSI application deployment
    LinuxDeclarative Framework
    • 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.

    Headless

    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
    Security operations

    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.

    1. 01Alert firesYour SIEM correlates a Smplify event with everything else it sees.
    2. 02EnrichPull live posture for that device through the API or MCP.
    3. 03ActIsolate, lock, or reapply policy from the tool you are already in.
    4. 04ApproveDestructive steps wait for a second person. Everything is logged.
    MSPs, MSSPs & enterprise

    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.

    Evidence

    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.
    On the record

    We have shipped this before

    Between the two founders: the enrollment platforms Apple ships, and the first cloud-hosted Jamf environment.

    Spurti Preetham GurramCo-Founder & CEO
    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.
    Ben GreinerCo-Founder & CSO
    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.
    Talk to us

    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
    What happens next
    1. 01Tell us what you’re building. One short form, name, company, and the shape of your fleet.
    2. 02We read it, not a bot. One of the founders replies, usually same day.
    3. 03You get API access and docs. Enough to build something real before any commercial conversation.
    Or read the API docs first