M1012: Enterprise Policy
An enterprise mobility management (EMM), also known as mobile device management (MDM), system can be used to provision policies to mobile devices to control aspects of their allowed behavior.
Security context for executives and security teams
Enterprise Policy (M1012) is about using EMM/MDM to enforce mobile device rules instead of relying only on user judgment. Its business value is reducing mobile paths to credential theft, location exposure, screen/input capture, unauthorized app behavior, remote access tooling, and physical-device risks such as lockscreen bypass or USB-based compromise.
Executive priority
Treat this as a mobile governance and resilience control. Leaders should ask whether managed mobile devices are actually enrolled, compliant, and governed by enforceable policy for Android and iOS risks reflected in the related ATT&CK techniques. The priority is strongest where mobile devices access enterprise accounts, VPN/internal resources, sensitive notifications, or regulated data, because weak policy enforcement can undermine identity assurance, incident containment, audit evidence, and remote-work security.
Technical view
MITRE does not provide detection guidance for this mitigation, so teams should validate implementation evidence rather than assume coverage. SOC, IR, and mobile administrators should confirm that EMM/MDM policies are deployed, monitored, and auditable for behaviors related to input capture, keylogging, GUI prompt abuse, location tracking, remote device management abuse, SIM swap exposure, removable media/USB risks, lockscreen bypass, screen capture, accessibility/input injection abuse, notification access, defense impairment, code-signing/trust-control changes, application updates, and remote access software. Relationship context identifies Android and iOS across many mitigated techniques, with several Android-specific areas such as screen capture, input injection, notification access, and defense impairment.
Likely telemetry
- EMM/MDM enrollment and device compliance status
- Mobile policy configuration and deployment history
- EMM/MDM administrator and console audit logs
- Device inventory, ownership, OS version, and managed/unmanaged status
- Mobile application inventory and application update history
Detection direction
- Validate that detections and dashboards distinguish enrolled, compliant, non-compliant, and unmanaged devices; unmanaged devices are a major blind spot for this mitigation.
- Review EMM/MDM audit logs for unauthorized or unusual administrator activity, because related technique T1430.001 includes abuse of remote device management services for location tracking.
- Tune monitoring around high-risk mobile permissions and features referenced by related techniques, including third-party keyboards, accessibility APIs, notification access, location access, device administration, and remote access applications.
- Correlate mobile compliance state with identity, VPN, and internal resource access so a device that falls out of policy does not continue to receive the same trust.
- Expect false positives from legitimate accessibility tools, remote support tools, location services, and enterprise administration actions; require business justification and documented approvals rather than blanket blocking assumptions.
Mitigation priorities
- Establish a baseline EMM/MDM policy for enterprise mobile devices and require enrollment for devices accessing enterprise resources.
- Prioritize controls that reduce credential and data exposure: lockscreen requirements, managed app controls, permission governance, notification/data leakage restrictions, and limits on unauthorized keyboards or accessibility abuse where supported.
- Tie mobile access to compliance status for enterprise services such as VPN, email, and internal applications.
- Restrict or review remote access software, unmanaged app installation, trust-control changes, and application update risk using available EMM/MDM policy features.
- Protect the EMM/MDM console itself with strong administrative controls and audit review, since compromise or misuse of management services can affect location and device control.
Additional notes and limits
The object is a mobile ATT&CK mitigation, not a technique. Its supplied description is broad: an EMM/MDM system can provision policies to control allowed mobile device behavior. The practical value comes from the relationship set, which shows this mitigation applies across many Android and iOS mobile risks, including credential capture, device tracking, remote access, trust subversion, and defense impairment.
No official detection text, tactics, or platforms are specified on the mitigation object itself. Platform references come from related techniques only. Actual control strength depends on the organization’s EMM/MDM product capabilities, enrollment coverage, mobile OS versions, policy configuration, logging, and exception handling.
Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.
Enterprise Policy
An enterprise mobility management (EMM), also known as mobile device management (MDM), system can be used to provision policies to mobile devices to control aspects of their allowed behavior.
How security teams should use this page
Treat this object as behavior context, not an attribution claim. Validate the related groups, software, data sources, and mitigations against official ATT&CK relationships and your own telemetry before making control-coverage decisions.
Techniques used
This mirrors the MITRE pattern of making group, software, campaign, and technique relationships scannable. Relationship notes come from mirrored ATT&CK relationship text when available.
| Domain | ID | Name | Relationship / procedure |
|---|---|---|---|
| Mobile | T1417 | Input Capture | When using Samsung Knox, third-party keyboards must be explicitly added to an allow list in order to be available to the end-user.[1] An EMM/MDM can use the Android `DevicePolicyManager.setPermittedAccessibilityServices` method to set an explicit list of applications that are allowed to use Android's accessibility features. |
| Mobile | T1428 | Exploitation of Remote Services | Configuration of per-app VPN policies instead of device-wide VPN can restrict access to internal enterprise resource access via VPN to only enterprise-approved applications |
| Mobile | T1632.001 | Code Signing Policy ModificationSub-technique | On iOS, the `allowEnterpriseAppTrust` and `allowEnterpriseAppTrustModification` configuration profile restrictions can be used to prevent users from installing apps signed using enterprise distribution keys. |
| Mobile | T1513 | Screen Capture | Enterprise policies should block access to the Android Debug Bridge (ADB) by preventing users from enabling USB debugging on Android devices unless specifically needed (e.g., if the device is used for application development). An EMM/MDM can use the Android `DevicePolicyManager.setPermittedAccessibilityServices` method to set an explicit list of applications that are allowed to use Android's accessibility features. |
| Mobile | T1417.001 | KeyloggingSub-technique | When using Samsung Knox, third-party keyboards must be explicitly added to an allow list in order to be available to the end-user.[1] |
| Mobile | T1516 | Input Injection | An EMM/MDM can use the Android `DevicePolicyManager.setPermittedAccessibilityServices` method to set an explicit list of applications that are allowed to use Android's accessibility features. |
| Mobile | T1430.001 | Remote Device Management ServicesSub-technique | If devices are enrolled using Apple User Enrollment or using a profile owner enrollment mode for Android, device controls prevent the enterprise from accessing the device’s physical location. This is typically used for a Bring Your Own Device (BYOD) deployment. |
| Mobile | T1451 | SIM Card Swap | Enterprises should monitor for SIM card changes on the Enterprise Mobility Management (EMM) or the Mobile Device Management (MDM). |
| Mobile | T1661 | Application Versioning | Enterprises can provision policies to mobile devices for application allow-listing, ensuring only approved applications are installed onto mobile devices. |
| Mobile | T1430 | Location Tracking | If devices are enrolled using Apple User Enrollment or using a profile owner enrollment mode for Android, device controls prevent the enterprise from accessing the device’s physical location. This is typically used for a Bring Your Own Device (BYOD) deployment. |
| Mobile | T1461 | Lockscreen Bypass | Enterprises can provision policies to mobile devices that require a minimum complexity (length, character requirements, etc.) for the device passcode, and cause the device to wipe all data if an incorrect passcode is entered too many times. Both policies would mitigate brute-force, guessing, or shoulder surfing of the device passcode. Enterprises can also provision policies to disable biometric authentication, however, biometric authentication can help make using a longer, more complex passcode more practical because it does not need to be entered as frequently. |
| Mobile | T1521.003 | SSL PinningSub-technique | Certain enterprise policies can be applied to prevent users from adding certificates to the device and to prevent applications from being able to install their own certificates. |
| Mobile | T1632 | Subvert Trust Controls | On iOS, the `allowEnterpriseAppTrust` and `allowEnterpriseAppTrustModification` configuration profile restrictions can be used to prevent users from installing apps signed using enterprise distribution keys. |
| Mobile | T1663 | Remote Access Software | When devices are enrolled in an EMM/MDM using device owner (iOS) or fully managed (Android) mode, the EMM/MDM can collect a list of installed applications on the device. An administrator can then act on, for example blocking, specific remote access applications from being installed on managed devices. |
| Mobile | T1458 | Replication Through Removable Media | Enterprise policies should prevent enabling USB debugging on Android devices unless specifically needed (e.g., if the device is used for application development). |
| Mobile | T1629 | Impair Defenses | An EMM/MDM can use the Android `DevicePolicyManager.setPermittedAccessibilityServices` method to set an explicit list of applications that are allowed to use Android's accessibility features. |
| Mobile | T1417.002 | GUI Input CaptureSub-technique | An EMM/MDM can use the Android `DevicePolicyManager.setPermittedAccessibilityServices` method to set an explicit list of applications that are allowed to use Android's accessibility features. |
| Mobile | T1517 | Access Notifications | On Android devices with a work profile, the `DevicePolicyManager.setPermittedCrossProfileNotificationListeners` method can be used to manage the list of applications running within the personal profile that can access notifications generated within the work profile. This policy would not affect notifications generated by the rest of the device. The `DevicePolicyManager.setApplicationHidden` method can be used to disable notification access for unwanted applications, but this method would also block that entire application from running.[2] |
| Mobile | T1629.001 | Prevent Application RemovalSub-technique | An EMM/MDM can use the Android `DevicePolicyManager.setPermittedAccessibilityServices` method to set an explicit list of applications that are allowed to use Android's accessibility features. |
All related ATT&CK context
Object version and sync metadata
The fields below describe the current mirrored snapshot. When Glexia retains multiple ATT&CK source imports, you can open the table to compare the same object across releases (hashes and MITRE timestamps). For MITRE’s own release notes and roadmap, see ATT&CK resources — Updates.
Imported snapshots across ATT&CK releases(1)
| Release | Bundle imported | Object version | Modified | Status | Raw hash |
|---|---|---|---|---|---|
| 19.1 | 1.0 | Current bundle | 5b24834a2b2f… |
Mirrored ATT&CK source object
The raw object is retained through the mirrored ATT&CK source bundle and object hash. The raw endpoint returns the exact object from the mirrored bundle when available.
External references and citations
MITRE external references are preserved separately from Glexia analysis so citations remain traceable to their original source records.
- [1]Samsung Keyboards
Samsung. (2019, August 16). 3rd party keyboards must be whitelisted.. Retrieved November 17, 2024.
Open source URL - [2]Android Notification Listeners
Android. (n.d.). DevicePolicyManager. Retrieved September 15, 2019.
Open source URL - [3]mitre-attackM1012Open source URL
- [4]mitre-attackM1012Open source URL
- [5]Samsung Keyboards
Samsung. (2019, August 16). 3rd party keyboards must be whitelisted.. Retrieved November 17, 2024.
Open source URL
Source: MITRE ATT&CK®. © 2026 The MITRE Corporation. This work is reproduced and distributed with the permission of The MITRE Corporation. MITRE ATT&CK and ATT&CK are registered trademarks of The MITRE Corporation. Glexia is not affiliated with or endorsed by MITRE.