New · Release 2026.04, Multi-tenant audit exports & SLA dashboards now liveSee changelog →
Device management
Mobile device management from enrollment to remote command
Enroll and manage Windows, macOS, Linux, and Android devices from one tenant workspace—policies, compliance, and remote commands (no iOS/iPadOS today).
Product illustration · sample data
Mobile Device Management
6 OS
AndroidiOSWindowsLinux
94%
Compliance · 128 enrolled
Enrolled devices128
Non-compliant8
Pending commands3
Linux agentsActive
Product proof
Already live in the product
Backed by app modules
Running in production today: the MDM dashboard, devices, enrollment, policies, apps, groups, compliance, commands, reports, and settings.
Protected app route: /mdm-dashboard
How it works
Built around real workflows
Highlights below describe capabilities already present in the protected app behind this page.
Multi-OS device registry and dashboard KPIs
Enrollment tokens and QR flows
Policy and device group management
Compliance rules and org-wide scans
Remote commands with audit trail
Inventory and compliance reports
Per-tenant module gating (Enterprise)
Linux and API enrollment for QA
Workflow
What teams can do here
Step 1
Enable MDM module for tenant
Step 2
Create enrollment token
Step 3
Register or enroll device
Step 4
Assign policy and run compliance scan
Step 5
Queue remote command and review status
How it works
How it works
01
Enrol devices
Mint an enrollment token or QR code and register Windows, macOS, Linux and Android devices into one tenant workspace. Each device resolves the management channels it actually has.
02
Understand its channels
A device is managed over an agent (our software) and/or the OS vendor's native MDM protocol. The platform computes, per device, which commands each live channel can genuinely carry.
03
Apply policy and scan compliance
Assign policies and device groups, then run org-wide compliance scans against the rules you set, so drift is visible rather than assumed.
04
Send commands honestly
Queue remote commands from the capability list. An action a device cannot truly perform is refused with a reason — for example "requires native MDM enrolment" — instead of being offered and silently doing nothing.
05
Support and report
Start an in-app remote-desktop session to Windows, macOS or Linux endpoints via the MeshCentral relay, and pull inventory and compliance reports — all with an audit trail and per-tenant isolation.
Example
A worked example
Say a 250-employee logistics firm enrols 180 Windows laptops, 25 Macs, 15 Linux workstations and 30 Android handhelds into Infronest MDM. On the Windows fleet the console offers lock, wipe, BitLocker and BIOS actions, because the Windows agent genuinely carries them. On the Macs, factory-wipe and true lock light up only on devices that completed native MDM enrolment — an agent-only Mac refuses those buttons with "requires native MDM enrolment", since Apple restricts EraseDevice and DeviceLock to its own protocol. The Linux boxes manage over the agent alone, and the Android handhelds are driven through Google's Android Management API.
FAQ
Frequently asked questions
Which operating systems can Infronest MDM manage — does it cover iPhones and iPads?
Infronest manages Windows, macOS, Linux and Android today. There is no iOS or iPadOS management yet: Apple mobile devices can only be managed through Apple's certificate-gated MDM programme, and we would rather say that plainly than list a platform we cannot control. What each supported OS can do also differs, because management runs over two channels — a cross-platform agent and the OS vendor's native MDM protocol.
Do all commands work the same on every OS?
No, and this is a platform reality, not a roadmap gap. Windows is strongest: its agent carries lock, wipe, BitLocker and even BIOS control. macOS cannot be factory-wiped or truly locked by the agent — Apple restricts those to native MDM enrolment — and Apple MDM has no shell command, so scripts stay agent-only. Linux is agent-only forever because no vendor publishes a Linux MDM protocol, and it cannot silently encrypt an already-provisioned root disk; it enforces data-volume encryption and flags non-compliance instead. Android runs only through Google's own device channel, with no shell execution or screen sharing.
What is the difference between the agent and native MDM?
The agent is software we ship that runs cross-platform and works today, but it cannot enforce anything the user can undo, survive a wipe, escrow a disk key or act before login. Native MDM is the OS vendor's protocol enforced by the OS — real wipe, key escrow, supervision, zero-touch — but it is per-platform and usually gated behind a vendor approval.
Why is an action greyed out on one device but not another?
Capability is resolved per device from its live channels. If a device lacks the channel an action needs, the platform refuses it with a reason — such as "requires native MDM enrolment" or "requires the management agent" — so a disabled button explains itself rather than pretending to work.
Can I remote-control an enrolled device?
Yes for Windows, macOS and Linux, through an in-app remote-desktop viewer over a MeshCentral relay with per-organization isolation. Android is more limited, since mobile operating systems do not expose third-party screen control the way desktops do.
Is one tenant's device data isolated from another's?
Yes. Devices, policies, commands and remote sessions are scoped to your organization, and the module blocks access when MDM is disabled for a tenant, which suits MSPs and multi-entity teams that must keep each org separate.
Manage Windows, macOS, Linux and Android from one console
The full Infronest MDM tour at infronest.com/mdm shows the per-OS capability matrix, remote desktop and policy engine — a platform that refuses actions a device cannot truly perform instead of pretending.