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

DET0603: Detection of Device Lockout

MITRE ATT&CK DET0603: Detection of Device Lockout Detection Strategy details, with detection guidance, relationships and mapped CVEs.

MobileDET0603Detection StrategyObject v1.0Modified
Glexia's Take · Automated analysis

Security context for executives and security teams

Automation confidenceMedium

DET0603 is a mobile ATT&CK detection strategy for recognizing device lockout behavior associated with T1629.002. The business issue is not just a locked phone: if a legitimate user is prevented from using an Android device, incident responders may lose visibility, employees may lose access to business apps, and recovery may depend on whether mobile management, identity, and support teams have usable evidence and procedures.

Executive priority

Treat this as a mobile resilience and incident-readiness concern for Android environments. Leaders should ask whether the organization can identify device lockout events quickly, determine whether device administrator privileges or suspicious foreground behavior preceded the lockout, and support the user without destroying evidence. This matters for workforce continuity, help desk escalation, mobile security control validation, and audit evidence that managed mobile devices are monitored and recoverable.

Technical view

The supplied ATT&CK object has no official detection text and no platform listed for the detection strategy itself, but it detects T1629.002 Device Lockout, which is described for Android. SOC, mobile security, and IR teams should validate whether they can correlate lockout reports with Android device administration events, app permission changes, MDM/UEM state, and suspicious app behavior such as persistent overlays or foreground-locking patterns where such telemetry is available. Because lockouts can also be legitimate user, policy, or support events, detection should emphasize context and sequencing rather than a single alert condition.

Likely telemetry

  • MDM/UEM device state, compliance, enrollment, and remote action logs
  • Android device administrator activation, policy change, and lock-related events where collected
  • Mobile application inventory, install/update history, and permission changes
  • User/help desk reports of sudden device lockout or inability to dismiss foreground screens
  • Identity and access logs showing mobile app access interruption or unusual authentication failures after lockout

Detection direction

  • Validate that Android device lockout-related telemetry is actually collected centrally; ATT&CK provides no official DET0603 detection logic.
  • Correlate lockout timing with recent device administrator permission requests, new app installation, app updates, or MDM policy changes.
  • Separate expected administrative lock actions from suspicious local app-driven lockout behavior to reduce false positives.
  • Use help desk tickets and user reports as a detection input, because lockout may be visible to the user before it is visible in security tooling.
  • Check for blind spots on personally owned or lightly managed Android devices where device policy, app inventory, and permission telemetry may be limited.

Mitigation priorities

  • Prioritize clear governance for which apps may receive device administrator privileges on managed Android devices.
  • Use MDM/UEM policy, app inventory, and compliance controls to limit unmanaged or untrusted apps where the organization has authority to do so.
  • Create IR and help desk runbooks for preserving evidence while restoring user access to locked mobile devices.
  • Ensure mobile identity access decisions account for device compliance and recovery status after a lockout event.
  • Document collection and response procedures as compliance evidence for mobile device monitoring and incident handling.
Additional notes and limits

This take is based on the DET0603 detection strategy object and its relationship to T1629.002 Device Lockout. The most useful defensive work is validation: confirm whether mobile management, identity, help desk, and SOC workflows can tie a reported lockout to device administrator activity, app changes, or suspicious foreground behavior.

The official DET0603 object supplies no description, no detection text, no tactics, and no platforms. Android context comes from the related T1629.002 technique, not from the detection strategy platform field. Local telemetry availability and management scope determine how actionable this detection strategy can be.

Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.

Official MITRE ATT&CK definition

Detection of Device Lockout

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
DomainIDNameRelationship / procedure
MobileT1629.002Device LockoutSub-techniqueThis object detects Device Lockout.
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
63f2ebae531690bf...
Imported snapshots across ATT&CK releases(1)
ReleaseBundle importedObject versionModifiedStatusRaw hash
19.11.0Current bundle63f2ebae5316…
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-attackDET0603
    Open source URL
  2. [2]
    mitre-attackDET0603
    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.