M1003: Lock Bootloader
On devices that provide the capability to unlock the bootloader (hence allowing any operating system code to be flashed onto the device), perform periodic checks to ensure that the bootloader is locked.
Analyst context for executives and security teams
Lock Bootloader is a mobile mitigation focused on proving that devices capable of bootloader unlocking remain locked. For leaders, the value is not the setting itself; it is assurance that the mobile fleet cannot easily be reflashed with unauthorized operating system code that could enable persistence, modified system binaries, or USB-connected compromise paths.
Executive priority
Treat this as a mobile device integrity control and audit evidence issue. Security leaders should ask whether managed mobile devices that support bootloader unlocking are periodically checked, whether exceptions are documented, and whether incident response can quickly identify devices whose trust baseline has changed. This is especially relevant to resilience and compliance where mobile devices access business data or connect physically to PCs, chargers, or other USB infrastructure.
Technical view
ATT&CK provides no official detection text for M1003, so SOC and mobile security teams should validate control state rather than assume coverage. Confirm whether device management or compliance tooling can report bootloader lock status for applicable devices and whether that status is reviewed over time. Use the relationship context to prioritize validation around behaviors mitigated by this control: boot/logon initialization script persistence that may require rooting or jailbreaking, compromise of system software binaries, and movement or installation paths involving USB-connected devices.
Likely telemetry
- Mobile device inventory and compliance records showing bootloader lock status where available
- Periodic device posture check results from mobile management or security tooling
- Root or jailbreak indication records, when collected
- USB connection or direct-install evidence relevant to mobile devices, where available
- System software or binary integrity findings, where available
Detection direction
- Because official ATT&CK detection guidance is not provided, first validate whether the organization can observe bootloader lock status at all on applicable devices.
- Tune monitoring around changes from locked to unlocked state, missing posture checks, or devices that fall out of compliance; investigate with awareness that legitimate service, testing, or administrative workflows may create exceptions.
- Correlate bootloader status with related mobile behaviors: suspected root or jailbreak conditions, boot initialization persistence, modified system binaries, and suspicious USB-connected activity.
- Identify blind spots for unmanaged devices, devices that do not expose bootloader state to enterprise tooling, and environments where posture checks are not retained as evidence.
Mitigation priorities
- Define which mobile devices are in scope for bootloader lock verification, limited to devices that provide the capability to unlock the bootloader.
- Perform periodic checks to ensure the bootloader remains locked, as specified by ATT&CK.
- Require documented exceptions and compensating review for any device that cannot be verified or must operate outside the expected locked state.
- Use noncompliance as a trigger for containment, re-enrollment, or incident response review based on local mobile device policy.
- Retain posture evidence to support audit, compliance readiness, and post-incident reconstruction.
Analyst notes and limits
This mitigation is tied in ATT&CK to mobile techniques T1398, T1458, and T1645, covering persistence through boot/logon initialization scripts, replication or access paths through removable/USB-connected media, and compromise of client software binaries. The decision value is strongest when bootloader state is treated as part of device trust, not as a one-time enrollment checkbox.
The supplied ATT&CK object has no platforms, tactics, aliases, labels, or official detection text for M1003. Android and iOS appear only in the related technique context, not as the mitigation platform field. Local device models, management capabilities, policy exceptions, and telemetry retention must be validated before making coverage claims.
Lock Bootloader
On devices that provide the capability to unlock the bootloader (hence allowing any operating system code to be flashed onto the device), perform periodic checks to ensure that the bootloader is locked.
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 | T1645 | Compromise Client Software Binary | A locked bootloader could prevent unauthorized modifications of protected operating system files. |
| Mobile | T1458 | Replication Through Removable Media | Users should ensure bootloaders are locked to prevent arbitrary operating system code from being flashed onto the device. |
| Mobile | T1398 | Boot or Logon Initialization Scripts | A locked bootloader could prevent unauthorized modifications to protected operating system files. |
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 | 75dc9bf28b01… |
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 M1003Open 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.