Device Compliance

Occasional Contributor

Hi All,


Is anyone else see incorrect reporting of device compliance due to the "System Account"? As per Microsoft documentation:


"Windows 10 devices that are Azure AD joined may show the System Account as a non-compliant user. This is expected behavior and doesn't affect the overall device compliance."


This seemed to be working OK until about 2 weeks ago. We are using:


Hybrid joined device in a co-managed state - Windows 10 1709 and SCCM 1806. The slider for device compliance is set completely to Intune.


We end up with results like this:




and the device is then overall marked as non-compliant:




This example is just ridiculous, as everything is actually compliant yet the System Account is marked Not Compliant and the device is as well.


Seems to be so inconsistent... and we are using CA policies which are locking out users.


35 Replies

Did you ever get any response or resolution to this issue? we are having the same problem, doesn't seem to be any obvious resolution to the problem.

Hi Dustin,


Hope you are well. Unfortunately I have now left the company were I was deploying the above solution. However, as per the engineers onsite they have advised the issue is resolved with the January update to 1709.


Microsoft related the fault to this issue:


Despite this being an 1809 quality update:


"Addresses an issue with Microsoft Intune that causes devices to be incorrectly marked as not compliant because a firewall incorrectly returns a 'Poor' status. As a result, the affected devices will not receive conditional access compliance approval and may be blocked from access to corporate resources such as email."


So upgrade to the latest version of 1709 and see if it resolves the problem.


My issue was sporadic so I am guessing you will probably need to patch 50+ machines to truly see results.

Our workstations are all on 1803, rapidly upgrading to 1809. Interestingly, even though we already knew about the firewall issue and opted to exclude the check from our CA policies for the moment, most of the non-compliant machines are failing the AV check for the "System Account", even though the same check shows compliance under the user identity.


Perhaps, as is often the case, the code base will fix that as well for the machines that haven't yet upgraded to 1809, have to wait a few weeks to know for sure.


Thanks for the response though.

I also have issue, where we deploy Intune "Compliance policy" to "All Users", and is also effecting the integrated "System Account" and overall device compliance status.

Example is also, for shared devices (shared meeting room windows pc etc.)

We have latest Windows 10 - 1809 with all further updates

Going to +1 this, while Microsoft's own documentation does state that non-compliance for the System Account will not impact a machines' overall compliance, it can make proactively addressing compliance issues more difficult. For example, the Machine compliance report in InTune seems to be correctly ignoring machines where the non-compliance is the System Account identity, but the Power BI report pack that leverages the InTune data warehouse does not. 


Ideally, if the compliance state of the System Account doesn't matter, it would be preferable that InTune ignore the identity entirely and didnt report on it.

Have the same issue on several configuration policies in Intune reporting Error or Failed on the System Account
best response confirmed by Hrvoje Kusulja (MVP)

@Baljit Aujla I have figured out the solution.

When you have Compliance policy, assigned to All Users, it will reflect all your Azure AD users with those logins. But what about other (local accounts), like "system account" etc.., they are not compliant.

Resolution is to have another additional (same) compliance policy, assigned to Azure AD security group, and add those (shared) windows 10 devices to the group.

In that case, Compliance policy is assigned on device level to the specific device, and then "system account" does not cause the problem.

It is poorly documented, but this is something that Microsoft Support given to me...

@Hrvoje Kusulja 


In our case, our Compliance policy is targeted to an Azure AD Security group with all of our Windows 10 machines in it already, reading this it sounds like I have to duplicate the policy exactly then assign it to a group of Users as well?

@Dustin Adam in that case, I am not sure, you can try and post feedback.

My case, i was assigned to (all) users, and additionally assigned to devices, to resolve system account issue.

@Hrvoje Kusulja 

Did you have to create a copy of the compliance policy, or simply assign the same policy to multiple groups that included both users and computers?

@Dustin Adam in my case (all users) there is no option to assign the same policy to other things then. I think it should be enough to have one policy and assign to multiple security groups at the same time..

@Hrvoje Kusulja 

Awesome, thanks! I'll give it a shot. 

Any resolution for you Dustin? I still have System Account showing as not compliant, with the Compliance profile assigned to device security group as well as the user security group. Company Portal app tells the user they are out of compliance.


It didnt work for me, we still have a bunch of clients that are failing compliance because of the System Account.

I had the same issue until we updated Windows@Dustin Adam 

@Baljit Aujla 

@Oliver Kieselbach 


I also have this problem. Devices are set to AD security group "windows 10 only" devices.

When adding the laptops to Azure AD, they will get both the system account and user account.

Sometimes, there's no problem, but other times, things like "require bitlocker" only fail on the system account, and the entire devices gets marked as non-compliant!

Laptops are on 1809.

Still no fix?

Mine is working :p sorry, not be able to help more..

I've had this problem too and I'll share my experience here:

If you assign policies to a device it applies the policies to all accounts on that device, including the system account (which will usually bring trouble for the compliance and such). I've not had any cases in which the system account was actually needed in Intune.
In most cases it is better to just assign the policies to the users and I usually use a dynamic group with all enabled users in it instead of 'All users'. If they then change device it will automatically migrate all policies and apps to that device as well, which will save us some time. Only when you work with special shared devices is assigning them to the device itself useful in my opinion (and even then there are some good cases for user assignment).
Simply reassigning the policies to users instead of devices won't make that system account go away in the portal though. You will have to delete the policy and make a new one, then assign it to the users only, then there won't appear a system account.

This is what I have found out from experience. I might be wrong but it has worked for me in the past. If someone wants to correct me about my policy assignment best practices, feel free to do so. I'm relatively new to Intune.

In my opinion there is a major!! flaw in compliance reporting by Intune. The problem we encounter with shared devices forced us to completely disable all compliancy checks for those devices.


The situation:

  • User 1: logs on to the device
  • User 1: marks the device as not compliant for whatever reason
  • User 1: Logs of from the device before remediation could be started
  • User 2: Logs on to the device
  • User 2: The device gets remediated
  • User 2: tries to open a resource that requires a compliant device and is denied access because the device is NOT compliant

The only solution is... let User 1 sign in again and remediate the device under User 1....


In my opinion this is absolutely unacceptable.... The solution is called DEVICE compliance. So how the beep is it possible that the DEVICE wont be set to compliant when a different user logs on to the device and remediates the issue that marked the device to be non compliant.....


For another customer of ours, an admin needed to logon to a users device and marked that device as non compliant. Result was the user wasn't able to access resources that required a compliant device.


Especialy with shared devices we cannot trust the Device Compliance solution the way it works now. This is a huge issue in a world where compliancy is one of the key components to secure access to resources.