In Device Management Only

Understanding In Device Management Only Configuration

If you're dealing with Enterprise Mobility Management platforms like Microsoft Intune, VMware Workspace ONE, or Jamf, you've almost certainly hit a setting that restricts management actions to the device level rather than the user or cloud level. The term In Device Management Only refers to configurations where policy enforcement and data handling happen exclusively on the physical device, with no cloud-based intervention or synchronization happening in real time. This setup matters because it changes how you troubleshoot, deploy updates, and handle compliance failures. When a device is enrolled under In Device Management Only mode, the MDM server pushes policies to the device once, and then the device enforces them locally without periodic re-checking against the cloud. The agent running on the device handles remediation, compliance status, and policy application entirely on its own. This is different from continuous compliance models where the cloud constantly validates whether the device meets policy and pushes corrective actions as needed. The practical result is that your MDM console will show the device as managed, but you lose visibility into what's actually happening day to day. If someone disables a security policy on the device manually, the cloud won't know until the next full sync cycle, which in some platforms can be as long as 24 hours. This delay is something I learned the hard way during a compliance audit last year when three devices had their firewall settings modified locally and our dashboard showed everything as green for nearly two weeks.

When In Device Management Only Makes Sense

There are legitimate scenarios where operating entirely on-device is the right call. Remote or field workers who spend extended periods without reliable cellular or Wi-Fi coverage benefit from having policies cached locally so the device continues enforcing rules even when disconnected. Medical and manufacturing environments with air-gapped networks also typically require this approach since pushing policies back to a cloud server isn't physically possible. Another common use case involves highly restricted government or defense contractor devices where any outbound management traffic triggers compliance violations or audit flags. In these environments, the MDM server exists on a local network segment, and the device only communicates during scheduled maintenance windows rather than maintaining persistent cloud connectivity. The tradeoff is real though. You give up near-real-time compliance visibility, remote wipe becomes unreliable if the device is offline during an incident, and bulk policy updates require either manual initiation from each device or a scheduled sync window that you control. Factor in an extra 30 to 45 minutes of configuration time per device during initial enrollment because you need to pre-stage all policies rather than relying on dynamic cloud assignments.

Setting Up In Device Management Only in Practice

The configuration path varies depending on your platform, but the core steps are consistent across most MDM solutions. First, you create a device enrollment profile that specifies local-only management mode. Then you define your compliance and configuration policies and attach them to that enrollment profile rather than to user-based groups. The device agent needs to be configured with the correct server endpoint and given permission to operate without continuous cloud verification. In Intune, this maps to device enrollment profiles with the management mode set to local. In Workspace ONE, you configure the device association type and disable cloud compliance polling. Jamf Pro requires setting the policy scope to target devices directly and disabling cloud-based compliance checks in the device category settings. Each platform uses different terminology but the underlying mechanism is the same: you're telling the agent to stop constantly phoning home and start making its own decisions based on cached policy. One specific problem I ran into involved Windows 11 devices enrolling through Autopilot where the In Device Management Only setting conflicted with the registered device attribute in Azure AD. The enrollment would complete successfully but the device would immediately revert to hybrid management after the first sync. The workaround was to explicitly assign the device to a device group before the first policy application and to set the Azure AD join type to standard cloud join rather than hybrid. Once I did that, the local-only mode held stable across reboots and Windows updates.

Pitfalls That Catch Most People Off Guard

The biggest issue is policy drift. When a device operates in In Device Management Only mode for an extended period, the cached policy on the device can diverge significantly from what the admin intended. I've seen configurations where a password policy was updated in the management console but the device never pulled the change because it hadn't initiated a sync in over a week. The device continued enforcing the old 90-day rotation while the rest of the fleet was on 30 days. You need a documented sync schedule and periodic manual verification to catch this. Another counter-intuitive problem involves certificate-based authentication. When the device manages policies locally, certificate renewal for SCEP or EST protocols also happens on-device without cloud oversight. If the certificate authority's enrollment server goes down even briefly, the device won't renew its management certificate and will appear as non-compliant the moment it does reconnect. I recommend maintaining a secondary CA endpoint or configuring the device agent with multiple registration servers to prevent this single point of failure. Password policies and encryption settings tend to be the second area where problems surface. Since the device doesn't validate its compliance state against the cloud continuously, a user can change their own password through local Windows settings and the MDM agent won't detect that the new password doesn't meet the cached policy requirements. The fix is to use local group policy or registry-level enforcement alongside the MDM policies so there are two overlapping layers that prevent unauthorized changes.

Monitoring and Maintenance Considerations

You can't just enroll devices in In Device Management Only mode and forget about them. Without active monitoring, compliance gaps accumulate silently. I set up a weekly PowerShell script that queries the management agent status on each device and reports back the last sync time, cached policy version, and any local policy overrides that have been applied. This takes about 10 minutes to run across a fleet of 200 devices and surfaces issues that would otherwise go unnoticed for weeks. Scheduled maintenance windows should be built into the enrollment profile. Even if the device operates primarily in local mode, a monthly or quarterly sync back to the management server ensures policy versions stay current and any drift gets corrected. In my experience, setting this interval to every 14 days provides the best balance between operational independence and administrative oversight. Shorter intervals reintroduce some of the cloud dependency you were trying to avoid. Longer intervals let problems compound. There's also the matter of offboarding. When a device leaves In Device Management Only mode or is decommissioned, the local cache may retain policy data and credentials that aren't immediately purged. I've encountered cases where a device returned to the fleet with residual configuration profiles that conflicted with new enrollment policies, causing a failed installation that required a full manual cleanup. Documenting the offboarding sequence and verifying local cache deletion is part of the standard procedure prevents this from becoming a recurring headache.

The approach works well when you understand what you're giving up in exchange for local autonomy. It's not a set-it-and-forget-it configuration. The devices need periodic attention, the policies need verification, and the administrators need a monitoring routine that compensates for the reduced cloud visibility. When those conditions are met, In Device Management Only provides a reliable framework for environments where continuous cloud communication isn't feasible or desirable.