This blog explores the behavior change in Intune’s built-in compliance policy, specifically why devices are still marked as compliant even when the original enrolled user has long since left the organization.
Introduction
Intune’s default device compliance policy seems straightforward. A device just needs a compliance policy; it has to check in with Intune, and the enrolled user must still exist. Simple, right? That used to be the case. But recently, we noticed something funny and odd at the same time: devices were still marked as compliant even after the enrolled user had been deleted from Entra ID. Which is pretty weird, and it doesn’t line up with what we were told.
Turns out, things have changed. Intune’s compliance logic is now leaning more toward the device itself rather than relying on the enrolled user. In this post, we’ll break down what’s happening, where each compliance check runs, and why devices might now remain compliant even when they shouldn’t. Let’s start with an overview of the default device compliance policies.
The Three Default Device Compliance Policy Checks
The built-in/default device compliance policy comes with three core checks that determine whether a device is considered compliant or if it’s headed straight for restricted access. These checks come down to three key points:
- Has Compliance Policy Assigned
- Is Active
- Enrolled User Exists
Each of these compliance checks helps ensure devices meet your security and management standards. But only the first two are checked locally.
Exploring Each Default Device Compliance Policy Setting:
To understand what’s really happening under the hood with these compliance updates, it’s worth breaking down the key settings involved with each compliance policy. Each compliance setting plays a specific role in keeping devices secure and compliant with Intune policies.
1. Has Compliance Policy Assigned
- JSON Property: DefaultDeviceCompliancePolicy.RequireDeviceCompliancePolicyAssigned
- Description: This setting ensures that a compliance policy is actively assigned to the device. If no policy is found, the device is immediately marked as non-compliant, resulting in potential restricted access or alerts.
2. Is Active
- JSON Property: DefaultDeviceCompliancePolicy.RequireRemainContact
- Description: Validates that the device is actively communicating with Intune. If a device has not checked in recently, this may indicate the device is lost, tampered with, or otherwise unmanaged.
3. Enrolled User Exists
- JSON Property: DefaultDeviceCompliancePolicy.RequireUserExistence
- Description: Ensures there is a valid enrolled user. Initially, removing or deleting the original enrolled user would trigger non-compliance.
The Enrolled User Exists compliance policy was problematic for shared or reassigned devices. However, recent changes have made this requirement more flexible. Let’s find out how this compliance policy is checked!
Where is “Enrolled User Exists”?
Intune’s default compliance settings, such as Has Compliance Policy Assigned, Is Active, and Enrolled User Exists, seem straightforward enough. However, as I discovered when exploring the selfserviceportal.dll (company portal / IME bridge), things are a bit different.
This DLL file only “Has Compliance Policy Assigned” and “Is Active” actually gets checked when you press “Check Access” in Company Portal.
The Enrolled User Exists part? Nowhere to be found locally!!! This points to a service-side check, which we can’t directly influence on the device. So, while it looks like a missing piece, it’s really Intune’s backend handling that specific EnrolledUserExists compliance call.
Shall I let you in on a secret? Do you want to hear a funny thing as well? The “Is Active / Enrolled User Exists” section is also not even mentioned in the MSDocs anymore.
Even while Microsoft Support still mentions that if a user is deleted, the device will become non-compliant.
Shall we check if that is still really the case?
What seems to have changed silently?
More than a year ago, changing a device’s Primary User was a good (not the best) workaround for the “Enrolled User Exists” compliance requirement. Back then, switching the Primary User didn’t directly affect the enrolled user status, but it kept the device compliant by updating the RegisteredUsers and Owners fields.
This meant that as long as a new primary user was assigned, Intune played along, and the device remained compliant, even if the original user was no longer there.
However, this behavior seems to have changed, and now changing the Primary User started influencing the immutable “Enrolled by” field itself, which wasn’t something you could alter without re-enrolling the device.
However, somehow, changing the primary user also changed the enrolled user.
One thing is for sure…more than a year ago, the enrollment was stuck with the old user.
The Recent Default Device Compliance Policy Changes Explained
But guess what? After a while, Microsoft changed this behavior (again?), AKA rolling back the change? After changing the primary user, the enrolled user is (again) NO LONGER getting updated. At that same time, things started to get weird.
For instance, if a device was enrolled by User A, but you logged in with User B and subsequently deleted User A, the device still retains its compliant status..
This is weird, as the device should not have been compliant to my knowledge and to Microsoft as well (as we seen earlier)? But somehow, the Default Device Compliance Policy: Require User Existence state is pretty compliant.
How We Tested This Behavior
We rigorously tested this behavior using the below approach
- Step 1: Initial Enrollment with User A:
- Enrolled the device using User A, verified that the compliance policy was successfully assigned, and the device showed as compliant.
- Step 2: Logging in with User B:
- Logged in with User B and observed that the device remained compliant.
- Step 3: Deleting User A from Azure AD:
- Deleted User A entirely, expecting the device to fall into a non-compliant state. Surprisingly, the device remained compliant even when the primary user UPN looked very weird
It appears that we no longer need to change the primary user for the device to regain compliance. As shown below, even Graph believes the device is compliant with that weird primary user UPN… which doesn’t exist in Entra anymore and is replaced with a fake user?!
However, it remains best practice, as without this, tasks such as installing apps from the Company Portal will not function without the device being the primary user.
Why Devices Aren’t Falling Out of Compliance Anymore
It seems Intune’s compliance checks have become a bit more flexible with recent updates. Now, even if the “Enrolled by” and “Primary User” fields are blank, the device can still stay compliant as long as it meets the “Has Compliance Policy Assigned” and “Is Active” conditions.
It’s almost as if Intune is ready to keep compliance rolling with whichever user logs in next, rather than tying compliance to a single original user. This approach improves compliance tracking, especially in environments where user roles shift frequently. This results in fewer false negatives, less disruption, and a more device-centric approach that handles reassignments.
Conclusion
For IT admins dealing with shared or dynamic environments, this compliance shift is significant. With Intune now focusing more on device status and checking the latest active user, compliance has become more adaptable to real-world scenarios. This change helps keep devices compliant, reducing the chances of enforcement issues, even when user assignments change unexpectedly.
Does that mean I no longer have to wipe the device when passing it to a different user? NO!! Even with this change, in my opinion, the device should always be wiped when you pass it to a new user!