Live Active security incident? Get immediate response
MITRE ATT&CK® Detection Strategy

DET0619: Detection of Code Signing Policy Modification

This detection strategy is relevant because it points defenders toward attempts to weaken mobile code-signing trust. If code-signing policy is modified, an...

MobileDET0619Detection StrategyObject v1.0 Modified
Glexia's Take

Analyst context for executives and security teams

Analyst confidence Medium

This detection strategy is relevant because it points defenders toward attempts to weaken mobile code-signing trust. If code-signing policy is modified, an organization may lose confidence that only approved, authentic mobile applications can run on affected Android or iOS devices. For leaders, the practical issue is not just malware detection; it is whether mobile device trust controls, audit evidence, and incident response processes can prove that app execution policy has not been altered.

Executive priority

Prioritize this as a mobile security and assurance control gap. Executives should ask whether the organization can validate code-signing enforcement on managed mobile devices, detect policy drift, and preserve evidence during mobile incidents. This matters for business continuity where mobile devices support operations, identity access, executive communications, or regulated workflows. Because the ATT&CK object provides no official detection logic, coverage should be treated as a validation requirement rather than an assumed SOC capability.

Technical view

DET0619 is a detection strategy for T1632.001, Code Signing Policy Modification, in the mobile ATT&CK domain. The related technique concerns adversaries modifying code-signing policies to allow applications signed with unofficial or unknown keys. SOC, mobile security, and IR teams should validate whether Android and iOS device management, endpoint/mobile telemetry, and configuration compliance data can show changes to code-signing enforcement or related security policy state. Detection engineering should focus on evidence of policy modification, unexpected trust changes, and deviations from expected managed-device baselines, while avoiding assumptions because MITRE provides no official detection text for this object.

Likely telemetry

  • Mobile device management configuration and compliance records
  • Android and iOS security policy state or configuration inventory where available
  • Device posture and jailbreak/root or tamper indicators where collected
  • Application installation and signing/trust metadata where available
  • Administrative change logs for mobile security policies

Detection direction

  • Confirm whether mobile policy telemetry can identify changes that weaken code-signing enforcement or allow unofficial/unknown signing keys.
  • Baseline expected code-signing and app trust policy for managed Android and iOS devices, then alert on drift from that baseline.
  • Correlate policy changes with administrative activity to distinguish authorized configuration changes from suspicious modification.
  • Validate whether unmanaged, personally owned, offline, jailbroken, rooted, or otherwise tampered devices create visibility gaps.
  • Because ATT&CK provides no official detection analytic, test detection assumptions against local MDM, mobile endpoint, and IR evidence rather than relying on the DET0619 name alone.

Mitigation priorities

  • Define and document expected mobile code-signing and application trust policy for managed devices.
  • Use mobile management and compliance processes to enforce approved app execution and detect policy drift where supported.
  • Restrict and monitor administrative ability to change mobile security policies.
  • Ensure incident response playbooks include collection of mobile policy state, app trust/signing evidence, and relevant admin change history.
  • Periodically audit Android and iOS device posture to confirm that code-signing enforcement assumptions remain valid.
Analyst notes and limits

The supplied ATT&CK object is a detection strategy with no official description, no official detection text, and no tactics or platforms specified on the strategy itself. The only behavioral context comes from its relationship to T1632.001, Code Signing Policy Modification, which is in the mobile domain and lists Android and iOS as related platforms. Treat this take as guidance for validation and control assurance, not as a finished detection rule.

This summary is constrained to the supplied STIX fields, external reference, and relationship context. It does not establish active exploitation, adversary attribution, impact, customer exposure, or guaranteed detectability. Local mobile management architecture, device ownership model, logging depth, and incident response collection capability are required to determine real coverage.

Official MITRE ATT&CK definition

Detection of Code Signing Policy Modification

No official description is available in the imported ATT&CK source object.

View the same entry on attack.mitre.org (MITRE-hosted reference; in-page links above use the Glexia ATT&CK library.)

Glexia analysis

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.

ATT&CK relationship table

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.

1 rows
Domain ID Name Relationship / procedure
Mobile T1632.001 Code Signing Policy Modification Sub-technique This object detects Code Signing Policy Modification.
Relationship explorer

All related ATT&CK context

Change history

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 .

ATT&CK release
19.1
Object version
1.0
Created
Modified
Raw hash
fae408fc3abf1b83...
Imported snapshots across ATT&CK releases (1)
Release Bundle imported Object version Modified Status Raw hash
19.1 1.0 Current bundle fae408fc3abf…
Raw source

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.

Source references

External references and citations

MITRE external references are preserved separately from Glexia analysis so citations remain traceable to their original source records.

  1. [1]
    mitre-attack DET0619
    Open source URL
Source and licensing

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.