AN1680: Analytic 1680
On Android, the user can use the device settings menu to view trusted CA certificates and look for unexpected or unknown certificates. A mobile security product could similarly examine the trusted CA certificate store for anomalies. Users can use the device settings menu to view which applications on the device are allowed to install unknown applications.
On iOS, the user can use the device settings menu to view installed Configuration Profiles and look for unexpected or unknown profiles. A Mobile Device Management (MDM) system could use the iOS MDM APIs to examine the list of installed Configuration Profiles for anomalies.
Analyst context for executives and security teams
Analytic 1680 is about validating whether a mobile device has unexpected trust or management changes, especially installed iOS Configuration Profiles. For executives and security leaders, the value is not the analytic name itself; it is whether the organization can prove that managed mobile devices have not been silently reconfigured to trust unexpected certificate authorities or profiles that could change device behavior and weaken user protection.
Executive priority
Prioritize this as a mobile security and compliance-readiness validation point for iOS environments using managed devices. Leaders should ask whether MDM inventory can show installed Configuration Profiles, whether anomalies are reviewed, and whether users or support teams have a path to report unknown profiles. This matters for incident triage because unexpected mobile configuration changes may affect trust, monitoring, and access decisions, but the supplied ATT&CK object does not specify a tactic, related technique, actor, or impact.
Technical view
For iOS, validate that MDM can enumerate installed Configuration Profiles through supported iOS MDM APIs and that SOC or mobile administration workflows can identify unexpected or unknown profiles. The official description also mentions Android checks for trusted CA certificates and unknown-application installation permissions, but the supplied platform field is iOS, so iOS should be treated as the supported scope for this object. Because no official detection logic is provided, detection engineering should focus on inventory baselining, change review, and exception handling rather than assuming a ready-made alert rule.
Likely telemetry
- MDM inventory of installed iOS Configuration Profiles
- MDM change history or device state snapshots for profile additions, removals, or modifications
- User or help desk reports of unexpected/unknown profiles visible in device settings
- Mobile security product findings where available for trusted certificate or configuration anomalies
Detection direction
- Confirm that MDM telemetry actually includes the list of installed iOS Configuration Profiles, not only device enrollment status.
- Baseline expected profiles by device group, ownership model, and business role, then review unknown or unexpected profiles as anomalies.
- Tune review workflows to account for legitimate administrative changes, testing profiles, and bring-your-own-device constraints where applicable.
- Treat the Android-related text in the official description as contextual only unless local scope and data sources support Android; the supplied ATT&CK platform for this object is iOS.
- Document gaps where unmanaged devices, incomplete MDM enrollment, or limited API visibility prevent profile inventory review.
Mitigation priorities
- Maintain authoritative MDM configuration baselines for approved iOS profiles.
- Restrict and govern who can deploy or modify mobile configuration profiles.
- Create an investigation path for unexpected profiles found by users, MDM inventory, or mobile security tooling.
- Use change management and audit evidence to show when profiles were approved, deployed, and removed.
- Where devices are not managed, set expectations that profile anomaly detection will depend more heavily on user inspection and support reporting.
Analyst notes and limits
This object is a detection analytic in the mobile ATT&CK domain with external ID AN1680 and an official MITRE URL under DET0619. It has no supplied relationship context, tactics, labels, aliases, or official detection logic. The description references Android and iOS, but the supplied platform field lists iOS only, so the take emphasizes iOS Configuration Profile visibility while noting the Android text as a source limitation.
Coverage cannot be inferred from this object alone. Local MDM enrollment, iOS API access, device ownership model, logging retention, and operational review processes determine whether the analytic is actionable. No active exploitation, attribution, business impact, or guaranteed detection is supported by the supplied fields.
Analytic 1680
On Android, the user can use the device settings menu to view trusted CA certificates and look for unexpected or unknown certificates. A mobile security product could similarly examine the trusted CA certificate store for anomalies. Users can use the device settings menu to view which applications on the device are allowed to install unknown applications.
On iOS, the user can use the device settings menu to view installed Configuration Profiles and look for unexpected or unknown profiles. A Mobile Device Management (MDM) system could use the iOS MDM APIs to examine the list of installed Configuration Profiles for anomalies.
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 | feaf4f446ec9… |
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 AN1680Open 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.