Notes from the field: Windows 10 Device Compliance

One of the coolest features in Microsoft 365 is the ability to measure device compliance, and based on that reading, grant, deny or limit access to cloud resources. For mobile devices this works really well, and most compliance policies are fairly simple: make sure the device isn’t jail-broken/rooted, require a device PIN, etc. I’ve never had an issue with these settings.

Windows devices are another story. Throughout the last year of working with this feature I have seen too many instances where Windows devices mysteriously fall out of compliance for one reason or another, and lose access to resources. I have yet to see an instance of this where the compliance issue being reported is of any significant concern. It appears to be just “the way it works.”

The most common setting that trips the compliance snafu is the Antivirus requirement, specifically when third-party antivirus is present (Defender hasn’t given me any issues like this yet).

For some reason, third party antivirus solutions don’t always seem to work right with this compliance setting. I have gone to these devices, looked at the Security Center, did not see anything saying that antivirus was out of date, or disabled, or otherwise amiss in any way. Usually, simply forcing a sync on this device does the trick to clear up the issue, but because we’ve been seeing it so frequently, I have moved my default settings here to Not configured for the most part, when third-party security software is present.

Shared computers = not supported

Now I have also seen several other controls misreport from time to time, such as the firewall and others. However, I believe this is isolated to shared devices, and it’s just been too many days since the “other” user has signed in, so the compliance goes stale for that user. Vacations, conference rooms where users sign in very infrequently, employee terminations and so on.

But guess what? We shouldn’t be surprised by this–because shared devices are technically NOT SUPPORTED for use with compliance policies. Go read it here on the official docs page:

“Enroll devices to one user, or enroll without a primary user. Devices enrolled to multiple users aren’t supported.”

Crazy, right? How many small businesses out there have shared devices? Answer: hard to say, but a whole hell of a lot.

The problem is that Intune will track compliance for every associated user on a device, and if one user falls out of compliance on the device then the whole device is considered not compliant (even if the active user shows up as compliant, Conditional access is still affected by the inactive users on the device). So ridiculous, right?! If you agree, go vote it up on uservoice.

These behaviors are pretty annoying to say the least when combined with Conditional Access.

Ideal conditions…

The Goldilocks zone for Conditional access with an enforced Windows 10 compliance policy therefore seems to be:

• 1-1 device-to-user scenarios
• built-in Defender Antivirus rather than third-party

I never have these types of issues with that configuration. But there are many businesses using third-party security software, and of course, many shared machines out there in the average workplace. So, you may want to consider adjusting your compliance policies, and/or exempting these devices, is what I’m getting at. It’s less than ideal, but… there may be another way….

Consider implementing Conditional Access without a Compliance policy?

We could go with the “out of box” configuration, where devices with NO compliance policy are simply marked compliant (and this implies you should not create a compliance policy for Windows 10).

In theory, this configuration would have the desired effect. I haven’t implemented this anywhere yet, but I am considering it. Let’s move through a mental exercise here–what would be the result of simply not assigning a Windows 10 compliance policy and using the default configuration of marking devices without policies assigned as compliant?

Well, it means:

1. I cannot measure the devices for compliance, and
2. I cannot withhold access based on compliance

But, I can still create a Conditional Access policy with the control “Require device to be marked as compliant,” and it will still be meaningful. Why?

A device that does not show up in Intune can’t be considered compliant or not compliant–it just cannot be evaluated. So even though devices will automatically be considered compliant when no policy is present, the device must at least be in our inventory of enrolled devices in order to gain the “compliant” status, and have access. And that means we have visibility and leverage over the device. So while I cannot withhold access based on compliance, I can still withhold access to devices that have not enrolled.

And of course, in this configuration we are not in an unsupported configuration when it comes to shared PC’s (the problem is with compliance policies, but in this case there is no compliance policy assigned).

New access control needed

What I really wished we had was one more access control: Require device to be enrolled. That way, I could withhold access based on enrollment.

The benefits would be:

• I could hold mobile devices to a “compliance standard” while allowing Windows devices to be held only to the “enrollment standard”
• I could target specific groups with the more strict compliance requirement while leaving others such as shared devices on the lesser control
• I could make on-boarding to Conditional Access and Endpoint Manager much easier–I can start with the lesser control and smoothly transition up once I’ve nailed compliance down org-wide

Because right now it’s all or nothing: Conditional access compels not only enrollment but also compliance. And if I modify the compliance settings to allow every device to be marked compliant with or without a policy, that is a global setting–but I don’t necessarily want to relax the requirements for everyone, just Windows 10.

If you like this idea, go vote it up at uservoice also.

Departed users

The other issue is that devices could still fall out of compliance after the validity period passes. For instance, when users leave the company and a device is re-purposed for a new user. After the compliance validity period (30 days by default) the machine would fall out of compliance for the departed user and that would affect the new user of this device.

Therefore, the best thing to do in this situation is to reset the device completely and redeploy it, removing the old device object from your inventory.

If you think it’s dumb that we have to reset a device and re-enroll it when it changes owners, go vote this feature up at uservoice.

Another management task that could be avoided if the requirement were simply device enrollment, rather than compliance. Or… I don’t know, maybe Intune could be smart enough to realize when a user has departed, or a machine is being shared, or it’s changed hands? Maybe upgrade the intelligence a bit so it knows to measure only the active session on each device?!

Not measuring compliance isn’t the end of the world…

Also, let’s consider other ways we could measure compliance. I may not be able to look at a compliance policy and see which devices meet or do not meet my requirements, but I can enforce most of the same requirements using Device configuration profiles, and even report on their success or failure.

We’re not really missing that much by ditching compliance. So no Windows 10 compliance policy might just be the ticket until Microsoft improves the intelligence here or gives us another access control based on mere enrollment… And even then, don’t forget to manage stale devices, especially for departed users!

My suggestion: just keep slogging through it for now, but head over to User voice and vote these issues up! Remember that you, the consumer of these products, are responsible for the software we all have tomorrow.

Update: I ultimately decided on a very “low bar” for compliance–right now I am only enforcing a minimum OS level (1809 which is 10.0.17763). This appears to work without issue.