cases

Policy Scope Drift in Device Controls

Device-oriented security controls had been attached to a broad dynamic user group, creating conflict state and unreliable testing. This record traces the scope problem and the low-risk migration path used to correct it.

Date
Area
Intune policy architecture
Status
Case record

Summary

I investigated recurring management conflict on Intune-managed test devices and traced it to a deeper assignment problem: device-oriented security controls had been attached to a broad dynamic user group instead of device groups. That created scope mismatch, made endpoint-hardening tests unreliable, and meant any licensed user could reintroduce the same problem by signing into a device. I designed a low-risk migration path that preserved functional intent by mirroring the relevant policies onto device groups first, validating the new control path, and only then retiring the legacy user-scoped assignments.

Context

The environment already contained a large body of legacy Intune configuration for endpoint security. Controls related to BitLocker, ASR, antivirus, firewall, and similar device-oriented behaviour were linked to a dynamic user group that effectively covered all licensed users. At the same time, I was trying to improve hardening and testing quality on pilot devices without causing disruption in active client environments.

Problem

The visible symptom was conflicted management state on test devices. Looking more closely, the same device could show successful application in system or device context while also showing a conflicting user-linked state. That made it hard to trust what was actually being enforced and made test results difficult to interpret.

Investigation

The first question was whether the conflict could simply be tolerated while better device-based policies were layered on top of the old model. That started to look increasingly unstable.

A major clue was that my test user belonged to the same dynamic group that carried the legacy device-oriented policies. I tried to detach the test user from that group to isolate the issue, but because the assignment was dynamic, manual removal was not practical.

That forced a more structural conclusion: as long as device settings remained tied to a broad user group, any licensed user signing into the device would keep reintroducing scope ambiguity. This was not just a policy-payload issue. It was an assignment-architecture issue.

From there, I mapped the device-oriented policy families attached to the legacy user group and defined a clean migration path:

  • inventory the user-linked policies
  • mirror their intended behaviour into device-targeted equivalents
  • apply the mirrored policies to device groups
  • validate behaviour in device context
  • remove legacy user-scoped assignments after the new path converges

Root Cause

The root cause was a scope mismatch between the managed object and the assignment model. Device-oriented security controls had been attached to a broad dynamic user group, creating recurring conflict state and making reliable endpoint-hardening validation difficult.

Findings

  • Policy conflict is not always a settings collision. Sometimes it is a scope problem.
  • User-scoped assignment of device controls creates ambiguity whenever users sign into the managed device context.
  • Reliable endpoint security depends on aligning control scope with the managed object.
  • The safest way to modernise a live configuration is often to preserve behaviour first, then remove the legacy path.

Approach

The migration strategy was simple:

  • inventory the relevant configuration policies attached to the dynamic user group
  • replicate each device-oriented policy for device-group assignment
  • apply the mirrored policies to the intended device scope
  • validate management state and device behaviour on pilot systems
  • remove legacy user-scoped assignments once the new path is stable

Risk Management

The goal was to correct the assignment model without creating disruption for users already operating in the environment. By mirroring the intended policy behaviour first and delaying removal of the old assignments until the new ones had settled, the migration reduced blast radius and made regressions easier to spot.

Validation

Validation focused on:

  • whether mirrored policies applied successfully in device context
  • whether conflicted management state reduced or disappeared on test devices
  • whether user sign-in no longer reintroduced the same pattern
  • whether removal of the legacy user-scoped assignments caused regressions

Outcome

The immediate outcome was a practical migration path for correcting scope drift across the environment. The more important change was that the conflict stopped being treated as routine noise and started being read as evidence that the assignment model itself needed to be corrected.

Lessons Learned

  • Scope alignment matters as much as the policy settings themselves.
  • Dynamic user groups can hide architectural debt when used as universal control surfaces.
  • Conflict state should be investigated, not dismissed as routine noise.
  • Preserving behaviour first and correcting architecture second is often the safest modernisation path.