Guide · Device Management Infrastructure
What Is Device Management Infrastructure
(and Why MDM Is Only Part of It)
Device Management Infrastructure (DMI) is the full management system for company-owned hardware doing a single job — kiosks, point-of-sale systems, barcode scanners, signage. Traditional MDM handles policy and control, but it's only one layer. DMI is the whole foundation beneath it — the OS, provisioning, and updates that keep the hardware running the business. Esper is the infrastructure built to handle that specific demand.
- ◆DMI is the full management system for company-owned single-purpose hardware — kiosks, POS, scanners, signage. MDM is one layer of it (policy and control); DMI is the whole foundation beneath, including the OS, provisioning, and updates MDM can't control.
- ◆The difference from MDM is structural, not feature-based. MDM operates devices from the outside, one at a time. DMI declares the state the whole fleet should hold and continuously maintains it.
- ◆It's not UEM, and it's not a more capable MDM. UEM widens how many endpoint types one console reaches; DMI changes where management lives — inside the device's OS, provisioning, and application surface, not bolted on from outside.
- ◆DMI matters when complexity outgrows the tools managing it. Once management has to reach into how a device is provisioned, what OS it runs, or how it updates with no one nearby, a bigger policy tool can't get you there. The reach itself is the problem.
- ◆Esper manages Android, iOS, iPadOS, tvOS, Linux, and Windows from a single pane of glass, as one declared system: devices provisioned managed from first boot, legacy hardware moved to a new OS, applications locked to a single purpose.
- ◆This isn't just Esper's framing. Apple's Declarative Device Management and Google's Android Management API are both moving enforcement into the device — the industry is relocating management off the server and into the OS, because managing from outside doesn't scale.
What is Device Management Infrastructure?
Device Management Infrastructure is the full management system a device fleet runs on. With DMI, the operating system, provisioning, configuration enforcement, and update delivery are part of the managed system itself, not endpoints an external tool reaches in to control after the fact. MDM lives inside it as the operational layer — enrollment and provisioning, configuration, app deployment, updates, telemetry, and remote troubleshooting, with policy and control as the governance slice within it.
But MDM is only that one layer, and it assumes a finished device to act on: an OS someone else built, a device already booted, already enrolled into management. DMI is the full system behind every device's identity and desired state — that layer plus everything beneath it that MDM was never built to touch. The management isn't something you do to the device from outside. It's part of what the device is.
A generation ago, running servers meant racking physical boxes and configuring every one by hand. Then cloud infrastructure changed the relationship to the machine. You stopped unboxing hardware. You started declaring the state you wanted — and the layer provisioned, configured, and maintained it for you. You stopped operating hardware and started orchestrating intent.
Device Management Infrastructure is that same move, pointed at the physical devices a business actually runs: the kiosks, the point-of-sale terminals, the scanners and connected frontline tech, the signage, the tablets out in the field. It's all the components that let you operate and manage your devices.
And that's exactly what Esper does. Esper is the infrastructure, not an MDM. Physical devices are programmable infrastructure, and they ought to be managed the way you manage infrastructure — by declaring desired state across the whole fleet instead of babysitting endpoints one at a time.
Infrastructure vs. a tool
There's a quick test for whether a thing is infrastructure or a tool you operate. In device management, a tool is a console an admin logs into to act on devices one at a time — it can be genuinely excellent and still be a tool. Infrastructure is the layer devices run on: it holds the whole fleet in its declared state so the work happens by default, not by someone driving it. That's a different shape.
- API-first — your own systems build on top of it.
- Declarative — you describe the destination, not every turn to get there.
- Load-bearing — your stack leans on it the way an app leans on the cloud.
- Scales without headcount — growth doesn't mean a new hire per chunk.
- Worked manually — something a human stands at and operates.
- Built script-by-script — one action at a time.
- Attached — sits beside your stack rather than under it.
- Needs people to grow — scales by adding humans to run it.
Plenty of MDM platforms pass parts of this test, and for a whole lot of fleets they pass enough of it to be the right answer, full stop. The test isn't here to devalue MDM. It's here to show that "manage devices" has quietly been describing two different jobs the whole time. And the infrastructure job is the one most teams have never had a product for.
MDM is a layer of DMI, not a synonym for it
"MDM," "UEM," and "device management" get tossed around like they're the same word, as if managing a fleet is one job that one tool does. That oversimplification may seem like semantics, but it's actively damaging.
Here's the 21st century reframe: MDM is the policy and control layer: enrollment, configuration, compliance, remote actions, lock and wipe. Real, necessary, and a genuine component of DMI. But look at everything it assumes before it can do any of that: a device that already exists, an OS somebody else built and shipped, a device already booted into a runtime somebody else chose. MDM picks up the story at the moment the device is a finished, enrolled object — and manages from there. Esper controls the full stack: image, OS, browser, firmware, provisioning, and management.
Everything that happens before and beneath that moment is the infrastructure. How the device arrives in its managed state. What OS it runs, and whether you're even allowed to change it. What the device is permitted to be. How it updates when the nearest human is a hundred miles away. Not one of those is a policy question — which is precisely why the policy layer can't answer them. They're foundational questions.
And this isn't just an Esper claim for the sake of being different. Apple tells the same story with its Declarative Device Management model, pulling enforcement off the server and into the device itself. Google's Android Management API has been drifting the same way. The biggest platform owners on the planet are, independently, relocating management into the device — because managing from the outside doesn't scale and falls apart the second the network gets flaky. Esper just built the version that works across every platform at once.
How you operate a fleet built as infrastructure: desired state
Once the fleet is infrastructure, the way you operate it changes too. Desired-state management is the operating model that runs on top of DMI — a change in what counts as work. The unit stops being "actions you take on devices" and becomes "the state you declare for the fleet." The shift happens on several axes at once:
With Esper, the desired-state document is called a Blueprint. You declare the settings, applications, and policies the fleet should be holding, and the system continuously converges every device toward that declared state. You're not pushing a change and watching for the little checkmark that says it landed — you're editing the description of how the fleet ought to be, and the infrastructure makes reality match the description. You can set Blueprints across device types, locations, operating systems, or any combination you can think of. What matters is the operating model, not the syntax.
Drift and self-healing
The clearest way to feel the difference is to watch what happens when one device isn't in its desired state. Somebody changes a setting locally. An app version slips a notch. A config drifts. In an operate-each-device world, you find out when something breaks, and then a human goes digging. In a desired-state world, the gap between where the device is and where it's declared to be gets caught automatically, and the system pulls the device back into line with nobody in the loop. Drift stops being a support ticket and becomes a condition that quietly corrects itself. That one difference is most of the reason the desired-state model keeps scaling while the one-human-per-handful-of-devices model falls behind.
The DMI product suite: six places MDM alone can't reach
The case for DMI really gets made in six specific places where the policy layer simply runs out of reach — each one a product in the Esper suite. Every one is somewhere Esper customers actually live, every day.
Devices that arrive managed
Enrollment is the original sin of the operate-each-device model — the very word assumes a device that already exists and a person standing there to enroll it. The friction isn't the policy. It's that there's a "before managed" state at all, and somebody — an implementation manager, a technician, staff on site — has to physically close the gap between "device in a box" and "device under management." That's the cost and time of touching every unit before it can do a thing.
DMI deletes the gap. The device drop-ships straight from the manufacturer, powers on, identifies itself, pulls its assigned Blueprint, and configures itself completely at first boot — no kitting line, no staging warehouse, no technician in the chain. Because provisioning begins inside the OS at first boot rather than after enrollment, management software sitting on top of the OS can't replicate that zero-touch first boot.
Legacy hardware, moved to a new OS
Aging Windows hardware is one of the most expensive headaches in any large fleet, because the obvious fix — ripping out and replacing thousands of working devices — is a capital event nobody wants their name on. MDM is no help here, not because it's bad at its job, but because it's the wrong job. MDM can manage what a device runs. It can't change what the device fundamentally is.
Esper Firebolt can: it converts aging Windows devices to a managed Android OS on the exact same hardware — the flip — no replacement units required. And if you're not ready to commit, Firebolt runs Windows and Android side by side in dual-boot, so you flip on your own timeline. Firebolt is the on-ramp; where it lands is Esper Foundation.
A managed OS, not a surface to sit on
Where Firebolt lands is Esper Foundation for Android — a custom AOSP-based build that isn't only a Windows escape hatch. It's a managed OS for custom and purpose-built hardware of any kind, from handhelds to kiosks to signage: custom Android without the maintenance burden, because Esper builds, patches, and supports the OS across ARM and x86 through its full lifecycle.
The Foundation SDK is a Maven artifact you pull straight into your app, with direct access to OS subsystems a standard Android app can't reach. Because the OS itself is part of the managed system, management stops being a tool balancing on top of a surface someone else shipped — the operating system becomes the foundation the rest of the stack is declared on.
OTA infrastructure you don't have to build
If you ship devices with your own OS build — an OEM, or an enterprise that's taken ownership of the OS — then getting firmware and OS updates to the field is your problem to solve, and it's a big one: update servers, staged rollout logic, rollback machinery, package signing, build targeting. That's a serious engineering investment, and it's not the product you actually sell.
Esper Airwave handles over-the-air firmware and OS updates for Android — staged rollouts, delta build support, A/B rollback, cryptographically signed packages — and runs as a standalone product, no MDM required. You get all of it without building and babysitting it yourself.
Devices where the cloud is too far away
Plenty of fleets live where the network is an afterthought: a factory floor behind three firewalls, a retail back room on a saturated uplink, a QSR location where every device competes for the same limited bandwidth. Cloud-only management assumes a clean line back to the data center is always there. When it isn't, the math breaks. Esper Edgebox moves the work on site, running provisioning and device-operations infrastructure on a local gateway.
The honest boundary: Edgebox isn't air-gapped or fully on-prem — the gateway still talks to Esper Cloud for orchestration. What changes is where the heavy work happens: provisioning, updates, and device operations run locally, so the fleet keeps working even when the uplink is slow or drops entirely.
When the application surface is the management surface
Some devices should only ever do one thing, forever. A kiosk is a kiosk. A point-of-sale terminal is a point-of-sale terminal. The operate-each-device model parks an MDM next to the application and fences off everything around it — leaving you with two separate systems, the app and the management layer, quietly fighting each other for control.
DMI collapses the two into one. Esper's Titanium is a purpose-built Chromium browser designed for dedicated-device fleets — not a browser someone installed on a managed device, but a browser built as the managed surface itself. The management isn't a fence you build around the app. It's the ground the app is standing on.
And the management layer itself
None of this replaces device management — it stands it on a real foundation. Esper runs that layer too: Deploy is Esper's MDM, the enrollment, provisioning, configuration, app deployment, updates, and remote-action surface that rides on top of all six layers above. The difference is that here it isn't a separate tool reaching in from outside; it's the top of one declared system, operating devices the infrastructure already provisioned, built, and holds in state. Management and infrastructure, from the same place.
When you need DMI (and when MDM alone is enough)
Real talk: not every fleet needs any of this, and pretending otherwise would torch the whole argument. Buying infrastructure you don't need is just a more sophisticated way to waste money.
- Devices are dedicated and single-purpose
- Complexity climbs as the fleet grows faster than you can hire
- Hardware is aging and replacing it is costly
- Devices are unattended or starved for bandwidth
- A mix of OSes must behave like one system, managed from a single pane of glass
- Corporate laptops and phones that ship pre-configured
- Devices enrolled by the people who use them
- A stock OS you have zero reason to touch
- A reliable network you can count on
The pattern under every one of those is identical, and it's the tell. The moment management has to reach below the policy layer — into how a device is provisioned, what it's built on, what it runs, where it lives, or how it stays current — you've walked out of tooling territory and into infrastructure territory. And a bigger MDM is just a taller ladder for a problem that's actually underground.
MDM manages the device you already have. Device Management Infrastructure controls the full stack — image, OS, browser, firmware, provisioning, and management — with granular control over what every device is, what it runs, and how it holds the state you declared, across every operating system and without a single hand on a single unit.
Explore the platform
See how the pieces fit together across provisioning, OS, application, and updates in the Esper platform overview.
Frequently asked questions
MDM is the policy and control layer that operates existing devices from the outside: enrollment, configuration, compliance, remote actions. Device Management Infrastructure is the full system that layer is part of — the operating system, provisioning, application surface, and update delivery beneath it, plus the policy layer itself. MDM is one layer of DMI, not a synonym for it.
No. UEM broadens the policy layer to cover more device types, but it still manages devices as external endpoints. Device Management Infrastructure changes where management lives, putting it inside the device's OS, provisioning, and application surface, rather than just widening how many endpoint types one console can reach.
Yes. Esper manages Android, iOS, iPadOS, tvOS, Linux, and Windows as one declared state from a single console, instead of running a separate management stack per operating system. Managing a mixed fleet as one system is covered in detail in the guide to running multiple operating systems on one platform.
A device that arrives managed enters its managed state at first boot, with no onsite setup, instead of being enrolled into management after it already exists. The device is part of the declared fleet from the moment it powers on. Setup specifics are in the Esper Seamless Provisioning documentation.
Reliable over-the-air delivery — staged rollouts, automatic rollback, delta updates, A/B slots, and cryptographic signing — runs as standalone infrastructure, independent of any MDM, so OEMs and enterprises shipping custom OS builds don't have to build and maintain that whole system themselves. A failed update halts and reverts on its own rather than reaching the rest of the fleet. Delivery specifics are in the Esper Airwave documentation.
A local gateway on site runs the provisioning and update work close to the devices, so the heavy traffic stays on the local network instead of crossing the open internet for every device. Provisioning drops from around 24 minutes per device on cloud-only MDM to about 2 minutes, and one customer cut update traffic from 240MB per device to 3MB. The gateway still coordinates with the cloud for orchestration; what moves on-prem is the heavy lifting, not the whole system.
Yes. Flipping aging Windows hardware to a managed Android foundation extends device life without buying new hardware, and it brings the operating system itself into the managed system. Conversion specifics are documented in the Esper Foundation reference.
They share a core principle: declare the target state, then let the system converge devices to it rather than scripting each change. Apple's Declarative Device Management applies that principle within Apple's own stack, while Esper's desired-state Blueprint applies it across all six supported platforms as the operating model for the entire fleet.