T1632: Subvert Trust Controls
Adversaries may undermine security controls that will either warn users of untrusted activity or prevent execution of untrusted applications. Operating systems and security products may contain mechanisms to identify programs or websites as possessing some level of trust. Examples of such features include: an app being allowed to run because it is signed by a valid code signing certificate; an OS prompt alerting the user that an app came from an untrusted source; or getting an indication that you are about to connect to an untrusted site. The method adversaries use will depend on the specific mechanism they seek to subvert.
Analyst context for executives and security teams
Subvert Trust Controls matters because mobile security often depends on users and operating systems being warned before untrusted apps, code, or sites are allowed. If those trust gates are weakened or bypassed on Android or iOS, organizations may lose an important layer of prevention and user decision support. For leaders, the practical question is whether mobile devices are managed, current, and configured so trust prompts, code-signing protections, and unsafe-site warnings remain effective.
Executive priority
Treat this as a mobile resilience and governance issue, not just a malware behavior. Priority should go to confirming that enterprise mobile policy, OS update posture, and user guidance are sufficient to preserve platform trust controls. This supports incident readiness, audit evidence for managed-device controls, and risk decisions around bring-your-own-device or lightly managed mobile access to business systems.
Technical view
SOC, detection engineering, and IR teams should validate Android and iOS visibility around attempts to weaken or bypass trust-related controls. ATT&CK provides no official detection text for T1632, but it does identify a related detection strategy, DET0657, and a relevant sub-technique, T1632.001 Code Signing Policy Modification. Teams should therefore test whether they can observe mobile policy changes, code-signing or app trust exceptions, installation of apps from untrusted sources where applicable, unsafe-site or certificate trust warnings, and deviations from expected EMM/MDM configuration baselines.
Likely telemetry
- EMM/MDM device compliance status, policy configuration, and policy change history
- Android and iOS OS version and security update inventory
- Mobile app installation records and app trust/signing status where available
- Device configuration state related to enterprise policy enforcement and allowed behaviors
- User reports or helpdesk records involving untrusted app, untrusted site, or trust-warning prompts
Detection direction
- Confirm what DET0657-style coverage means in the local environment, since the ATT&CK object does not provide official detection logic.
- Baseline expected mobile trust-control settings and alert on unauthorized changes or noncompliant device states.
- Use T1632.001 as a concrete validation case: determine whether code-signing policy modification or equivalent trust exceptions would be visible on managed Android and iOS devices.
- Tune detections to distinguish approved administrative policy changes from unexpected device-level trust-control changes.
- Account for blind spots on unmanaged, personally owned, offline, or privacy-restricted mobile devices where EMM/MDM and endpoint telemetry may be limited.
Mitigation priorities
- Prioritize M1006 Use Recent OS Version: maintain current Android and iOS versions because newer releases include patches and security architecture improvements.
- Apply M1012 Enterprise Policy through EMM/MDM to enforce allowed mobile behaviors and maintain compliance evidence.
- Use M1011 User Guidance so users understand trust prompts and avoid risky configuration changes or untrusted app/site interactions.
- Review mobile access policies for devices that cannot meet OS currency or enterprise policy requirements.
Analyst notes and limits
This technique is broad: it covers undermining controls that warn users about untrusted activity or prevent execution of untrusted applications. The supplied relationship to T1632.001 narrows one important area to code-signing policy modification, but the parent technique can also involve other trust mechanisms. Practical assessment should be based on the organization’s actual Android/iOS management model and mobile telemetry.
ATT&CK does not specify tactics for this object and provides no official detection text. The supplied fields do not support claims about active exploitation, specific adversaries, business impact, or guaranteed detection coverage. Local device management, logging, and mobile security architecture determine real visibility and control effectiveness.
Subvert Trust Controls
Adversaries may undermine security controls that will either warn users of untrusted activity or prevent execution of untrusted applications. Operating systems and security products may contain mechanisms to identify programs or websites as possessing some level of trust. Examples of such features include: an app being allowed to run because it is signed by a valid code signing certificate; an OS prompt alerting the user that an app came from an untrusted source; or getting an indication that you are about to connect to an untrusted site. The method adversaries use will depend on the specific mechanism they seek to subvert.
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.
Related techniques
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 | T1632.001 | Code Signing Policy Modification Sub-technique | Code Signing Policy Modification subtechnique of this object. |
All related ATT&CK context
Mitigation direction
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.1 | Current bundle | 6c15576339e3… |
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]
NIST Mobile Threat Catalogue STA-7Open source URL
-
[2]
mitre-attack T1632Open 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.