If you run a small company on Microsoft 365 and you want work email on everyone’s phone, you hit a question that looks simple and isn’t: how do you protect company data on a device you don’t own?

The answer is a stack of well-defined tools with clear trade-offs. Used correctly, they give you strong protection for company data and full privacy for personal data on the same phone. This is a guide to the concepts, the trade-offs, the exact setup we used — and the problems we ran into getting there, because there were several.

Why bother — the facts

A few plain reasons this is worth doing properly:

The phones are already personal. A small company doesn’t hand out corporate hardware. People check email and Teams on the device in their pocket, so that device is already in scope whether you manage it or not.
Unmanaged access is a real data path. Left alone, company mail and files sit in apps with no encryption requirement, no PIN, no control over where data gets copied, and no way to remove it if a phone is lost or a person leaves.
We hold data that matters. We operate a platform with player funds and personal information, so we hold our own internal access to a defined bar (CIS/SOC 2-style controls), not a best-effort one.
Privacy is a requirement, not a nice-to-have. Whatever we do cannot extend IT’s reach into anyone’s personal apps, photos, messages, or location.

The goal was specific: every path to company data on a phone must meet a defined security standard, without managing the personal device around it.

The problem, stated precisely

Two requirements apply at the same time:

Company data needs protection — encrypted, access-controlled, and removable if a phone is lost or the person leaves.
A personal phone belongs to the person — photos, chats, apps, and location stay private and outside IT’s reach.

Mobile device management is the tooling built to satisfy both at once. The rest of this guide is the toolbox and how the pieces fit.

The toolbox: three ways to manage a phone

Microsoft Intune offers a spectrum, not a switch:

1. MAM — Mobile Application Management manages the app. You protect the work apps and leave the rest of the phone alone. No enrollment.

2. MDM — Mobile Device Management manages the device, in two distinct flavors:

Work Profile / User Enrollment — a separate, encrypted work container on a personal phone. IT manages the container only.
Fully managed — IT manages the entire device. Appropriate for company-owned hardware, not personal phones.

Most teams consider only option 1 and the “fully managed” end of option 2, reject both, and settle for something loose. The useful option is the one in the middle.

Concept 1: MAM / App Protection

Intune App Protection Policies are the MAM layer. A policy applied to an app such as Outlook:

Encrypts company data inside the app.
Requires a PIN or biometric to open it.
Blocks copy, Save As, and Open in from company data into personal apps.
Allows a selective wipe of company data only, leaving personal data untouched.

None of this requires enrolling the device. The phone stays entirely personal; only the work apps are managed. For many BYOD cases, this is sufficient — and it was our starting point.

Concept 2: Compliance implies enrollment

The concept that ties everything together is device compliance.

A device is “compliant” when it is enrolled in management and meets health rules you define — disk encryption on, screen lock set, OS patched, not rooted, and so on. Compliance is a state the device reports and management verifies.

The key point: you cannot evaluate compliance on a device that was never enrolled. MAM’s premise is no enrollment, so a MAM-only phone is protected at the app level but can never be “compliant” — there is nothing enrolled to check. Require compliant device and “no enrollment” are mutually exclusive by design.

If you want a device-level guarantee, the device must be enrolled in something. That points to the middle option.

Concept 3: The work profile

On Android, the middle option is a Work Profile (via Android Enterprise). On iOS, the equivalent is User Enrollment. The model:

A work profile is a separate, encrypted container on a personal phone. IT manages only what is inside that container. Everything outside it — personal apps, photos, messages, accounts — is in a space IT cannot see, touch, or wipe.

Work apps appear as a badged set alongside the personal home screen, sandboxed in the container. The device becomes enrolled and compliant, scoped to the work container. Personal data stays private. “Enrollment” here means the company manages a container, not the device.

Concept 4: Conditional Access

Conditional Access (CA) in Microsoft Entra is the access gate. Before granting a sign-in, it checks conditions you define. Two grants are relevant here:

Require app protection — access is allowed if the app has your MAM policy applied. Pairs with MAM.
Require compliant device — access is allowed if the device is enrolled and healthy. Pairs with MDM / work profile.

CA is where you enforce which model you’re using. Change the grant, change the bar for access.

The path we took

With the model in place, the build is straightforward:

Start with MAM. App Protection on the work apps, plus a CA rule requiring app protection. Lightest touch.
Decide the guarantee you need. If “the app is protected” is enough, stop here — it’s valid. We wanted the device-level guarantee.
Enable Android Enterprise by linking Managed Google Play to the tenant. A one-time connection that unlocks work-profile enrollment.
Enroll the phone as a personally-owned Work Profile. A badged, encrypted work space is created, the personal side is untouched, and the device reports compliant within a couple of minutes.
Deliver the work apps from Managed Google Play — approve Outlook, Teams, Edge, and the Office apps, assign them, and they install into the container.
Move the CA grant from Require app protection to Require compliant device — the same bar used for laptops.

That’s the clean version. Here’s what actually happened.

Problems we hit, and how we solved them

1. Every managed app blocked with “device is not compliant.” Our MAM App Protection policy carried a conditional-launch rule, appActionIfDeviceComplianceRequired, set to block. When we tried to relax it, Intune only accepted block or wipe — the API rejects null and warn. Combined with Concept 2, this is a closed loop: the policy demands a compliant device, a MAM-only phone is never enrolled, so it’s never compliant, so every app is blocked and Company Portal keeps trying to enroll. It’s enforced client-side, so it never shows up as an Entra sign-in failure — a detail that makes it hard to diagnose. Fix: stop fighting the gate. Enroll the device (work profile) so it can actually be compliant, then move off MAM for that platform (problem 5).

2. Company Portal: “does not meet requirements to enroll.” Before Android Enterprise was connected, there was no work-profile enrollment path at all, so the enroll attempt had nothing to land in. Fix: connect Managed Google Play to bind Android Enterprise. That single connection is what makes work-profile enrollment available.

3. The Google account conflict — the step that cost the most time. Managed Google Play binds using a Google account that becomes the enterprise’s owner. Our business email was already tied to a personal Google account, and Google treats that as a conflicting account — it won’t let you use the same address to create the organizational/Workspace admin. This is easy to miss and it stalls everything. Fix: resolve the conflict first. Either free up the email through Google’s conflicting-account process (rename or close the existing personal Google account on that address) or use a dedicated account with no prior Google registration. Budget real time for this — it’s the single most likely thing to block a small team on day one, and it has nothing to do with Intune.

4. The work profile was empty after enrollment. Work-profile apps do not carry over from the personal side. A freshly created container has nothing in it. Fix: approve the apps in Managed Google Play and assign them to your group as Required (auto-install) or Available (self-install from the work-profile store). They then appear as badged apps in the container.

5. Still “not compliant” — even after the device was compliant. The device now reported compliant, but Outlook still refused. The cause: the MAM App Protection policy was still applied to the same app that was now MDM-managed in the work profile, and its device-compliance gate conflicted with the enrollment. MAM and MDM don’t want to co-manage the same app. Fix: commit to one model per platform. We unassigned the Android App Protection policy and switched Android’s Conditional Access grant from Require app protection to Require compliant device. The work-profile device satisfies it directly; no MAM gate remains to conflict.

6. Our own policy blocked our admin tooling — AADSTS530033. Automating the Intune changes, an admin sign-in was refused: Conditional Access declining a device-code login because that token isn’t bound to a compliant device. Fix: run privileged work from an already-compliant device so the token is device-bound — e.g. Connect-MgGraph interactively from a managed machine. The takeaway is positive: if your Conditional Access can stop a device-code login, it’s configured correctly.

On building with AI

We build in public, and we build with AI, including on operations. AI is effective at working a configuration through many branches quickly. We pair it with one rule: the AI proposes, a human decides — especially on anything that touches security. That division of labor lets a small team operate at a larger team’s pace.

The mental models to keep

MAM manages the app; MDM manages the device. Choose based on the guarantee you need.
Compliance implies enrollment. You cannot verify a device that was never enrolled, so Require compliant device and “no enrollment” cannot coexist.
The work profile is the middle option. It manages a container, not the device — device compliance and personal privacy at once.
One model per app. Don’t leave a MAM policy on an app you’ve moved to MDM; pick a lane.
Conditional Access sets the bar. Pick the grant that matches your model and let it enforce.

We put this level of care into a few work inboxes because the same discipline that secures our mobile access is what protects your account, your funds, and your data on the platform. Security is a habit that runs through the internal work, not just the parts customers see.

See you at the tables.

BYOD Done Right: A Field Guide to Securing Personal Phones with Intune