Last Updated on June 7, 2022 by Oktay Sari
When you configure Android Enterprise Personally owned devices with a work profile in Microsoft Endpoint Manager (Intune) to support BYOD, you probably configured the option for a Work Profile Password like the example below. If you did, and your wondering why some users complain they have to set a device PIN, the device PIN they’ve set before no longer works, or somehow the PIN requirements are different then before, continue reading. This post is all about the end-user experience with Android Enterprise Personally owned devices with a work profile and device PIN. I’ve also included a video walkthrough showing the end user experience.
This is a device configuration profile. You can configure it by going to;
- Devices > Android > Configuration Profile
- Click on Create profile
- Select Android Enterprise for Platform
- You’re creating a Device restriction profile
- The profile section is split in two
- Fully managed, dedicated, and corporate-owned work profile
- Personally-owned Work Profile
- Choose Device restrictions under Personally-owned Work Profile
The dreaded Device PIN
You might also have seen the settings to configure settings that apply to the personal profile on devices using a work profile. Read this again “settings that apply to the personal profile” In most cases, this section is left as is, without changing the default settings.
But even then, most of the time, users are setting up a new device PIN without even realizing it. Partially, this is because the Required password type is set to At least numeric by default! In other words, if the user configured a pattern at the device level (personal profile), this policy now requires the user to configure a numeric PIN!
Let’s assume you’ve configured everything and are ready for Personally owned devices with Work profiles. Now on my test device, I’ve downloaded the company portal app, signed-in with a work account and completed the work profile configuration.
Android Enterprise Personally owned devices with a work profile user experience
- Start by downloading the Company Portal app.
- Open the app and sign in with a work account.
- Follow the on-screen info and complete the work profile setup.
Right after you complete the work profile setup, you will see there are 2 notifications
- Secure your work profile (triggered by configuration profile>work profile password)
- You Need to update your work profile passcode
- Update device settings (triggered by configuration profile>password or compliance policy)
- You need to update your device passcode
Have a look at the next screenshot. Although I already have a device startup and screen lock PIN, the Company portal app gives me a notification to update my device passcode.
My device passcode in this test is 1234 (numeric/not complex), and secure startup is enabled. Most users have a very easy to remember passcode right?? Let’s see what happens when users follow the happy flow…and click on Update device settings first
Update device settings
Note: Device settings can be triggered/required either by the configuration profile, or a compliance policy! When you click on Update device settings, you’re basically going to set a new device PIN. This new device PIN will enforce the policy PIN requirements you’ve configured earlier. For this test, I’ve configured a minimum password length (6 characters) and Numeric complex.
After setting up a new complex PIN (at the device level), you’ll be able to unlock your device with this new PIN. Furthermore, you don’t need to set a different work profile PIN. You can simply open your work profile and access apps that have been deployed without entering a separate PIN.
Why is this happening? Because you’re using a work profile setting/feature that is called “Use one lock” which enables you to have one lock (PIN) for both the work profile and your phone’s lock screen and/or startup PIN. Use one lock, is enabled by default! More on this later…
Secure your work profile
Now, lets start over again, but this time, were going to click on Secure your work profile.
When you click on Secure your work profile, you’re configuring a separate PIN for your work profile only. Your existing 4 digit easy to remember device PIN will still work at the device level, but when you want to work with apps in your work profile, you’ll need to use your work profile PIN before you’re allowed to use the apps. Please note: Your existing 4 digit device PIN will work assuming you don’t have a compliance policy requiring more than 4 digits. More on this later.
Why is this working different then update device settings? Because when you click on Secure your work profile first. The Use one lock setting is disabled, making it possible to have a different PIN at the device level and work profile.
Good to know
In most cases, when a user starts with “Secure your work profile”, the other notification “Update device settings” will show up, depending on what you configured for password requirements in your configuration profile, or compliance policy. In rare occasions, the user already configured a work profile PIN (disabling One Lock), but when they also click on “Update device settings” (enabling One Lock again) they are configuring a new device PIN. Still with me?
No PIN configured at all
Then there are also users, who simple swipe their phone to unlock it. They have no PIN configured at all. Well, in these situations. The users are prompted to set a device PIN and in this example the user also needs to enable secure startup.
Impact of Compliance Policies
IMPORTANT: Remember that these password/PIN requirements can also be required by a compliance policy! In this example, secure startup is something that I require for devices to be compliant. It is triggered by the Encryption requirement in my compliance policy. Also note, that compliance policy settings always have precedence over configuration profile settings. And to make it more complex, the default required password type for a compliance policy is Device Default. And for a configuration policy (at the same device level) it is At least numeric. That means that when both are configured, the compliance policy will win!
When you create a compliance policy, you can choose between 2 profile types:
- Fully managed, dedicated, and corporate owned work profile
- 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 Android Enterprise device configuration settings.
So if you don’t want this to happen on personal devices, then set it to Not Configured at compliance policy level, and configure your configuration policy to require a PIN when the user opens the apps in the work profile. If you do require a password, then remember that swiping will be disabled at the device level, after the user configures a PIN. Swiping is equal to not having a password, and (although not documented) this seems to be logical to me.
Use one Lock
When you configure a work profile, new settings for your work profile become available and you can configure these settings by going to
- Search for Work Profile
- Click on Work Profile settings
Have a look at theses settings and get to know what each setting does so you can support/educate your end-users. Here’s what Microsoft has to say about One Lock;
Better user experience?
You might want to test all of this before deploying it to all your users. Think about your communication and adoption strategy. Perhaps, you’ll even want to configure the Password settings that apply to the personal profile on devices using a work profile. For example, you could require users to have a PIN at the device level with a minimum password length set to 8 😊. This way users always have to configure two separate PINS. Not sure if that’s a good thing for end-user experience, and I can imagine you’ll have some good discussions about Android Enterprise Work profile configuration settings. I’m sure you do test everything you configure in Microsoft Endpoint Manager. Get yourself some test devices or test with virtual android devices.
Tip: Make sure the right stakeholders and decisionmakers are engaged and well informed!
Although the Number of sign-in failures before wiping device is set to 5, it will only wipe the work profile 😉 So all, personal files and photo’s are untouched… Click on the screen/tool tip for more info:
“Number of consecutive times an incorrect password can be entered before the work profile is removed and corporate data is wiped. (4-11)”
One can argue that it is a No Go to require users to enable encryption, disable swipe, block USB debugging, block rooted devices or require a complex numeric PIN using compliance policies (or configuration policies for some settings) but remember this;
It’s always a choice. If the user chooses, not to set a pin or encrypt his/her device the only thing that happens is that the user cannot access corporate data on his/her personal device. Everything else still works like it always did.
On the other hand. As a company, of course you have the right to set the requirements, personal devices must meet, before users can safely access corporate data on these devices. It’s not a bad thing you know… This way, we are protecting the user from unknowingly leaking data and at the same time, we are also protecting proprietary/corporate data.
I guess it all comes down to what and how you communicate these requirements and changes that might impact how users where used to work. If you want a high adoption rate, make sure you are crystal clear in your communication strategy.
Here’s a video walking through the user experience on Android Enterprise Work profile, step by step. Hope this helps and don’t be shy to post a message about your experiences.