Category filter

How to resolve compliance policy conflicts in Hexnode UEM?

TL;DR

Compliance conflicts happen when multiple compliance policies apply different rules to the same device.
Hexnode UEM behavior: when conflicting compliance policies are associated, the most recently applied policy takes effect.
Common causes include overlapping device groups, user group targeting, domain targeting, cloned policies, and broad default policies.
Recommended fix: separate policies by platform, ownership, user group, and device group.
Always review policy summary before changing production compliance policies.

Conflicting compliance policies can occur when more than one compliance policy is associated with the same device, user, device group, user group or domain and the policies evaluate the same device posture differently. In Hexnode UEM, admins should review policy targets, policy timing, default compliance behavior, and the configured compliance criteria to understand why a device received a specific compliance result.

Executive Summary

Compliance policy conflicts can create confusion when a device appears compliant under one policy but non-compliant under another. This usually happens when policies overlap across device groups, users, domains, or ownership categories.

Admins should use clear names, scoped targets, platform-specific policies, ownership-based policies, and staged rollout groups to reduce conflicts.

Common causes of compliance policy conflicts

This table explains common causes of conflicting compliance policies in Hexnode UEM.

Cause	What Happens	Recommended Fix
Overlapping device groups	A device belongs to two groups with different compliance policies.	Use more specific groups or remove duplicate targeting.
User and device targeting overlap	A policy is applied through both user and device association.	Choose a consistent targeting model for compliance policies.
Default policy overridden	A newly applied custom policy overrides default compliance behavior.	Review default and custom policy behavior before rollout.
Cloned policy reused incorrectly	A cloned policy may retain settings that do not match the new target group.	Review all criteria before assigning cloned policies.
Corporate and BYOD devices share one policy	Personal devices may receive strict corporate checks.	Create separate policies for corporate-owned and personal devices.

Workflow to resolve conflicting compliance policies

Log in to Hexnode UEM
Navigate to Manage> Devices and open the affected device to review its current compliance status
Identify the compliance policy currently associated with the device.
Review all user, device, group, and domain targets that may apply to the device.
Check whether a newer policy was applied after an older policy.
Open the Policy Summary Tab for each relevant compliance policy.
Compare Basic Settings, Advanced Settings, criteria, logic, and target scope.
Remove duplicate or unintended policy associations.
Create separate policies for different platforms, ownerships, or business units where needed.
Save changes and run a device scan remote action on the affected device by navigating to Manage> Devices > Actions > Scan Device
Confirm the device compliance result after the next check-in.

Conflicting compliance policy examples

This table explains examples of conflicting compliance policies and how to resolve them.

Scenario	Conflict	Resolution
Windows BitLocker conflict	One policy marks BitLocker disabled as non-compliant; another policy does not check BitLocker.	Use a dedicated Windows corporate baseline and remove overlapping policy targets.
BYOD iOS conflict	BYOD iPhones receive a corporate supervision requirement.	Use ownership criteria or separate BYOD and corporate iOS policies.
macOS FileVault conflict	A pilot FileVault compliance policy applies to all Macs by mistake.	Limit pilot policy to a test device group.
App compliance conflict	A required app policy applies to a department that does not need the app.	Map required app compliance policies to department-specific groups.

Troubleshooting conflicting compliance policies

This table explains common troubleshooting scenarios for conflicting compliance policies.

Issue	Possible Cause	Recommended Action
Device result changed after policy edit	A newer policy or updated policy may have taken effect.	Review modified date, policy version, and target count.
Device belongs to multiple groups	Several group-based policies may apply.	Review all device groups and user groups associated with the device.
Default compliance behavior disappeared	A custom policy may have overridden default compliance settings.	Review custom policy criteria and re-add needed default checks.
Compliance status does not update	Device has not checked in or scan data is stale.	Scan the device and confirm last check-in time.

Best practices to avoid compliance policy conflicts

Use platform-specific policies: Keep iOS, Android, Windows, macOS, ChromeOS, Linux, tvOS, and visionOS policies separate where possible.
Separate corporate and BYOD policies: Avoid applying corporate-only checks to personal devices.
Use clear naming: Include platform, ownership, and purpose in the policy name.
Limit broad domain targeting: Use domain targets carefully because they may affect more devices than expected.
Review policy summary: Check configured settings, version, modified date, and target count before rollout.
Pilot first: Test new compliance policies on a small group before production deployment.