Should employees reach company data from their own phones? BYOD, MDM and MAM

Letting employees reach corporate mail and files from their own phones is not forbidden, and in most small and mid-sized companies it has been happening for years without anyone writing it down. The question worth asking is not whether they get access but under what control. There are two distinct technical answers: manage the whole device (MDM) or manage only the app and the data inside it (MAM). The first asks for a level of control people rarely welcome on a phone they paid for. The second does nothing at all if you configure only half of it. The workable setup is not one choice for the company, it is a decision made role by role.

The numbers explain why an unmanaged device belongs in its own category. When Verizon's 2025 DBIR analysed credential logs from infostealer malware, 46% of the compromised systems that held corporate logins turned out to be non-managed devices carrying both personal and business credentials. In the same analysis 30% of the systems could be identified as enterprise-licensed devices. The 2026 DBIR then found that 41% of social engineering breaches now arrive through channels other than email, roughly a quarter of those via social media or phone-based routes. The reason the phone deserves separate attention is simple: most multi-factor authentication already runs on it. Compromise one handset and the attacker collects the password and the second factor in the same move.

The device belongs to the employee, the data still belongs to you

Under Article 12 of Turkey's KVKK, the data controller has to take appropriate technical and organisational measures to prevent unlawful processing of and access to personal data. Who owns the hardware does not change that duty. If your sales representative's own phone holds a customer list inside a WhatsApp thread, your company is the one processing that data, and the phone bill being in someone else's name does not move the obligation. The same logic runs the other way too. Because the device is personal, you cannot demand visibility into or control over the personal side of it. That is where the technical part of every BYOD argument comes from: you have to draw a line in a place where both parties have a fair point.

If you want a framework to lean on, NIST SP 800-124 Rev. 2 (May 2023, replacing Rev. 1 from 2013) covers organisation-owned and personally owned devices together and follows the full lifecycle from deployment through use to disposal. Its most useful contribution is not the control list but the order of the questions: which data genuinely needs mobile access, against which threat, enforced by which control. Plenty of companies start at the end of that sequence by buying an MDM product first.

MDM manages the device, MAM manages the data

The difference fits in one sentence. MDM enrols the device and applies policy at device level; MAM never enrols the device and instead controls the data inside the corporate app. On personally owned phones, the second is usually the right starting point.

On the Microsoft side this is what Intune app protection policies do. With no device enrolment, they can require an app PIN or biometric check before corporate data opens, encrypt only the data marked as corporate, restrict cut, copy and paste out of managed apps, block saving company data to local storage or a personal cloud account, refuse to run managed apps on rooted or jailbroken devices using Google's Play Integrity checks, and selectively wipe company data out of an app without removing the app itself. Microsoft groups these settings into a three-level data protection framework: level one is PIN, encryption and selective wipe, level two adds data leakage controls and minimum OS requirements, level three is aimed at people handling high-risk data.

Know the limits before you promise anything. App protection policies only work on apps built with the Intune App SDK, which means Outlook, Teams, Word, Excel, Edge, OneDrive and similar. On an unenrolled device they cannot deploy apps, provision certificate profiles, or push corporate Wi-Fi and VPN settings. On Android the Company Portal app has to be installed for policy to reach the device at all. Every targeted user needs an Intune Plan 1 licence, which is bundled into Business Premium and the E3/E5 stack. If you run on Google Workspace instead, basic management gives you a screen lock requirement and the ability to remove the corporate account remotely; policy control and the power to wipe an entire device sit in advanced management, and advanced management is not included in Business Starter or Business Standard.

Writing the policy is not enough, you have to close the other road

This is the step most often skipped. Defining an app protection policy does not by itself shut the unprotected path. If the same user can sign in through mobile Safari or the phone's built-in mail client, every restriction you configured is simply bypassed. What closes the road is a conditional access policy: on iOS and Android, require that corporate resources are reachable only from clients covered by an app protection policy.

