Android Enterprise Management with Intune Explained: Fundamentals and BYOD

Android Enterprise Management Overview

Android Enterprise is the modern framework for managing Android devices in enterprise environments. It defines how Android devices are enrolled, managed, and secured, and it replaces older, legacy management approaches that offered limited control and inconsistent user experiences.

When Android Enterprise is used with Microsoft Intune, it provides a structured way to manage different device ownership models while keeping a clear boundary between corporate and personal data where required. Rather than treating all Android devices the same, Android Enterprise allows management to adapt to how a device is owned and used.

At its core, Android Enterprise answers a simple question:
How much control is needed over the device, and who owns it?

The answer to that question determines which deployment model is used.

From an Intune perspective, Android Enterprise is not a single mode or configuration. It is a set of management capabilities that support different scenarios, such as personal devices used for work, fully corporate-owned devices, or task-based devices with no personal usage at all. Each scenario has different expectations around security, privacy, and operational effort.

This is why Android Enterprise is best understood as a management framework, not just an enrollment method. Enrollment is only the entry point. What happens after enrollment, such as isolation, policy scope, app distribution, and access control, is what defines the actual management experience.

---

Android Enterprise deployment scenarios

Android Enterprise is designed to support different ways Android devices are used in organizations. Instead of a single management model, it provides multiple deployment scenarios that align with device ownership and usage patterns.

In Microsoft Intune, these scenarios are typically grouped as follows.

• BYOD (Personally-owned devices with Work Profile)
  Personal devices used for work, where corporate apps and data are isolated inside a managed work profile. The personal side of the device remains untouched, while the work profile is fully managed.
• COPE (Corporate-owned devices with Work Profile)
  Company-owned devices that still allow a degree of personal use. A work profile is used to separate corporate data from personal data, even though the device itself belongs to the organization.
• Fully Managed (Corporate-owned fully managed user devices)
  Corporate-owned devices with full device-level management. These devices are typically dedicated to work use and do not rely on profile-based separation.
• Dedicated devices (Kiosk or task-based devices)
  Corporate-owned devices configured for a specific purpose, such as kiosks, shared devices, or frontline scenarios. These deployments often do not involve personal user accounts.

Each scenario comes with different expectations around security, privacy, enrollment complexity, and ongoing management. Choosing the right one depends less on technical preference and more on how the device is owned and how it is expected to be used.

For this guide, the focus will be on BYOD using a Work Profile. This scenario strikes a balance between security and user privacy and is commonly used when employees bring their own Android devices into the workplace. The remaining scenarios will be covered separately, building on the same Android Enterprise foundation.

---

Preparing Intune for Android Enterprise

Before starting any Android Enterprise deployment, the Intune environment needs to be prepared. These steps ensure that enrollments behave consistently and that devices follow the intended management model from the beginning.

This preparation does not configure BYOD itself yet. Instead, it ensures that the required services are in place and that modern Android Enterprise enrollment paths are available.

Linking Managed Google Play to Intune

Android Enterprise relies on Managed Google Play for application distribution and management. Without this integration, Android Enterprise enrollment profiles cannot function correctly.

From the Intune admin center:

Devices → Android → Android enrollment

Under Android Enterprise, Managed Google Play appears as a required prerequisite.

To proceed, Intune must be linked to a Google-managed organization account. Starting the setup redirects you to Google’s enterprise sign-up flow, where consent is required for Intune to communicate with Google services.

If Microsoft Entra ID is detected, Google provides the option to sign in using a Microsoft account instead of creating a separate Google identity.

Once the setup is completed successfully, Intune shows Managed Google Play as Setup, along with the linked account and organization details

At this point, the Android Enterprise backend integration is ready.

Controlling enrollment using device platform restrictions

Before moving into any Android Enterprise scenario, it is important to verify device platform restrictions. This is where Intune controls which Android management types are allowed to enroll.

To reach this configuration:

Devices → Android → Android enrollment → Device platform restriction

This section acts as a gatekeeper. Even if enrollment profiles exist, devices cannot enroll unless the corresponding platform and management type are allowed here.From the Device platform restriction page, switch to the Android restrictions tab.

