InTune password policy for personal disabling pattern and swipe options

luvsql, So you do need a password on personal devices to meet compliance.  Ok, I've again checked the configuration and can confirm I have a working scenario. I'm willing to show you my test tenant configuration and test device setup if you thing that it can help you out.

When I require a password from within the compliance policy and set this to Low security biometric like this:

And configure the configuration profile password settings like this: Required password type: Device default.

Please note: The default in your configuration policy is At least numeric, so check this. In theory, It should also work if you had set this to Low security biometric. (the same as the compliance policy).

Then the user experience is:

Swipe is disabled because it is not a password. Pattern is still working. It's better then not having a password. You are requiring a password with the compliance policy so it's logical that swipe (no password) is disabled. But it's only disabled when the user sets a pattern or PIN, or something else.

I think the logic behind this is this: If swipe would have been left enabled, the device could become non compliant again, had the user decided to switch back to swipe. I know it's a user decision, but still, It does seem logical to go this way. And it's still a user decision right? Because the user can still choose to not set a pattern, or pin. But then the device is not compliant, and I guess, your conditional access policy blocks non compliant devices. 

Can you check your config or try to setup a new one for a test device?

Again, I'm willing to show you my test tenant configuration and test device setup if you thing that it can help you out. Just send me a DM.

Hope this helps.

Regards,

Oktay

luvsql , Here's the video : https://youtu.be/62-gl0dMaTA PS, the PIN I use here is Donald Duck's birthday I use for testing  (There is no audio in this video)

Just to be clear, When you create a compliance policy, you can choose between 2 profile types:

1. Fully managed, dedicated, and corporate owned work profile
2. Personally-owned work profile

Option 1 is for corporate owned devices, and option 2 will target personal devices.

When you choose option 2 and require passwords, the documentation tells you this: 

This setting applies at the device level. If you only need to require a password at the Personally-Owned Work Profile level, then use a configuration policy. See https://docs.microsoft.com/en-us/mem/intune/configuration/device-restrictions-android-for-work.

So if you don't want this to happen on personal devices, then set it to Not Configured here, and configure your configuration policy to require a PIN when the user opens the apps in the work profile.

If you are dealing with corporate devices, you can configure a compliance policy for Fully managed, dedicated, and corporate owned work profile.

I know it can be very confusing and perhaps even worrying, but this is how it works. When you configure App protection policies for example, With Windows Information Protection Without enrollment, you can require the user to set-up windows hello on their personal devices, before they can access corporate data. 

So yes, some of these setting you configure, apply at the device level and outside the work profile. This is documented at different locations but here's an example for the compliance policy. https://docs.microsoft.com/en-us/mem/intune/protect/compliance-policy-create-android-for-work#device-properties---for-personally-owned-work-profile

Oktay Sari Yes and it's set to Low security biometric.  These are personally owned devices so we should not be messy with these users own settings.  We should be able to have requirements for the work profile to whatever we need and require any kind of password for personal, which I did have set but config policy only has "Password Required" and Compliance doesn't so you have to pick something.