AN1836: Analytic 1836
Mobile security products can use attestation to detect compromised devices.
Analyst context for executives and security teams
AN1836 is a mobile detection analytic for iOS: use device attestation from mobile security products to identify devices that may be compromised. The business value is not the analytic name itself, but whether the organization can prove that mobile devices used for sensitive work are still trustworthy enough for access and incident decisions.
Executive priority
For leaders, this is a control-evidence question: are managed iOS devices that access business systems subject to integrity attestation, and are failed or inconclusive attestations acted on? This matters for mobile access risk, compliance evidence, incident triage, and continuity of operations when mobile devices are part of executive, workforce, or field workflows.
Technical view
SOC, mobile security, and IR teams should validate that iOS attestation results are generated, retained, and reviewable by the teams responsible for mobile compromise response. Because the ATT&CK object provides no official detection logic and no tactic mapping, teams should treat this as a detection capability requirement rather than a ready-to-deploy rule. Confirm what the mobile security product reports, how failures are classified, and how those events are escalated.
Likely telemetry
- iOS device attestation pass, fail, and inconclusive results from mobile security products
- Device identity, enrollment, ownership, and user association records for attested iOS devices
- Timestamps and device context associated with attestation events
- Security console alerts or case records generated from attestation failures
- Response actions or analyst notes linked to suspected compromised-device findings
Detection direction
- Verify that attestation is actually enabled for relevant iOS device populations, not merely licensed or documented.
- Confirm that failed and inconclusive attestation outcomes reach SOC or mobile security workflows with enough device and user context for triage.
- Establish local handling for false positives or ambiguous results, since the official object does not provide detection criteria.
- Do not generalize this analytic to non-iOS platforms unless separate local evidence supports that coverage.
- Measure coverage gaps: unmanaged devices, devices not enrolled in mobile security tooling, missing logs, and events that remain only in an admin console.
Mitigation priorities
- Start with inventory: identify which business-critical iOS devices should be subject to attestation.
- Ensure mobile security tooling records and retains attestation outcomes for investigation and audit evidence.
- Define an incident response path for failed attestation results, including ownership, triage, and containment decision points.
- Use attestation status as one input to mobile access-risk decisions, while avoiding reliance on it as the only proof of compromise.
- Review gaps periodically because the ATT&CK object supplies no detailed detection implementation or relationship context.
Analyst notes and limits
This object is a detection analytic in the ATT&CK mobile domain for iOS. The only official behavioral statement is that mobile security products can use attestation to detect compromised devices. No relationships, tactics, aliases, labels, or official detection logic were supplied, so the strongest use is as a validation prompt for mobile detection coverage and response readiness.
The source is sparse. It does not specify analytic logic, event fields, thresholds, tactics, adversary use, mitigations, or supported products. Local mobile security architecture, device management scope, log retention, and response procedures are required to determine real coverage.
Analytic 1836
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 | 637e907612f2… |
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 AN1836Open 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.