Ready to read this content aloud.
Executive summary
This case study documents the extension of the organization’s endpoint-management strategy to corporate Android phones.
The objective was not simply to install applications remotely. The device needed to enter a managed lifecycle from initial setup: enrollment, employee association, restrictions, software delivery, threat protection, remote actions, and later compliance evaluation for access to corporate resources.
Because the phones belong to the organization, are assigned to one employee, and are not intended to operate as personal devices, the selected model was Android Enterprise Corporate-owned, fully managed.
Sensitive implementation details remain private. Internal identifiers, URLs, keys, operational QR codes, group names, and application-specific corporate parameters are intentionally omitted or generalized.
My role
I led the validation of the Android Enterprise model, the enrollment design, device-restriction policies, application delivery, Microsoft Launcher configuration, and the integration of Microsoft Defender into the mobile security flow.
The most important part of the work was turning lab results into a supportable onboarding process. That required separating what Intune can actually enforce centrally from what still depends on the device vendor, the application, or a local action by IT or the end user.
This case study extends the broader From On-Premises Active Directory to Microsoft 365: Identity, Email, and Endpoints in Four Months project, but focuses only on Android management.
Why Corporate-owned, fully managed
The requirement was to administer company-owned phones used individually by employees for work.
In this scenario, maintaining an independent personal profile would create an unnecessary boundary between IT and an asset that remains owned by the organization. The Fully Managed model was selected so that administrative settings, corporate applications, accounts, security requirements, and maintenance actions remain under company control.
Integration with Managed Google Play provides the Android Enterprise application catalog without requiring employees to use personal Google accounts to install the software needed for work.
From factory reset to managed endpoint
Enrollment begins with the phone reset and still in the initial Android setup flow.
Factory-reset device
↓
QR-code enrollment
↓
Corporate authentication
↓
Microsoft Intune registration
↓
Automatic device identification
↓
Restrictions + required applications
↓
Remaining manual application configuration
↓
Microsoft Defender activation
↓
Compliance evaluation
↓
Corporate access according to policy
The enrollment profile was also adjusted to assign a user-based naming pattern automatically. This reduces manual renaming and makes it easier to associate each device with the employee responsible for it.
The result is a process in which the phone enters management before it is delivered, rather than relying on the user to configure the device afterward.
Restrictions and lifecycle control
The first baseline was designed to prove that IT retained administrative control over the device.
Validated behaviors included blocking user-initiated factory reset, blocking personal Google accounts, preventing changes to management-related accounts, and requiring Google Play Protect threat scanning.
The policy was later expanded during the pilot to evaluate Android system updates, screen-lock behavior, user restrictions, and application-update settings.
Not every tested control was immediately promoted to a production standard. Developer options remained available during diagnostics, and an aggressive wipe-after-failed-attempts setting was treated as a high-impact control requiring further evaluation before broad rollout.
Device protection and lifecycle actions
Beyond account and system restrictions, the pilot evaluated reset protection, encryption, password behavior, and remote response as parts of the same device-protection lifecycle.
Reset blocking was validated through both normal Android settings and the behavior observed in the recovery menu of the pilot device, where the wipe option was not exposed in the tested state. Factory Reset Protection remains an additional layer: preventive blocking was demonstrated, while full validation of the authorized-account recovery flow still requires a separate destructive test.
Storage encryption was already active natively on the pilot device and can be used as a measurable compliance signal. PIN or password enforcement, however, behaved inconsistently across the device and enrollment method evaluated, so it was not promoted to a mandatory requirement in this phase.
That decision also affects remote response: remote lock is more effective when a screen credential already exists. On a lost phone without a PIN or password, a full remote wipe may become the safest available response as long as the device remains connected and can receive the Intune command.
Application delivery: three different models
Software standardization used different delivery methods depending on application origin.
Public applications such as Outlook, Teams, and WhatsApp Business were delivered through Managed Google Play. Corporate web applications could be exposed as managed links. Business applications supplied directly as APK files required the Android Line-of-Business app model in Intune.
This distinction matters because “Android application” does not represent a single management model.
Outlook with managed corporate identity
Outlook received a managed application-configuration policy to reduce errors during first use and restrict the application to the corporate identity associated with the enrolled user.
The policy does not eliminate authentication, but it allows Outlook to recognize the intended account and reduces the opportunity for personal accounts to be added to the corporate client.
APKs and package identity
Two applications required for operations could not be published as private Managed Google Play applications because their Android package identifiers were already registered in the Google Play ecosystem.
The workaround was to distribute them directly as Line-of-Business APKs through Intune.
That solved installation but transferred part of the update lifecycle to IT. For an upgrade to work predictably, the vendor must preserve the package name, signing certificate, and use an increasing versionCode. Changing package identity or signing material can turn a simple upgrade into a reinstall and potentially risk local application data.
Where automation stops: Managed Configurations
Installing an APK does not mean being able to configure it remotely.
One business application in the pilot depends on a QR code containing connection parameters. Because the application does not expose Android Managed Configurations, Intune has no supported channel for pushing those values directly into the app. IT therefore continues to perform that configuration during onboarding.
The same boundary appeared with RustDesk on Android. Intune can install the APK, but the version used in the pilot does not expose managed settings for server parameters and other internal options. Android application sandboxing also prevents a management platform from simply editing the application’s private files in the same way a Windows deployment might use scripts and configuration files.
The preferred improvement therefore depends on the application itself: support for Android Managed Configurations or a vendor-provided build designed to receive corporate parameters through a supported management interface.
This was one of the most important lessons from the pilot: MDM cannot automate an interface that the application does not expose.
Standardizing the user experience with Microsoft Launcher
Microsoft Launcher was used to reduce experience differences between device manufacturers and models.
In the pilot, it was delivered through Managed Google Play and configured as the default launcher. IT could standardize aspects of the home screen, dock, search placement, and the user’s ability to rearrange selected elements.
Corporate wallpaper deployment behaved inconsistently and remained a low-impact follow-up item. The rest of the Launcher configuration remained functional after reboots and device synchronization.
Launcher does not replace security policy. Its role is to provide a more predictable user experience and simplify onboarding while account management, restrictions, protection, and lifecycle control remain the responsibility of Android Enterprise and Intune.
Microsoft Defender as Mobile Threat Defense
Microsoft Defender was delivered as a required application and configured as the Mobile Threat Defense layer for the managed Android device.
The pilot validated capabilities including anti-phishing, Network Protection, device visibility in the Microsoft Defender portal, and a reduced-interaction onboarding configuration.
However, low-touch is not no-touch. The user still needs to open Microsoft Defender and complete the steps shown by the application before integration becomes fully effective.
After activation, Android displays a local VPN used by Defender to inspect connections and provide web protection. This is not a tunnel into the company’s internal network; inspection occurs locally on the phone.
The Xiaomi / HyperOS limitation
The pilot device also exposed a problem that could not be solved only through Intune policy.
On Xiaomi devices, additional battery, autostart, and background-execution controls can continue to interfere with Microsoft Defender even after the standard Android permissions available to Intune have already been granted.
The onboarding procedure therefore needs a practical validation step: Defender must remain operational after screen lock and reboot, stay visible in the portal, and retain web protection.
This matters because the environment contains a meaningful number of devices from this manufacturer. The vendor-specific behavior therefore becomes part of the operating procedure rather than a one-off pilot detail.
Defender, compliance, and Outlook access
The planned architecture treats Outlook as one of the more sensitive mobile resources because it provides direct access to corporate email.
The intended flow is:
Intune enrollment
↓
Corporate applications
↓
Defender activation
↓
Device-risk signal
↓
Compliance Policy
↓
Conditional Access
↓
Outlook / Exchange Online
The goal is that installing Outlook and knowing a password should not be enough. The phone should also be managed, protected, and within the organization’s accepted risk level.
At the stage documented by the pilot, this represents the planned enforcement architecture. Defender integration and security signaling were validated, but the final access requirement should still be enabled gradually using the same pilot-first approach applied to Windows management.
WhatsApp Business and the boundary between device management and data governance
Because personal Google accounts remain blocked, WhatsApp Business does not use an employee’s personal account for conversation backup. Planned device replacements use direct transfer before the old phone is wiped.
That process does not cover loss, theft, or total device failure. Business records therefore should not exist exclusively inside WhatsApp: MDM administers the device, but it does not guarantee recovery of every application’s internal data.
Pilot results
The pilot demonstrated a functional mobile-management lifecycle: Fully Managed enrollment, employee association, centralized application installation, personal-account restrictions, lifecycle controls, Microsoft Launcher standardization, active encryption, Microsoft Defender integration, and security signals suitable for future compliance and access policy.
More importantly, the work also made the operational exceptions explicit:
- applications without Managed Configurations still require local setup;
- directly distributed APKs transfer part of the update lifecycle to IT;
- password enforcement requires further validation before production enforcement;
- remote lock is less effective without an existing PIN or password;
- Factory Reset Protection still has a destructive validation step pending;
- Xiaomi devices may require additional configuration and manual verification of Defender background execution;
- the user still participates in the initial Microsoft Defender activation.
These limitations do not negate the management model. They define precisely where platform control ends and application or device dependencies begin.
Next steps
The next stage is to reduce exceptions without hiding their risk: reevaluate the password baseline, complete destructive FRP validation, turn Defender signals into effective compliance and Conditional Access requirements, and work with software vendors to expose Android Managed Configurations for applications that still require manual onboarding.
The operating procedure also needs to preserve manufacturer-specific checks for aggressive background-process controls and validate new APK versions before wider distribution.
What this case study demonstrates
Android Enterprise gives IT a strong administrative boundary over corporate devices, but modern management is not unlimited automation.
The quality of the result depends on three layers working together: what the MDM can enforce, what Android and the device vendor allow, and what each application was designed to accept.
Documenting those boundaries was as important as enabling policy. It made onboarding more predictable and avoided turning real Android limitations into zero-touch promises that the environment cannot yet fulfill.