This view shows the active restriction profiles applied to users. By default, Intune includes a built-in restriction named All Users, which applies globally unless overridden by a higher-priority rule. Opening the All Users restriction allows you to review the effective Android enrollment settings.

On this screen, the goal is simply to confirm that Android Enterprise (work profile) is allowed. This is the setting that determines whether Android devices can proceed with a work profile during enrollment.

If this option is blocked, the work profile option will not appear during enrollment. No other configuration in Intune can override this behavior.

This step ensures that Android devices are allowed to enroll using the Android Enterprise work profile model.

BYOD: What it is and when it makes sense

So far we talked about Android Enterprise as the modern baseline. Now let’s zoom into the scenario most orgs start with first: BYOD (Bring Your Own Device).

In BYOD, the device belongs to the user. That means we have to balance two things:

1. Security: company data shouldn’t leak to personal apps, personal cloud backups, screenshots, etc.
2. User trust: we shouldn’t manage the whole phone like it’s corporate-owned.

That’s why BYOD on Android usually becomes a “two-layer” setup:

• Android Enterprise work profile (MDM side): creates a separate work container on the device
• App Protection (MAM) policies (App layer): controls what users can do inside apps like Outlook/Teams/OneDrive (copy/paste rules, PIN, encryption, screenshot block, offline limits…)

In this part of the guide, we’ll start with the App Protection policy, because it’s the part that directly protects the data in Microsoft apps and it works great as a baseline in BYOD.

Step 1: Create a pilot group for Android BYOD

Before we create any App Protection (MAM) policy, we need a simple target group. This keeps assignments clean and makes it easier to test first, then roll out.

1. Open Intune admin center and go to Groups
   Click New group.
2. Create a Security group
   Give it a clear name like: Android Users (or BYOD Android Users if you want to be extra clear).
3. Keep membership simple at first
   Set Membership type to Assigned.
4. Add your test user(s) as members
   Click Members, select the user(s), and save.

Step 2 : Configuring App Protection Policies

App Protection Policies (APP) are the cornerstone of mobile application management in Intune. They protect corporate data within apps without requiring device enrollment, making them ideal for BYOD scenarios where users want to keep their devices unmanaged but still access work resources securely.

Understanding App Protection Policies

App Protection Policies work at the application layer, not the device layer. Key characteristics:

• Application-Level Control: Policies apply only to managed apps (Microsoft apps, apps integrated with Intune SDK)
• Data Containment: Prevents corporate data from leaking to personal apps
• No Device Enrollment: Works on unenrolled devices (MAM-only scenarios)
• User Privacy: IT has no visibility into personal apps or data
• Conditional Access Integration: Can be combined with Azure AD conditional access for comprehensive security

Creating an App Protection Policy

Go to Apps > App protection policies, click Create and select the Android platform

Configure Basic Settings

Enter a descriptive policy name (for example, BYOD Android App Protection), optionally add a description for documentation purposes, verify that the platform is set to Android, and then click Next

Select Target Apps

Choose which apps the policy will protect. For BYOD scenarios, typically select Microsoft 365 apps -> Click Select public apps and Select the following Microsoft apps (recommended):

1. Microsoft Outlook
2. Microsoft Word
3. Microsoft Excel
4. Microsoft PowerPoint
5. Microsoft Teams
6. OneDrive
7. SharePoint

Data Protection Settings

These settings control how corporate data can be transferred, stored, and shared. They are the core of preventing data leakage in BYOD scenarios.

Setting	Recommended Value	Rationale
Backup org data to Android backup services	Block	Prevents corporate data from being uploaded to personal Google Drive or other backup services where IT has no control. Critical for data residency and compliance requirements.
Send org data to other apps	Policy managed apps	Only allows data sharing between apps protected by Intune policies. Users can work across managed apps, but cannot copy-paste corporate data to personal apps.
Save copies of org data	Block	Prevents “Save As” to unmanaged locations. Users cannot save corporate documents to personal cloud storage, SD cards, or local device storage outside the managed app container.
Transfer telecommunication data to	Any dialer app	Allows users to tap phone numbers in emails/chats to make calls using device’s native dialer. Essential for productivity – blocking would force manual number entry.
Receive data from other apps	Policy managed apps	Controls what data can be imported into managed apps. Setting to “Policy managed apps” prevents users from opening personal files in managed Office apps, reducing data mixing risks.
Restrict cut, copy, and paste between apps	Policy managed apps with paste in	Optimal balance: users can cut/copy/paste between managed apps, and can paste data into managed apps from anywhere, but cannot copy corporate data out to personal apps.

