AN1835: Analytic 1835
Mobile security products can use attestation to detect compromised devices.
Analyst context for executives and security teams
This analytic highlights a defensive use of mobile device attestation on Android: helping mobile security products identify devices that may be compromised. For leaders, the practical value is not the analytic name itself, but whether the organization can trust the health state of Android devices before allowing access to corporate apps, data, or workflows.
Executive priority
Prioritize this where Android devices are used for business access, privileged operations, regulated data handling, or operational workflows. The key decision is whether device trust is being measured and evidenced, not assumed. Security leaders should ask whether attestation results are available to SOC, identity/access, and incident response processes, and whether access decisions can account for a compromised-device signal.
Technical view
ATT&CK provides a narrow analytic statement: mobile security products can use attestation to detect compromised Android devices. SOC and detection teams should validate whether Android attestation outcomes are generated, retained, and correlated with mobile security alerts, device posture records, and access events. Because no official detection logic or relationship context is supplied, teams should avoid treating this as a complete detection rule and instead use it as a coverage validation prompt for Android device integrity monitoring.
Likely telemetry
- Android device attestation results or verdicts
- Mobile security product alerts related to device compromise or integrity
- Device posture/compliance records from mobile management or endpoint security tooling
- Identity and access logs showing authentication or access attempts from Android devices
- Incident response case evidence tying device health state to user, device, and application access
Detection direction
- Confirm that Android attestation is enabled where supported and that results are visible to security operations or access-control workflows.
- Validate alert handling for compromised-device or failed-attestation signals, including ownership, triage steps, and escalation paths.
- Tune for operational context: failed or unavailable attestation may reflect enrollment, compatibility, network, or device-management issues and should be separated from confirmed compromise where possible.
- Check blind spots such as unmanaged Android devices, personal devices outside mobile security coverage, or environments where attestation results are collected but not correlated with identity/access activity.
- Because no ATT&CK detection logic is provided, document local rule logic, thresholds, and evidence sources as organization-specific implementation details.
Mitigation priorities
- Establish policy for which Android devices must provide trusted posture or attestation evidence before accessing business resources.
- Integrate mobile device health signals with identity and access management decisions where appropriate.
- Ensure SOC and incident response teams can retrieve attestation history during investigations involving Android access.
- Maintain exception handling for unsupported, unmanaged, or bring-your-own-device scenarios so business access risk is explicit.
- Use the analytic as compliance evidence only when local logs, procedures, and control enforcement can demonstrate that attestation is actually collected and acted upon.
Analyst notes and limits
This object is a detection analytic in the mobile ATT&CK domain for Android. The official description is limited to the use of attestation by mobile security products to detect compromised devices. No tactics, detection pseudocode, data components, or relationships were supplied, so the main value is as a control and telemetry validation point rather than a ready-to-deploy detection.
The supplied ATT&CK fields do not specify tactics, related techniques, detection logic, severity, adversary usage, or implementation requirements. Any assessment of coverage, impact, or exploitation must come from local Android fleet, mobile security, identity, and access telemetry.
Analytic 1835
Mobile security products can use attestation to detect compromised devices.
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.
All related ATT&CK context
No relationships are available in the current normalized data for this object.
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 | eead08e53452… |
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 AN1835Open 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.