M1001: Security Updates
Install security updates in response to discovered vulnerabilities.
Purchase devices with a vendor and/or mobile carrier commitment to provide security updates in a prompt manner for a set period of time.
Decommission devices that will no longer receive security updates.
Limit or block access to enterprise resources from devices that have not installed recent security updates.
On Android devices, access can be controlled based on each device's security patch level. On iOS devices, access can be controlled based on the iOS version.
Security context for executives and security teams
Security Updates is a mobile ATT&CK mitigation focused on reducing exposure from known vulnerabilities by keeping devices current, buying devices with reliable update commitments, retiring unsupported devices, and restricting enterprise access from devices that are behind on patches. For leaders, the business issue is not just “patch phones”; it is whether mobile devices that access email, identity, VPN, SaaS, and sensitive data are still trustworthy enough to remain connected.
Executive priority
Prioritize this as a mobile resilience and access-control governance issue. The related ATT&CK context ties security updates to reducing risk from mobile exploitation, privilege escalation, persistence, lockscreen bypass, supply chain compromise, defense impairment, credential access, and modified binaries. Executives should ask: which mobile devices can access enterprise resources, which are no longer receiving vendor or carrier updates, what patch or OS version is required for access, and whether procurement standards require prompt security update support for a defined period.
Technical view
SOC, IR, mobile security, and IAM teams should validate that device compliance decisions can use Android security patch level and iOS version, as described by ATT&CK. This mitigation is especially relevant to Android and iOS techniques in the relationship set, including exploitation for initial access, client execution, privilege escalation, persistence via boot/logon initialization scripts, compromise of application or system binaries, defense impairment, and credential access from iOS keychain data. Because ATT&CK provides no detection text for M1001, coverage should be assessed through asset, patch, mobile device management, and access-control evidence rather than alert logic alone.
Likely telemetry
- Mobile device inventory and ownership records
- Android security patch level
- iOS version
- Device model, vendor, carrier, and support/update eligibility
- MDM or mobile compliance status
Detection direction
- Validate whether security teams can distinguish current, outdated, unsupported, rooted, or jailbroken mobile devices before they access enterprise resources.
- Monitor compliance drift: devices that were compliant but have not installed recent updates should become visible to SOC, IAM, or mobile administration workflows.
- Tune reporting to avoid treating patch status alone as proof of compromise; outdated devices indicate exposure and prioritization, not confirmed malicious activity.
- Correlate outdated or unsupported devices with suspicious mobile behaviors when available, especially around exploitation, privilege escalation, defense impairment, credential access, or modified application/system binaries.
- Review blind spots where unmanaged personal devices, carrier-delayed updates, unsupported models, or exception-based access may bypass patch requirements.
Mitigation priorities
- Set minimum mobile OS version and Android security patch level requirements for enterprise access.
- Use procurement standards that favor vendors and mobile carriers with prompt security update commitments for a defined support period.
- Decommission devices that no longer receive security updates.
- Limit or block enterprise resource access from devices that have not installed recent security updates.
- Maintain documented exceptions with business owners, expiration dates, and compensating controls.
Additional notes and limits
This is a preventive control with strong governance value: it turns vulnerability management into an access decision for mobile devices. It also supports compliance evidence by showing patch baselines, device lifecycle rules, and enforcement records. The relationship set indicates broad defensive relevance across mobile exploitation, persistence, defense evasion, credential access, and supply chain-related techniques, but local device inventory and access architecture determine how much risk is actually reduced.
ATT&CK does not provide detection guidance, tactics, or object-level platforms for this mitigation. Android and iOS relevance is supported by the official description and the related mitigated techniques. This take does not assert active exploitation, attribution, or guaranteed detection coverage; organizations must validate coverage against their own MDM, IAM, logging, procurement, and decommissioning data.
Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.
Security Updates
Install security updates in response to discovered vulnerabilities.
Purchase devices with a vendor and/or mobile carrier commitment to provide security updates in a prompt manner for a set period of time.
Decommission devices that will no longer receive security updates.
Limit or block access to enterprise resources from devices that have not installed recent security updates.
On Android devices, access can be controlled based on each device's security patch level. On iOS devices, access can be controlled based on the iOS version.
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 | T1404 | Exploitation for Privilege Escalation | Security updates often contain patches for vulnerabilities. |
| Mobile | T1634 | Credentials from Password Store | Apple regularly provides security updates for known OS vulnerabilities. |
| Mobile | T1630.001 | Uninstall Malicious ApplicationSub-technique | Security updates typically provide patches for vulnerabilities that enable device rooting. |
| Mobile | T1456 | Drive-By Compromise | Security updates frequently contain patches for known exploits. |
| Mobile | T1664 | Exploitation for Initial Access | Security updates frequently contain patches for known software vulnerabilities. |
| Mobile | T1398 | Boot or Logon Initialization Scripts | Security updates frequently contain fixes for vulnerabilities that could be leveraged to modify protected operating system files. |
| Mobile | T1577 | Compromise Application Executable | Security updates frequently contain patches to vulnerabilities. |
| Mobile | T1474 | Supply Chain Compromise | Security updates may contain patches for devices that were compromised at the supply chain level. |
| Mobile | T1634.001 | KeychainSub-technique | Apple regularly provides security updates for known OS vulnerabilities. |
| Mobile | T1474.002 | Compromise Hardware Supply ChainSub-technique | Security updates may contain patches to integrity checking mechanisms that can detect unauthorized hardware modifications. |
| Mobile | T1474.003 | Compromise Software Supply ChainSub-technique | Security updates may contain patches that inhibit system software compromises. |
| Mobile | T1629 | Impair Defenses | Security updates often contain patches for vulnerabilities that could be exploited for root access. Root access is often a requirement to impairing defenses. |
| Mobile | T1630 | Indicator Removal on Host | Security updates typically provide patches for vulnerabilities that could be abused by malicious applications. |
| Mobile | T1645 | Compromise Client Software Binary | Security updates frequently contain fixes for vulnerabilities that could be leveraged to modify protected operating system files. |
| Mobile | T1658 | Exploitation for Client Execution | Security updates frequently contain patches to vulnerabilities. |
| Mobile | T1629.003 | Disable or Modify ToolsSub-technique | Security updates frequently contain patches to vulnerabilities that can be exploited for root access. |
| Mobile | T1461 | Lockscreen Bypass | OS security updates typically contain exploit patches when disclosed. |
| Mobile | T1458 | Replication Through Removable Media | Security updates often contain patches for vulnerabilities. |
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 | e4e0806ea0e1… |
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-attackM1001Open source URL
- [2]mitre-attackM1001Open 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.