Encryption and Functionality Settings

Setting	Recommended Value	Rationale
Encrypt org data	Require	MANDATORY for compliance. Encrypts all corporate data at rest using platform encryption. If device is lost or stolen, data remains protected. Required by most data protection regulations (GDPR, HIPAA, etc.).
Encrypt org data on enrolled devices	Require	Ensures Android Enterprise Work Profile encryption is enabled. Modern Android devices (8.0+) support hardware-backed encryption, providing strong protection with minimal performance impact.
Screen capture and Google Assistant	Block	Prevents screenshots of sensitive data. Blocks Google Assistant from reading screen content. Critical for preventing inadvertent data leaks through screenshots saved to personal cloud or shared on social media.
Approved keyboards	Not required	In BYOD scenarios, forcing specific keyboards can frustrate users. Unless you have specific security requirements (regulated industry), the user experience benefit outweighs the theoretical keyboard logging risk.
Printing org data	Block	Prevents printing from managed apps on personal devices. Users might print to home printers or public print services creating uncontrolled copies of corporate data. Alternative: Allow printing but add watermarks.

Access Requirements (Authentication)

Access requirements define how users must authenticate to access corporate data in managed apps. This is your first line of defense against unauthorized access.

PIN Configuration

Setting	Recommended Value	Rationale
PIN for access	Require	Essential security control. Users must enter a PIN (separate from device unlock PIN) to access managed apps. Prevents unauthorized access if device is unlocked but left unattended.
PIN type	Numeric	Numeric PINs are faster to enter on mobile keyboards. Balance between security and usability. For higher security, use Passcode (alphanumeric).
Simple PIN	Block	Prevents simple patterns like 1234, 0000, 1111, or sequential numbers. Significantly improves security against guessing attacks.
Select minimum PIN length	6	6 digits provides 1 million combinations (with simple PIN blocked, effectively more). Balances security with memorability. 4 digits = too weak. 8+ digits = user frustration.
Biometrics instead of PIN for access	Allow	HIGHLY RECOMMENDED. Fingerprint or face recognition provides faster access while maintaining security. Users more likely to comply with frequent authentication. PIN still required as fallback.
Override biometrics with PIN after timeout	Require	After biometric updates (new fingerprint enrolled) or extended inactivity, require full PIN entry. Prevents unauthorized biometric enrollment attacks.
Timeout (minutes of inactivity)	30	30 minutes balances security and usability. Shorter (15 min) = user frustration during meetings. Longer (60 min) = security risk. Users working actively won’t be interrupted.
PIN reset after number of days	90	Quarterly PIN rotation reduces risk from compromised PINs. More frequent rotation leads to predictable patterns or written-down PINs. Annual or never = too long.
Number of previous PIN values to maintain	3	Prevents PIN reuse. With 90-day rotation and 3-PIN history, users cannot reuse a PIN for 9 months. Stops the common pattern of alternating between 2 PINs.
Work or school account credentials for access	Require	CRITICAL for identity verification. Periodically requires full Azure AD authentication (username + password + MFA). Ensures the person using the app is the actual account holder. Integrates with conditional access.
Recheck the access requirements after (minutes of inactivity)	30	After 30 minutes of inactivity, re-validate that the user still meets access requirements (device compliance, conditional access policies). Ensures real-time enforcement of security posture changes.

Conditional Launch Settings

Conditional Launch defines the automated responses when devices or apps don’t meet security requirements. These settings enforce your security baseline and protect against compromised devices.

App Conditions

