M1004: System Partition Integrity
Ensure that Android devices being used include and enable the Verified Boot capability, which cryptographically ensures the integrity of the system partition.
Analyst context for executives and security teams
System Partition Integrity is a mobile mitigation focused on ensuring Android devices include and enable Verified Boot so the system partition is cryptographically checked. Its business value is reducing the chance that modified system components, persistence mechanisms, or defense-disabling changes survive on managed mobile devices without being noticed by the platform integrity model.
Executive priority
Treat this as a mobile device trust-control requirement, especially for Android devices used for business access. The ATT&CK relationships show it is relevant to persistence at boot/logon, execution-flow hijacking, defense impairment, and modified system software binaries. Leaders should ask whether Android device procurement, enrollment, and compliance processes can prove Verified Boot is present and enabled before devices are allowed to access sensitive business applications.
Technical view
ATT&CK provides no official detection text for M1004, so SOC and mobile security teams should validate control state rather than rely on behavior-only detection. Confirm whether Android devices report Verified Boot capability and enabled status, and whether integrity failures or rooted-device conditions are visible to mobile management, SOC, or incident response workflows. Use the related techniques as validation scenarios: unauthorized boot/logon initialization changes, modified system binaries, runtime API hijacking, and attempts to disable or modify security tools should be harder to persist when the system partition integrity check is enforced.
Likely telemetry
- Android device inventory and enrollment records showing whether Verified Boot is supported and enabled
- Mobile device compliance or posture records related to system integrity
- Rooted-device or protected-system-file modification indicators where available
- Alerts or status changes indicating boot or system partition integrity failure
- Incident response evidence from affected devices, including whether system binaries or security tools were modified
Detection direction
- Because ATT&CK lists no official detection, first validate whether the organization can observe Verified Boot state at all.
- Tune compliance checks to distinguish unmanaged or exception devices from managed Android devices expected to enforce system partition integrity.
- Use relationship context to hunt for gaps: persistence through boot/logon initialization scripts, modified client software binaries, runtime API hijacking, and disabled or modified tools.
- Do not assume this mitigation covers iOS simply because some related techniques include iOS; the official mitigation description specifically names Android Verified Boot.
Mitigation priorities
- Require Android devices used for business to include and enable Verified Boot where applicable.
- Make Verified Boot status part of device acceptance, enrollment, and ongoing compliance decisions.
- Prioritize enforcement for devices with access to sensitive applications, privileged workflows, or regulated data.
- Define incident response handling for devices that fail integrity checks or show evidence of rooted access or protected system modification.
- Maintain documented exceptions so audit and risk owners can distinguish approved deviations from unmanaged exposure.
Analyst notes and limits
This mitigation is preventive and assurance-oriented. Its value is strongest when paired with inventory, mobile posture assessment, and response processes that can act on integrity failures. The related ATT&CK techniques indicate why system partition integrity matters: several mobile behaviors depend on modifying operating-system components, persistence paths, security tools, or binaries.
The source object does not specify tactics, platforms as a structured field, or official detection guidance. The Android scope comes from the official description. Local device management capabilities, telemetry availability, and enforcement options must be verified in the customer environment.
System Partition Integrity
Ensure that Android devices being used include and enable the Verified Boot capability, which cryptographically ensures the integrity of the system partition.
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 | T1629.003 | Disable or Modify Tools Sub-technique | System partition integrity mechanisms, such as Verified Boot, can detect the unauthorized modification of system files. |
| Mobile | T1645 | Compromise Client Software Binary | Android includes system partition integrity mechanisms that could detect unauthorized modifications. |
| Mobile | T1474.003 | Compromise Software Supply Chain Sub-technique | Ensure Verified Boot is enabled on devices with that capability. |
| Mobile | T1625 | Hijack Execution Flow | Android Verified Boot can detect unauthorized modifications made to the system partition, which could lead to execution flow hijacking.CitationAndroid-VerifiedBoot |
| Mobile | T1398 | Boot or Logon Initialization Scripts | Android and iOS include system partition integrity mechanisms that could detect unauthorized modifications. |
| Mobile | T1629 | Impair Defenses | System partition integrity mechanisms, such as Verified Boot, can detect the unauthorized modification of system files. |
| Mobile | T1625.001 | System Runtime API Hijacking Sub-technique | Android Verified Boot can detect unauthorized modifications made to the system partition, which could lead to execution flow hijacking.CitationAndroid-VerifiedBoot |
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 | d7db5e819130… |
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]
mitre-attack M1004Open 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.