It’s become very common in the United States and must of the rest of the world for employers not to purchase phones for employees and, at the same time, it has become very common for employees to want to carry parts of their workday on their phones. Since a business owns its data regardless of what device is accessing it, how can we allow businesses to retain control of their data while allowing employees to enjoy accessing that data on their personal devices? At my MSP, we decided that as our clients’ trusted advisers that we needed to take the lead on controlling business data. We saw our clients hand-wringing either in denial that employees were accessing their data at all or that there was nothing that could be done about it. We also saw employees bristling at the idea of the business putting any controls on their personal devices. We decided to look for a middle ground using the tools that the business already owned in the Microsoft 365 business, Azure P1, and Cloud App Security licenses.
Proving that there’s a problem
You might first need to prove to the business that there is a problem. The easiest way to do this is to look into Azure AD under Devices. Here you’ll see a list of all of the devices that touch the business data.
If you are investigating whether there is a problem with unmanaged mobile devices accessing data in the business, then use Azure AD to gather a list of phones that are doing so. If any of them were not authorized to access business data or are unknown to the company — there’s a problem.
When you visit this screen further to the right, you’ll see the email address of the user that this phone is associated with. I’ve removed that for privacy reasons but this will assist you in identifying whether you know these phones or not.
First, you need a policy on business data
The business likely got into this situation because the corporation has no policy for employees to follow regarding the management of business data on their personal phone. So, before IT can configure its policies, IT needs to know what the corporate policy is. Once we have that we can design our compliance and security policies to match.
In your policy, employees need to understand that their personal phone could be subject to eDiscovery or forensic searches if it has business data on it and that some reduced level of privacy is assumed when business data is present on a personally owned device. Your policy is also going to inform them of the security and compliance requirements for the device and their responsibility to report replacement, theft, or loss of the device within a specific time.
With today’s modern mobile device management, we can control the corporate data and wipe only the corporate data and keep the corporate data in secured locations on the phone. This means for the employee, these policies are also going to keep the business out of their personal stuff, which is also a good thing.
It wasn’t too long ago that it was just a pipe dream to segregate corporate data from personal while preventing cut, paste, save, snip, etc. Then for a while, you could do it but it was complex and expensive. Now it’s just part of Intune and simple to do.
Create compliance policies
You are supposed to decide to manage business data on phones before it becomes a problem and before the data gets there because there’s no undoing what has already been done. By that, I mean that if the employee has already saved corporate data in their personal space we can’t retrieve it. All we can do is prevent that from happening again.
The first policy that we want to set up is the compliance policies. Your business may have specific requirements for this policy. What I am showing is a suggested minimum for a business with no regulatory requirements.
You’ll need a policy for each phone platform. To create a policy, go to Devices, Device Compliance, Policies and then press Create New. Decide which phone this policy is going to be for and choose it. For managing a personally owned Android phone, you’ll choose Android device administrator. For iPhones, choose iOS.
Inside of each policy you are going to configure the Settings section and the Actions for Non-Compliance section.
For both of these policies, because they are not corporate-owned devices, we have to be careful about not being too controlling of the device. Our policies, therefore, are going to be concerned with making sure that the device meets minimum security standards before allowing its use for corporate data. This includes things like minimum OS version, making sure it’s not jailbroken or rooted, and that the apps on the phone are from a safe source. We have slightly different options for each OS that we’re going to configure.
After we’ve chosen our device settings, we then move to the Actions for non-compliance and create your items here. In my example, we are marking the device as noncompliant so the admin will notice and we are also sending an email to prompt the phone owner to bring the device into compliance. Our iOS settings are similar.
Creating application policies
Now that we have created our device policies it’s time to manage the corporate data. To do this we’re going to create an app protection policy for each OS as we did above. Only this time we’re going to define what is a corporate app and what can happen with the data.
For this, we go to Client Apps, App Protection policies and Create New. In the Targeted Apps section, select all of the apps where you are going to manage corporate data. Save, then select Properties.
Start with data protection and work your way down the configuration of the policy. Choose the settings appropriate for your corporate policy. In the example below, we are not allowing data backup in iCloud since iCloud is a personal storage location. We are also keeping corporate data within the managed apps.
Take the time to read the information bubbles. They will save you from hitting some gotchas. For example, people will want to be able to copy and paste say from Outlook into Teams, or from the browser. Allowing paste lets the phone user paste data into the corporate location but does not allow them to copy/paste data out of the corporate apps.
Another gotcha involves the Contacts app on the phone. Most people like to be able to browse their contacts and initiate a call from the phone app. This setting populates the Outlook contacts into the native app. For some businesses, this may represent a security hole but for many, usability to going to win and you’ll want to allow this functionality.
Moving down the configuration of the policy we come to Access requirements. Most of Microsoft’s demos show a PIN being required to access an application. I prefer credentials now that phones offer face recognition. This will mean that when they open one of the corporate apps, Outlook for example, that they will have to authenticate in whichever manner you choose.
Moving down the configuration of the policy again, Conditional launch allows you to configure what happens to your data when the phone goes offline. Consider this a fail-safe. Here I’m choosing to block access to corporate data after 720 minutes offline and then wipe the data from the device if it goes offline for 15 days. I’m also blocking access to corporate data from rooted devices and warning the owner if the device is running an older OS.
Once you’ve configured your policies you need to assign them. Definitely assign your policies to some test users before rolling it out companywide. Some of the settings in there will surprise you with their consequence so make sure that your test subjects are real functional users.
As you can see, it’s not difficult anymore to manage devices. Microsoft has wizardized most of the process for you and Intune offers a nice set of options. No more does business have to shrug their shoulders at losing corporate data on personal devices. Once you have your policies in place, the corporate data can be accessed and used easily on mobile devices while the corporation retains control and ownership over its data. And when it comes time to wipe, only the data inside the managed apps will be removed. All of the owner’s personal data remains.
Featured image: Shutterstock