A fleet running Samsara, Geotab, or any third-party fleet management platform still has a layer of problems that platform doesn’t touch: keeping the tablet’s OS patched, locking it to the platform app so a driver can’t wander into settings, and diagnosing a unit that’s gone dark without sending someone to the vehicle. That’s device management (MDM), and it sits underneath the fleet platform, not inside it.
TL;DR
- Fleet platforms (Samsara, Geotab, Verizon Connect) manage vehicle and driver data; MDM manages the physical tablet — OS updates, app whitelisting, remote diagnostics
- These are two separate software layers running on the same terminal, from two different vendors, doing two different jobs
- Without MDM, a fleet running third-party hardware has no way to push a security patch or lock the device to the fleet app without physically collecting every unit
- CF-Device’s VCM terminals ship with kiosk-mode app whitelisting and remote MDM enrollment out of the box, independent of which fleet platform runs on top
- The two layers should be checked separately when specifying hardware — a tablet compatible with a fleet platform’s app isn’t automatically compatible with a given MDM’s enrollment method
I. Two Layers, One Screen
It’s easy to assume the fleet platform “manages” the tablet because it’s the only app the driver sees. In practice, most platforms manage the vehicle and driver side — location, diagnostics data, driver behaviour, dispatch — and treat the tablet itself as a fixed appliance they don’t touch below the app layer. Whoever deployed the hardware still owns OS updates, device enrollment, remote lock/wipe, and the question of what happens when a unit stops responding at 2am on a truck three states away.
In short: the fleet platform is the application; MDM is the operating layer underneath it. A fleet needs both, from potentially two different vendors, working together on the same device.
II. What MDM Actually Does That a Fleet Platform Doesn’t
| Function | Fleet platform (Samsara/Geotab) | MDM |
|---|---|---|
| Vehicle location, driver hours, diagnostics | Yes | No |
| OS updates / security patches | No | Yes |
| Kiosk mode / app whitelisting | No | Yes |
| Remote lock / wipe on a lost or stolen unit | No | Yes |
| Bulk device enrollment for new hardware | No | Yes |
| Battery / connectivity health monitoring | Partial (vehicle-level) | Yes (device-level) |
A fleet that skips MDM and relies only on the platform app usually finds out why the two layers are separate the first time a tablet needs a factory reset in the field, or when a driver figures out how to exit the app and use the tablet for something else during a shift.
III. Checking Compatibility at Both Layers
Specifying hardware for a fleet already running a management platform means checking compatibility twice, not once. The first check — whether the tablet runs the platform’s app and exposes the CAN data it needs — is covered in our guide to rugged tablets compatible with fleet management platforms. The second, separate check is whether the tablet’s MDM enrollment method (Android Enterprise, a dedicated agent, or a manufacturer’s own console) fits what the fleet’s IT team already manages. A tablet can pass the first check and still be awkward to manage at scale if it doesn’t support the fleet’s existing MDM approach.
IV. What CF-Device Hardware Provides at the Device Layer
CF-Device’s VCM terminals ship with kiosk-mode app whitelisting built in — covered in our kiosk mode and app whitelisting guide — so a unit can be locked to the fleet platform’s app before it ever leaves the warehouse. Remote diagnostics reads device-level signals (battery, connectivity, storage) independently of whatever the fleet platform reports about the vehicle, which matters when a unit fails in a way the platform’s own dashboard never surfaces, since the platform is reading vehicle data, not device health.
V. A Deployment Example
A fleet running an open telematics platform across 60 vehicles assumed the platform vendor would flag any tablet running low on storage or stuck on an outdated OS build, since that was the assumption baked into their original deployment plan. It didn’t — the platform only reported what the app itself sent it, and a tablet that stopped updating silently kept reporting stale location data for weeks before anyone noticed the pattern. Adding MDM alongside the existing platform closed that gap: the fleet could now see device-level health across all 60 units from one console, separate from the vehicle data the platform was already tracking well.
Frequently Asked Questions
Does Samsara or Geotab include device management?
Both focus on vehicle and driver data; device-level management (OS patching, app lock-down, remote diagnostics) is typically a separate MDM layer, whether that’s the platform vendor’s own limited device tools or a dedicated third-party MDM.
Can one MDM console manage tablets running different fleet platforms?
Yes — since MDM operates at the device layer, not the app layer, a single MDM console can typically manage a mixed fleet running different platform apps on different vehicles, provided all the hardware supports the same MDM enrollment method.
What happens if a tablet loses connectivity — does MDM or the fleet platform catch it first?
Usually MDM, since it monitors device-level connectivity directly rather than inferring it from vehicle data updates, which can lag or go silent for reasons unrelated to the tablet itself.
Which CF-Device terminals support kiosk-mode MDM enrollment?
The full VCM series ships with kiosk-mode app whitelisting and remote MDM enrollment as standard, independent of screen size or which fleet platform app is installed.
Interested in specs or a quote for hardware that fits both your fleet platform and your MDM console? Contact our team to confirm compatibility at both layers.