One change here has already landed and it affects companies still running the older configuration. The "Require approved client app" control in Microsoft Entra conditional access moved to a read-only state on 30 June 2026. Existing policies using that control keep being enforced for end users as long as they stay enabled, but an admin can no longer edit them or create new policies with it. The grant to use going forward is "Require app protection policy". Factor in one warning while you migrate: if an app does not support that control, users trying to reach resources from that app get blocked. Turning the change on in report-only mode first and reading who it would have hit costs far less than a Friday evening of support calls.

The separation the operating system gives you for free

Android and iOS both draw the work and personal boundary at OS level on personally owned phones, and that part does not depend on which product you buy.

The Android Enterprise work profile keeps work apps and their data in a separate space on the device. The organisation fully manages the apps, data and settings inside the work profile and has no visibility into the personal profile at all. When the work profile is removed, only work data goes; the personal side stays untouched. Android 15 reinforced the boundary from the other direction with Private Space, letting the user create a separate area inside their personal profile behind an extra layer of authentication. It is not available on fully managed devices, and on company-owned devices admins can switch it off by policy.

Apple's equivalent is account-driven User Enrollment. Corporate data is written to a separate managed APFS volume, and the administrator can only see and manage apps, certificates and policies on that volume. They cannot read device identifiers such as UDID, IMEI or MAC address, cannot manage apps outside the managed volume, cannot wipe the whole device, and cannot put it into supervised mode with this enrolment type. What gets managed is the organisation's accounts and settings, never the user's personal account.

"We can wipe the phone if we need to" is the sentence that kills the programme

Remote wipe is where BYOD policies meet the most resistance, and it is fair resistance, because two very different operations get described with the same word. A full wipe returns the device to factory settings, which includes the family photos. A selective wipe clears only the company data inside the managed app and does not even uninstall it. On personally owned devices the second should be the default; a full wipe is a power that belongs to hardware the company bought.

Put that in the policy in language an employee can actually read, not in product terminology: what IT can see, what it cannot see, and exactly what gets deleted in which situation. A policy signed without being understood is a policy you cannot enforce on the day you need it.

Most BYOD losses come from resignations, not attacks

The incidents that actually happen are rarely sophisticated. They are messy exits. A departing employee keeps customer conversations on their phone, a downloaded price list, a spreadsheet synced to a personal cloud account, and nobody checks. The off-boarding list should be short: revoke session tokens rather than only resetting the password, trigger a selective wipe in the corporate apps, remove the user from access groups, remove the corporate account from the device. Then accept one thing honestly. Data that already left through a screenshot or a message to a private address does not come back with any wipe command. That is why the everyday restrictions on moving data, not the cleanup at exit, are what protect you.

A minimum set for a company that will not run a full MDM programme

Six items, in order. Screen lock with biometric unlock required. A minimum OS version defined and checked when the corporate app launches, because patch management does the same job on mobile as it does on servers. Company data kept inside managed apps only, with saving to personal cloud storage and the photo gallery blocked. Authentication done with passkeys or, where that is not possible, a phishing-resistant second factor. Corporate apps refusing to open on rooted or jailbroken devices. And a one-page policy covering all of it that the employee has signed.

It is worth naming what this set does not solve. MAM protects the data inside the app, not the device around it. With no endpoint visibility on the phone, you have no record to reconstruct what happened on it after an incident. When the role carries real risk (a finance user who authorises payments, an administrator with access to production), issuing a company-owned device stays the cheapest option. Knowing what you can and cannot do on personal hardware also lets you write the mobile section of your incident response plan honestly. And employees moving work data into tools tied to their own accounts, as in the shadow AI case, is the same problem wearing different clothes.

You do not need to pick a product to get started. Start with a table: which role reaches which data from mobile, whether that access is genuinely needed, and whether you want to manage the device or the data for that role. At Wedevit we build that table with you, decide between MDM and MAM per role, write the policy in language an employee can sign, and test the conditional access side in report-only mode before it locks anyone out. If you want to review access rights across the whole organisation, the topic continues in Zero Trust architecture.