One of my Intune SA customers wants to allow BYO devices without a device PIN, but enabled managed apps used to access corporate data to be secured with a pin, while enforcing a device PIN on corporate (CORP) devices.

A pretty simple ask, but they were caught up in an underlying issue with Intune SA showing a setting as Not configured, while still enforcing any custom values entered in the setting before it was set to that state. Changing the setting to Require, defaulting everything then setting to Not configured while slotting in a save or two worked around the problem.

They have a bunch of users who use their own personally-owned iOS and Android devices to access corporate email, they do not want to enforce a password on these devices, instead, they want to use managed application policies to tighten down and secure corporate data on them; They also have a bunch of devices that are owned by the company and are not BYO, and thus need further configuration or tightening down.

Pairing off the BYO from CORP devices or users can be carried out using Azure Active Directories Groups, along with associated queries to tease them apart, much as we would in SCCM with Collections and AD security groups. We’d then use these groups to assign (deploy) policies and configurations.

The basics for getting an iOS or Android device configured so that the device does not require a PIN, or any security other than what the user has defined (biometric, pin, gesture etc), while prompting for a PIN when managed applications are accessed is pretty straightforward.

Hive off the BYO devices into a group, using manual or dynamic (queries) group types, then create the following specifically for the BYO devices and assign them to the BYO group:

Within the device profile that is used to restrict the device, Password is set to Not configured:

Note that the defaults are configured, no customisation of the settings were made before Not configured was selected.

And within the device compliance policy, both Email and System Security are tweaked. Here’s the managed email profile being enabled:

And here, system security is set so that having no device password does not make the device non-compliant:

Finally the application protection policy is configured so that a password is required, here we can see policies for both Android and iOS for application protection:


And here we have the iOS application protection policy’s access requirements configured:

The end result is that a newly enrolled device experience results in no device password enforcement for a specific group of users or devices, however, when they attempt to access their corporate email, they are prompted to setup a 4 digit PIN, or however you setup that aspect of security in your environment.

Such a light touch of a subject with many avenues to explore.

Intune has matured into a really strong platform for device and data management. There’s so much extensibility now that if you’ve already begun your journey from Active Directory to Azure Active Directory and the modern management landscape (EM:S), you cannot help feel inundated with options and flexibility that just a year or two ago we didn’t have.

An interesting observation I’ve made recently is that businesses are beginning to switch onto de-wiring parts of their existing corporate network, so as to reduce cost and align with their modern management roadmap using SDWAN or vWAN technology, reconfiguring their small to medium branch offices with far more cost effective internet connections for devices to VPN over, while installing at their larger sites network appliances pre-configured to VPN to their Azure network, the need to go side-ways is diminishing, with smaller more agile companies leading the charge on shunting or setting up most if not all of their assets in the cloud.

Azure, AAD, AD, Intune, and SCCM alone yield a rich landscape from which to design a modern infrastructure.