Windows Compliance

Hi SK,

I'd suggest assigning both policies to devices. Here's why, and what to check.

1. Likely cause: user-targeted compliance policies are evaluated for the users in the target group. On a shared device, a user outside that group (say F3 users when only E3 is targeted) may have no policy applied. If Compliance policy settings > "Mark devices with no compliance policy assigned as" is set to Not compliant (which Microsoft recommends with Conditional Access), that user's sign-in shows as non-compliant. You can confirm it in the Company Portal, which shows "No compliance policies have been assigned", or in the Devices without compliance policy report.

2. Fix: assign the compliance policy to a device group (for example a dynamic group on Windows OS, or All Devices with a filter). Assign the BitLocker policy (Endpoint security > Disk encryption) to devices too. The result is then the same whoever signs in.

3. Shared multi-user device profile: it's a separate profile (SharedPC CSP) that controls sign-in, account cleanup and power settings, so it won't fix compliance on its own. Use it if you want that locked-down shared-PC behaviour, and assign it to device groups.

4. Reporting caveat: compliance reports show the last signed-in user, or "System account" for device-targeted policies, so don't read too much into which user appears.

5. If BitLocker still fails after that, check TPM status and key escrow on an affected device.

E3 vs F3 doesn't change how compliance is evaluated. It's about who is targeted.

Docs: https://learn.microsoft.com/intune/device-security/compliance/overview and https://learn.microsoft.com/intune/device-security/compliance/monitor-policy