Android 15 Enterprise Security Overview
Android 15 marks the most consequential Android Enterprise API transition since Google deprecated the Device Administration API in Android 10. The release accelerates several deprecation timelines that EMM vendors and enterprise IT teams have been tracking since Android 12, and introduces new Work Profile behavior changes that affect how BYOD deployments function.
For IT administrators managing Android Enterprise fleets through BlackBerry UEM, Microsoft Intune, VMware Workspace ONE, or SOTI MobiControl, Android 15 requires proactive preparation — not because it breaks existing deployments immediately, but because the API migrations it forces have firm deadlines that are now within standard enterprise upgrade cycles.
Google's Android Enterprise release notes for Android 15 are organized around three themes: privacy improvements for Work Profile users, Device Admin API deprecation acceleration, and new managed configuration capabilities.
Each theme has direct operational implications for enterprise EMM configurations. This guide addresses each in the detail required for IT administrators planning Android 15 rollout strategy and policy updates.
Work Profile Changes in Android 15
The Work Profile — Android Enterprise's mechanism for separating work apps and data from personal content on employee-owned devices — receives two behavioral changes in Android 15 that affect how IT administrators configure and communicate BYOD policy.
First, Android 15 changes the Work Profile pause behavior. In Android 14 and earlier, pausing the Work Profile was an immediate, user-initiated action with no MDM override. Android 15 allows EMM platforms to configure constraints on Work Profile pause — specifically, organizations can now set a maximum pause duration or disable the pause feature entirely for policy-compliant enrollment scenarios.
This is particularly relevant in healthcare and financial services environments where continuous MDM monitoring of device health is a compliance requirement.
Second, Android 15 expands the cross-profile data sharing restrictions available to EMM administrators. New managed configuration keys allow IT administrators to restrict clipboard sharing between the personal and work profiles with more granular control than the existing allow/block binary.
The new controls distinguish between clipboard content categories, allowing organizations to block sharing of sensitive content while allowing general text clipboard operations. This is a significant improvement for regulated-industry BYOD deployments where blanket clipboard blocking caused significant user friction.
Android 15 also introduces a change to Work Profile notification handling on the lockscreen. In Android 14, work application notifications were visible on the lockscreen subject to the standard Android notification visibility settings.
In Android 15, work application notifications on the lockscreen are subject to the MDM-configured notification policy independently of the device's personal notification settings. EMM platforms can now configure whether work notifications appear on the lockscreen without conflicting with user-configured personal notification visibility.
IT administrators should test their MDM platform's notification policy implementation on Android 15 test devices before fleet rollout, as the behavior change may require policy updates to achieve the intended configuration.
Deprecated MDM APIs: What IT Teams Need to Migrate
Android 15 continues the deprecation of Device Administration (DA) API capabilities that have been progressively restricted since Android 10. The critical understanding for enterprise IT teams is the distinction between soft deprecation (the API still works but generates a deprecation warning) and hard removal (the API call returns an error or has no effect). Android 15 moves several DA APIs from soft-deprecated to hard-removed behavior.
The RESET_PASSWORD Device Admin policy, which allowed Device Administrators to set the device screen lock password remotely, is hard-removed in Android 15 for all enrollment modes. This API was previously available only in legacy Device Owner mode and had been soft-deprecated since Android 12.
Organizations with legacy workflows that relied on remote password reset via a Device Admin application must migrate to Android Enterprise fully managed enrollment with MDM-driven password reset mechanisms available through the Android Enterprise API before deploying Android 15 to devices using those workflows.
Screen capture restriction via the Device Admin setCameraDisabled and related APIs has also transitioned to hard-restricted behavior in Android 15. Device Admin applications can no longer globally disable camera access on devices not enrolled in Android Enterprise fully managed or Work Profile modes.
Organizations using legacy Device Admin-based MDM configurations with camera disable policies on non-AE-enrolled devices will find these restrictions have no effect on Android 15 devices. Migration to Android Enterprise enrollment is the only path to restoring enforced camera restrictions.
Google's published Android 15 DA removal list also includes setStorageEncryption (encryption is now mandatory and OS-enforced, not DA-settable), getEncryptionStatus (replaced by the Android Enterprise API), and several legacy Device Admin policy setters that have Android Enterprise equivalents. EMM vendors publish compatibility matrices for these removals — IT administrators should verify their platform's migration guidance document before testing Android 15 on any device where these APIs were in use.
New Managed Configurations in Android 15
Android 15 expands the Android Enterprise managed configuration API with new restriction keys that enterprise IT teams can use to enforce policy on managed devices. The most operationally significant additions are in the network and application management categories.
In the network category, Android 15 adds managed configuration support for per-app network restrictions — allowing EMM administrators to configure which managed applications can access specific network interfaces (Wi-Fi, cellular, VPN-only). This extends the per-app VPN concept with more granular control: an application can be configured to operate only when connected through a managed VPN tunnel, failing gracefully when VPN is not active rather than falling through to unencrypted cellular or Wi-Fi.
In the application management category, Android 15 adds new managed configuration keys for controlling application auto-update behavior on fully managed and Work Profile devices. Previously, managing application update timing on Android Enterprise devices required using the managed Play Store configuration to defer all updates — a blunt instrument that delayed security patches alongside feature updates.
Android 15's new keys allow EMM administrators to configure per-application auto-update windows, allowing immediate security-patch updates for critical enterprise applications while deferring feature updates for other applications to coincide with IT testing cycles.
Android 15 also introduces new managed configuration options for the Android Enterprise Work Profile notification settings described in the Work Profile changes section above. These are delivered as standard Android Enterprise managed configuration payloads through the EMM platform's managed configuration interface — no special SDK integration is required in the EMM platform beyond support for the new Android 15 managed configuration schema.
Screen Capture and Privacy Changes for Enterprise Apps
Android 15 introduces a system-level notification displayed to users when applications access the device's screen content through the Android MediaProjection API. This affects enterprise applications that use screen recording or screen sharing features — remote assist tools, screen sharing in collaboration applications, and device monitoring applications that capture screen content for audit or support purposes.
The new notification is a user-facing indicator that runs regardless of application permission status. For fully managed enterprise devices where screen recording is an authorized capability, the new notification may generate user confusion. EMM platforms can configure a managed configuration to suppress the notification for approved applications on fully managed devices.
IT administrators should verify with their EMM vendor and the vendors of remote assist applications in their fleet whether Android 15 screen capture notifications are addressed in application or EMM managed configuration updates.
Android 15 also changes the behavior of sensitive content detection in screenshot blocking. Applications can mark content as sensitive using the Android FLAG_SECURE window flag, which prevents that window's content from appearing in screenshots and screen recordings. Android 15 extends the FLAG_SECURE enforcement to the partial screenshot API — users attempting to take partial screenshots of sensitive-flagged content will find the sensitive content obscured even in partial capture.
For enterprise applications handling financial data, PHI, or classified content, this improvement provides better accidental disclosure protection without requiring additional application-level controls.
Device Admin Deprecation: Final Stage in Android 15
The Android Device Administration API represents the legacy MDM management model that predated Android Enterprise. Google has been progressively restricting DA functionality since Android 9, with each Android release removing or disabling additional DA capabilities. Android 15 represents what Google has characterized as the final deprecation stage — after Android 15, the remaining DA APIs that are still functional are those with no Android Enterprise equivalent.
Organizations still managing Android devices through DA-based MDM configurations are in an increasingly precarious position: each Android release further erodes the management capabilities available through the legacy path.
The primary organizations still using Device Admin-based management in 2026 are those with legacy EMM deployments that predate Android Enterprise, typically organizations that standardized on an EMM platform in the 2012-2018 period and have not fully migrated.
The migration path requires re-enrolling devices in an Android Enterprise enrollment mode and recreating MDM policies using Android Enterprise APIs. Most major EMM platforms have supported Android Enterprise enrollment alongside DA enrollment for several years — the migration is primarily an operational project, not a platform-selection project.
For organizations still running DA-managed devices that will receive Android 15 OS updates, the specific APIs removed in Android 15 should be evaluated against the organization's current policy configuration. Google publishes a DA-to-AE migration guide with specific API mapping for each deprecated capability. The migration should be completed before Android 15 reaches majority on the managed device fleet, which typically occurs 12-18 months after an Android version's initial release.
Android 15 Compatibility with BlackBerry UEM and Intune
BlackBerry UEM's Android 15 compatibility is documented in the UEM 12.20 release notes. UEM 12.20 adds support for Android 15 managed configuration schema changes, including the new per-app network restriction keys and the Work Profile notification policy additions. The UEM platform's Android Enterprise enrollment modes — fully managed, Work Profile, and COPE — are all compatible with Android 15-enrolled devices on UEM 12.20.
Organizations running earlier UEM versions should consult BlackBerry's compatibility matrix, which documents which UEM versions support Android 15 device enrollment and which Android 15 API features are available per UEM version.
BlackBerry Dynamics SDK-enabled applications require an update to the Dynamics SDK version compatible with Android 15 for optimal functionality. Android 15 changes to the Android Runtime (ART) optimization model affect cold-start performance for applications; Dynamics SDK-enabled apps that have not been updated to the Android 15-compatible SDK may exhibit longer cold-start delays.
Microsoft Intune's Android 15 compatibility is documented through the Intune product documentation and What's New monthly updates. Intune's Company Portal application on Android 15 receives an updated version that addresses the DA API deprecations — organizations using Company Portal for Android enrollment should verify that enrolled devices are running the current Company Portal version before Android 15 OS updates are deployed.
For Intune App Protection Policies, Android 15 SDK changes require updated Intune App SDK versions in managed applications — Microsoft publishes the required SDK versions in the Intune App SDK changelog.
Enterprise Enrollment Mode Changes
Android 15 refines several aspects of the Android Enterprise enrollment process that IT administrators should be aware of before deploying Android 15 across managed fleets.
Zero-touch enrollment receives an improvement to the device provisioning UX in Android 15. The setup assistant flow for zero-touch provisioned devices is condensed in Android 15, reducing the number of screens presented to the end user during initial device setup and improving provisioning time. Organizations using zero-touch enrollment for fully managed device deployments benefit from this improvement without requiring any configuration changes — the provisioning flow improvement is automatic for zero-touch provisioned Android 15 devices.
Work Profile enrollment via QR code provisioning receives an update in Android 15 that allows QR codes to encode additional managed configuration parameters at enrollment time. This enables more complete out-of-the-box configuration for Work Profile-enrolled BYOD devices, reducing the number of post-enrollment MDM policy push cycles required before the device is in its intended managed state.
Android 15 also changes the enrollment experience for COPE (Fully Managed with Work Profile) devices. The personal profile setup in COPE enrollment is updated in Android 15 to present clearer user-facing disclosure of what the organization can and cannot see on the device. This change is non-configurable — it is a mandatory disclosure improvement that Google has implemented to improve user understanding of the COPE enrollment data boundary.
IT administrators should update their COPE enrollment user documentation to reflect the new setup flow before Android 15 COPE enrollments begin.
For organizations managing Android alongside iOS devices, coordinating the Android 15 and iOS 18 enterprise upgrade cycles requires scheduling consideration. Both OS releases include API changes requiring EMM platform updates and policy testing — attempting to roll out both simultaneously in a mixed-OS fleet increases the risk of encountering unknown interaction effects before either rollout is validated.
Frequently Asked Questions
What is the difference between Device Admin and Android Enterprise for EMM?
Device Administration (DA) is the legacy Android MDM management model, available since Android 2.2. DA allowed an application designated as a Device Administrator to enforce a limited set of device policies — password requirements, screen lock timeout, remote wipe, and camera disable — without deep OS integration. Android Enterprise (AE), introduced in Android 5.1 and progressively expanded, is a comprehensive enterprise management framework built into the Android OS that provides EMM platforms with far deeper management capability through Android Enterprise APIs. The key differences: AE supports multiple enrollment modes (Work Profile, Fully Managed, Dedicated Device, COPE) with appropriate data isolation models for each; AE provides thousands of managed configuration parameters accessible through the Android Management API or Device Policy Controller (DPC); AE enrollment is the mandatory path for AER-certified devices. Google has been deprecating DA capabilities since Android 9, and Android 15 accelerates this toward the DA APIs with no AE equivalent being the only ones that remain functional.
What does Work Profile pause mean for employee-owned BYOD devices, and can IT disable it?
Work Profile pause is a user-initiated feature that allows employees to temporarily suspend the Work Profile — pausing work app notifications, disabling work app access, and pausing MDM compliance monitoring for the device — without disenrolling from MDM. It is intended for use during out-of-office periods and personal time. In Android 14 and earlier, EMM administrators could not configure Work Profile pause behavior — users had full control over whether and how long they paused the Work Profile. Android 15 adds EMM-configurable constraints: administrators can now set a maximum pause duration (after which the Work Profile automatically resumes) or disable pause entirely for compliance-sensitive deployments. The appropriate policy depends on the organization's regulatory requirements and employee relations considerations. Organizations with continuous compliance monitoring requirements should review whether enabling pause duration limits or disabling pause is appropriate for their regulatory context.
Which Device Admin API removals in Android 15 will break existing MDM configurations?
The hard removals in Android 15 that are most likely to affect existing enterprise configurations are: (1) RESET_PASSWORD — if any workflow in your MDM platform uses DA-based remote password reset, it will fail silently on Android 15; migrate to Android Enterprise password reset APIs. (2) Global camera disable via DA APIs — if your MDM uses a DA application to enforce camera restrictions on non-AE-enrolled devices, the restriction will have no effect on Android 15 devices; migrate to AE fully managed enrollment with the AE camera restriction policy. (3) setStorageEncryption — if any MDM configuration calls this API, it will return an error on Android 15; remove the API call (encryption is OS-enforced). Identifying whether your EMM configuration uses these APIs requires checking with your EMM vendor's Android 15 compatibility assessment, as the APIs are called by the EMM DPC application rather than directly by IT-configured policies.
How does per-app network restriction in Android 15 differ from per-app VPN?
Per-app VPN routes specific application traffic through a VPN tunnel while allowing other application traffic to flow through the standard network path. The EMM administrator configures which applications are included in the VPN tunnel by application package name, and the VPN client enforces routing accordingly. Android 15's new per-app network restriction is a managed configuration layer that sits above per-app VPN: it allows the EMM administrator to specify that an application may only transmit data through a specific network interface (VPN interface, Wi-Fi, cellular) or to require that an application blocks network access entirely when no VPN tunnel is active. The practical effect is that the per-app VPN "fail-through" behavior — where an application falls back to unencrypted network access when VPN connectivity drops — can now be blocked by policy. For applications that must never transmit data outside of an organizational network tunnel, the new per-app network restriction adds a safety net on top of per-app VPN configuration.
What is the COPE (Corporate Owned Personally Enabled) enrollment mode and when should IT teams use it?
COPE (Fully Managed with Work Profile) is an Android Enterprise enrollment mode for corporate-owned devices that employees also use for personal purposes. Unlike pure Fully Managed mode, which places the entire device under organizational control with no personal space, COPE creates both a managed corporate profile (with full MDM control) and a personal profile (which the organization cannot access or manage). The organization owns the device and sets device-level policies (screen lock, encryption, OS update schedule) but employees can use the personal profile for personal applications and data. COPE is appropriate when the organization owns and supplies devices but wants to allow limited personal use. It differs from Work Profile (appropriate for employee-owned personal devices) in that the device is corporate-owned and the organization has full device-level management capability. In Android 15, COPE enrollment now includes updated disclosure screens that more clearly communicate the data boundary to end users.
How should IT teams test Android 15 compatibility before fleet rollout?
The recommended Android 15 compatibility testing sequence: (1) Verify EMM platform compatibility — confirm your EMM vendor has published Android 15 support documentation for your platform version; (2) Identify DA API usage — request confirmation from your EMM vendor of which (if any) DA APIs your current DPC uses that are removed in Android 15; (3) Test enrollment modes — enroll test devices in each enrollment mode you use (Work Profile, Fully Managed, COPE, Dedicated Device) on Android 15 and verify that all policy types apply correctly; (4) Validate managed applications — test each managed application on Android 15 in the enrollment mode it will be used in, verifying AppConfig delivery, VPN tunnel behavior, and application update management; (5) Test compliance policy evaluation — verify that device compliance signals (OS version, patch level, enrollment status) are correctly reported to your EMM platform and to any connected conditional access systems; (6) Pilot rollout — deploy Android 15 to a small group of representative users across departments before fleet-wide rollout.
What are Android Enterprise Restricted Networks and how do they work in Android 15?
Android Enterprise Restricted Networks is a feature introduced in Android 13 that allows EMM administrators to configure which network types and specific Wi-Fi networks managed devices can connect to. On fully managed and dedicated devices, EMM administrators can allowlist specific Wi-Fi SSIDs and block connection to unauthorized networks, preventing corporate devices from connecting to untrusted public Wi-Fi without going through a managed VPN. Android 15 expands the restricted networks API to include more detailed blocking capabilities and adds the ability to configure restricted networks policy in Work Profile enrollment (previously limited to fully managed). For BYOD Work Profile devices, the network restriction applies only to Work Profile application traffic — personal application traffic can continue to use any available network, reflecting the BYOD data boundary model where the organization manages work data but not personal device usage.
Does Android 15 change how zero-touch enrollment works for enterprise device provisioning?
Android 15 improves the zero-touch enrollment provisioning UX without changing the underlying zero-touch enrollment mechanism. Zero-touch enrollment still requires devices to be registered with an organization's zero-touch portal through an authorized reseller, and the provisioning DPC and configuration are still assigned in the zero-touch portal and delivered to the device on first boot. What changes in Android 15 is the setup assistant flow — it presents fewer screens to end users during provisioning, reducing setup time and potential user confusion during the provisioning sequence. Additionally, Android 15 improves error handling in the zero-touch provisioning sequence, providing more actionable error messages when provisioning fails due to network, account, or EMM server connectivity issues. Organizations with existing zero-touch enrollment deployments benefit from these improvements without any configuration changes required.
How does Android 15 affect BlackBerry Dynamics applications?
Android 15 changes to the Android Runtime (ART) and application lifecycle management affect all Android applications, including BlackBerry Dynamics SDK-enabled applications. The primary impact for Dynamics apps is cold-start performance — Android 15's ART optimization changes require applications to be recompiled against updated build targets to take full advantage of Android 15's Dex code optimization. Dynamics SDK-enabled applications built against older SDK versions may exhibit longer initial launch times on Android 15 until they are rebuilt. BlackBerry publishes minimum Dynamics SDK versions for Android 15 compatibility — application development teams should rebuild and resubmit Dynamics-enabled custom enterprise applications to the Dynamics application catalog after updating to the Android 15-compatible SDK version. BlackBerry's Dynamics-ready catalog applications (Work Mail, Work Browser, Work Connect, and others) receive BlackBerry-published updates and do not require IT administrator action beyond approving the updated versions through the UEM application management interface.
What is the Android Management API and how does it relate to EMM platform management of Android 15 devices?
The Android Management API (AMAPI) is Google's cloud-based Android Enterprise management API that allows EMM vendors to build Android Enterprise management capabilities without implementing a full Device Policy Controller (DPC) application. EMM platforms that use AMAPI deploy Google's Android Device Policy (ADP) application as the on-device DPC, with the EMM platform handling policy configuration through the cloud API. AMAPI-based platforms receive new Android Enterprise management capabilities faster than DPC-based platforms because Google implements new API features in ADP centrally. EMM platforms with their own DPC (BlackBerry UEM's DPC, Intune's Company Portal, Workspace ONE Intelligent Hub) must release DPC updates to support new Android Enterprise APIs. For Android 15, AMAPI-based platforms have AMAPI schema updates from Google; DPC-based platforms release updated DPC applications. IT administrators should ensure managed devices have updated DPC/Company Portal/Hub applications before applying Android 15 OS updates.
Conclusion
Android 15 is not a breaking release for enterprise EMM deployments, but it contains enough accumulated API deprecations and behavioral changes to require active preparation. The organizations most at risk are those still running Device Admin-based MDM configurations on devices that will receive Android 15 — particularly where the removed DA APIs are embedded in EMM workflows for password reset or camera disable enforcement.
Migrating those configurations to Android Enterprise enrollment modes before Android 15 becomes prevalent in the managed fleet is a concrete, time-bounded action item.
For organizations fully migrated to Android Enterprise enrollment modes, Android 15 delivers useful improvements: more granular Work Profile pause configuration, expanded per-app network restriction capability, improved zero-touch provisioning flow, and cleaner managed configuration control over application update windows. Taking advantage of these improvements requires verifying EMM platform iOS 15 schema support and updating managed configuration policies in the EMM console.
For detailed guidance on parallel iOS enterprise changes, the iOS 18 enterprise features guide covers the Apple-side equivalent changes. Platform security hardening guidance is available in the MDM security section. For BlackBerry UEM-specific configuration guidance, including Android Enterprise policy depth available through UEM, the BES/UEM section covers platform-specific implementation details. The enterprise mobility hub provides broader EMM platform landscape context.