M1002: Attestation
Enable remote attestation capabilities when available (such as Android SafetyNet or Samsung Knox TIMA Attestation) and prohibit devices that fail the attestation from accessing enterprise resources.
Analyst context for executives and security teams
Attestation is a mobile access-control safeguard: before a phone or tablet reaches enterprise resources, the organization checks whether the device can prove an expected integrity state. In practice, this matters because many related mobile ATT&CK behaviors depend on rooting, jailbreaking, privilege escalation, hooking, modified system binaries, or hidden artifacts. A failed attestation should be treated as a business access-risk signal, not just a device-health warning.
Executive priority
Prioritize attestation where mobile devices access sensitive applications, credentials, VPNs, or regulated data. Leaders should ask whether access policies actually block or restrict devices that fail attestation, whether exceptions are governed, and whether mobile integrity evidence can support incident response and compliance reviews. The value is highest when attestation is tied to conditional access and incident playbooks rather than used only as a passive mobile-device-management status field.
Technical view
MITRE defines this mitigation as enabling remote attestation when available, such as Android SafetyNet or Samsung Knox TIMA Attestation, and prohibiting failed devices from accessing enterprise resources. Relationship context shows relevance to Android and iOS mobile techniques involving boot or logon initialization scripts, privilege escalation, process discovery, hooking, command and scripting interpreters, execution-flow hijacking, indicator removal, credential access from password stores/keychain, and compromised client software binaries. SOC, IAM, cloud, and mobile security teams should validate that attestation results are generated, centrally visible, correlated with access decisions, and preserved for investigation. ATT&CK provides no detection text for this mitigation, so local control and telemetry validation are required.
Likely telemetry
- Mobile device attestation result, timestamp, device identifier, and integrity verdict
- Mobile device management or enterprise mobility management compliance status
- Conditional access allow, block, quarantine, or step-up decision logs
- Identity provider authentication and resource access logs for mobile sessions
- Device enrollment, ownership, and exception records
Detection direction
- Confirm that failed, missing, stale, or downgraded attestation results are visible to monitoring teams and not only to device administrators.
- Correlate attestation failures with mobile access attempts to sensitive applications, VPNs, cloud services, and credential stores.
- Tune alerting for policy bypass patterns such as repeated failures followed by successful access through an exception, alternate enrollment path, or unmanaged device flow.
- Review false positives caused by unsupported device models, OS version changes, enrollment issues, or attestation service availability before enforcing broad blocking.
- Use the related techniques as validation scenarios: rooted or jailbroken states, modified binaries, hooking frameworks, shell access, and indicator-hiding behaviors should not be able to silently retain enterprise access if attestation fails.
Mitigation priorities
- Enable supported remote attestation capabilities for managed mobile devices.
- Bind attestation verdicts to conditional access so devices that fail attestation are prohibited or restricted from enterprise resources.
- Define an exception process with approval, expiration, and compensating controls for business-critical access.
- Preserve attestation and access-decision logs for SOC triage, incident response, and compliance evidence.
- Periodically test enforcement against representative Android and iOS access paths identified in the related ATT&CK techniques.
Analyst notes and limits
This is a mitigation object, not a detection analytic. Its defensive value is strongest when integrated across mobile device management, identity access control, SOC monitoring, and incident response workflows. The relationship set indicates that attestation helps reduce exposure to multiple mobile behaviors that often rely on elevated privileges, altered operating-system behavior, or compromised device integrity.
The supplied ATT&CK object does not specify platforms directly, tactics, or detection guidance. Android and iOS references come from the related mitigated techniques, and Android-specific attestation examples come from the official description. Local device fleet composition, enrollment model, identity architecture, and exception handling determine actual coverage.
Attestation
Enable remote attestation capabilities when available (such as Android SafetyNet or Samsung Knox TIMA Attestation) and prohibit devices that fail the attestation from accessing enterprise resources.
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 | Device attestation can often detect jailbroken or rooted devices. |
| Mobile | T1634 | Credentials from Password Store | Device attestation can often detect jailbroken devices. |
| Mobile | T1617 | Hooking | Device attestation can often detect rooted devices. |
| Mobile | T1623.001 | Unix Shell Sub-technique | Device attestation can often detect jailbroken or rooted devices. |
| Mobile | T1634.001 | Keychain Sub-technique | Device attestation can often detect jailbroken devices. |
| Mobile | T1398 | Boot or Logon Initialization Scripts | Device attestation could detect devices with unauthorized or unsafe modifications. |
| Mobile | T1623 | Command and Scripting Interpreter | Device attestation can often detect jailbroken or rooted devices. |
| Mobile | T1424 | Process Discovery | Attestation can typically detect rooted devices. For MDM-enrolled devices, action can be taken if a device fails an attestation check. |
| Mobile | T1625 | Hijack Execution Flow | Device attestation could detect unauthorized operating system modifications. |
| Mobile | T1645 | Compromise Client Software Binary | Device attestation could detect devices with unauthorized or unsafe modifications. |
| Mobile | T1625.001 | System Runtime API Hijacking Sub-technique | Device attestation could detect unauthorized operating system modifications. |
| Mobile | T1630 | Indicator Removal on Host | Attestation can detect unauthorized modifications to devices. Mobile security software can then use this information and take appropriate mitigation action. |
| Mobile | T1630.001 | Uninstall Malicious Application Sub-technique | Attestation can detect rooted devices. Mobile security software can then use this information and take appropriate mitigation action. Attestation can detect rooted devices. |
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 | 42acf19ca7c4… |
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 M1002Open 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.