Condition	Recommended Action	Rationale
Max PIN attempts Value: 5	Reset PIN	After 5 failed PIN attempts, force user to reset PIN using full Azure AD credentials. Prevents brute force attacks while allowing legitimate users who forgot their PIN to regain access.
Offline grace period Value: 1440 minutes (24 hours)	Block access (minutes)	Allows 24 hours of offline work (airplane mode, no network). After that, app requires online check-in to verify policies. Prevents indefinite offline access on stolen devices.
Offline grace period Value: 90 days	Wipe data (days)	NUCLEAR OPTION. After 90 days offline, automatically wipe all corporate data from managed apps. Protects against long-term data exposure on lost/stolen devices or devices of terminated employees.

Device Conditions

Condition	Recommended Action	Rationale
Jailbroken/rooted devices	Block access	NON-NEGOTIABLE. Rooted/jailbroken devices bypass Android security. Attackers can extract encryption keys, read memory, intercept data. Immediately block access. No warnings.
Samsung Knox device attestation	Block access on supported devices	For Samsung devices, Knox provides hardware-level attestation of device integrity. More reliable than software-based root detection. Blocks access if Knox detects tampering, custom ROMs, or bootloader unlock.

Policy Assignment

The final step is assigning the policy to your user groups. This determines who receives the protection policies.

1. Click Add groups under Included groups
2. Search for and select “Android Users” group
3. Review all settings and click Create

End-User Enrollment Experience

This section walks through the user experience when enrolling an Android device with a Work Profile, helping IT teams understand what users see during enrollment and set clear expectations for the process.

Step-by-Step Enrollment Process

Step 1: Install and Open Company Portal

1. User downloads Intune Company Portal from Google Play Store
2. Opens the app and taps Sign In

Step 2: Sign In with Work Account

1. User enters their corporate email address
2. Redirected to Microsoft authentication page
3. Completes Azure AD authentication (password + MFA if required)

Step 3: Begin Work Profile Setup

Company Portal displays setup steps:

1. Create work profile
2. Activate work profile
3. Update device settings
4. User taps BEGIN

Step 4: Accept Work Profile Terms

1. Android system displays work profile explanation
2. User can tap View terms to see privacy policy
3. Taps Accept & continue

What Users Should Know About Work Profile

• Privacy Protected: IT cannot see personal apps, photos, messages, or browsing history
• Visual Separation: Work apps have a briefcase badge. Personal apps don’t
• Data Isolation: Can’t copy-paste between work and personal apps (by policy)
• Pause Work: Can pause work profile to stop work notifications during off-hours
• IT Visibility: IT can see: work app list, compliance status, device model/OS. IT cannot see: personal data, location (unless configured), web browsing

Step 5: System Creates Work Profile

1. Android automatically creates encrypted work profile container
2. User sees privacy notice: “Data in your work profile is visible to your IT admin”
3. Taps Next

Step 6: Complete Enrollment

Company Portal completes all three setup steps:

1. Create work profile
2. Activate work profile
3. Update device settings
4. User taps CONTINUE

Step 7: Work Profile Activation

51. User taps BEGIN to activate work profile
52. System processes activation

Step 8: Enrollment Complete

1. Company Portal shows: “You’re all set!”
2. User now has access to:
3. Work email (Outlook)
4. Wi-Fi and VPN profiles
5. Managed Google Play Store for work apps
6. Ability to manage their device in Company Portal

Step 9: Work Profile on Home Screen

Users will see a separate “Work” section on their home screen containing work apps, each marked with a briefcase badge:

Post-Enrollment Verification

In Intune admin center, go to Devices > All devices . Verify the device appears with:

• Managed by: Intune
• Ownership: Personal
• OS: Android (personally-owned work profile)
• Compliance: Compliant
• Primary user: User’s email address

---

Android Enterprise Work Profile enables organizations to secure corporate data on personal Android devices without managing the device itself. By applying protection at the application level, corporate data remains isolated, encrypted, and controlled, while users retain full ownership of their personal apps and information. A successful BYOD implementation relies on setting clear boundaries rather than enforcing excessive restrictions, ensuring strong security without compromising usability or user trust.

In the next part, the focus will shift to Corporate-Owned devices with Work Profile (COPE), exploring how Android Enterprise balances control and personal use on organization-owned devices.