A lost or stolen phone is only as safe as its lock screen, because once the screen is open the attacker inherits the mailbox, the authenticator apps and every signed-in session on the device. MITRE ATT&CK for Mobile T1461 Lockscreen Bypass (tactic TA0027 Initial Access) covers an adversary with physical access getting past the device lock, and ATT&CK v20 maps it to Android and iOS. It also records malware that weakens the lock screen from inside an infected device. This guide sets out the bypass methods ATT&CK describes, the platform protections that already exist on each side, the MDM policies that strengthen them and what to monitor. It is for mobile and endpoint engineers, identity teams and incident responders handling lost devices. For the matrix overview see the MITRE ATT&CK for Mobile Guide.
Key takeaways
- Three routes, all physical. ATT&CK lists biometric spoofing, guessing or observing the passcode, and exploiting lock screen vulnerabilities.
- The passcode is the real control. Both platforms fall back to the passcode after restart and after set time limits, so passcode strength and the wipe threshold decide most outcomes.
- Hardware throttling is already strong. iOS enforces escalating delays in the Secure Enclave; Android checks the credential in the TEE through Gatekeeper, or a secure element through Weaver.
- Malware attacks the lock from inside. Escobar and VajraSpy requested DISABLE_KEYGUARD, Chameleon pushed users from biometrics to PIN so it could capture the PIN, and BRATA could unlock remotely.
- Revoke sessions fast. The response to a lost device is identity work: remote lock or wipe, then revoke tokens and re-register authenticators.
How the bypass methods work
- Biometric spoofing: presenting a fake fingerprint or face. ATT&CK notes both platforms partly mitigate this by requiring the passcode after every restart and after a set or random time.
- Unlock code bypass: brute-forcing or guessing the PIN or password, or shoulder surfing it. Vendors mitigate with escalating back-off timers and an optional wipe after repeated failures.
- Vulnerability exploit: lock screen bypass bugs have been demonstrated periodically and are patched by the OS vendor once disclosed, which is why ATT&CK lists M1001 Security Updates.
Shoulder surfing deserves attention: a passcode observed in a public place and then used with the stolen device defeats throttling and biometric protections at once. Apple's Stolen Device Protection, covered below, was designed for exactly that pattern.
Built-in protections on each platform
| Protection | iOS and iPadOS | Android |
|---|---|---|
| Where the passcode is checked | Secure Enclave enforces the attempt delays; a restart does not reset them | Gatekeeper in the Trusted Execution Environment, or Weaver in a secure element where available |
| Failed attempt handling | No delay for 3 attempts, then 1 minute, 5 minutes, 15 minutes, 1 hour, 3 hours and 8 hours; at 10 attempts the device locks and must connect to a computer. Optional Erase Data after 10 consecutive failures | Rate limiting of credential attempts; admin can set maximumFailedPasswordsForWipe |
| When biometrics stop being accepted | After restart, 48 hours without unlock, passcode unused for 156 hours with no biometric unlock for 4 hours, a remote lock command, Emergency SOS cancel, or 5 failed biometric matches | Class 3 (strong) biometrics: primary authentication required at least every 72 hours. Class 2 and Class 1: every 24 hours, after a 4-hour idle timeout or after 3 incorrect attempts |
| Spoof resistance requirement | Face ID and Touch ID matching runs in the Secure Enclave | Android classes biometrics by spoof acceptance rate: Class 3 at 0 to 7 percent, Class 2 at 7 to 20 percent |
| Theft-specific protection | Stolen Device Protection (iOS 17.3 or later): biometric-only for sensitive actions away from familiar locations, with a one-hour security delay for critical changes | Admin can require a separate work profile lock (REQUIRE_SEPARATE_WORK_LOCK) and limit how long weaker methods unlock the device (requirePasswordUnlock) |
Apple also lists operations that always need the passcode regardless of biometrics, including installing software updates, erasing the device, changing passcode settings and installing configuration profiles. Stolen Device Protection must be turned on before the device is lost, and it requires two-factor authentication on the Apple Account, a passcode, Face ID or Touch ID, Significant Locations and Find My. See the iOS and iPadOS Enterprise Security Guide and the Android Enterprise Security Guide for the wider baselines.
Malware that weakens the lock screen
| Software | Behaviour recorded by ATT&CK v20 | Defensive signal |
|---|---|---|
| BRATA (S1094) | Can ask the user to unlock the device, or unlock it remotely | Sideloaded app with accessibility or remote-control capability |
| Chameleon (S1083) | Uses accessibility events to switch the unlock prompt from biometric to PIN, so the PIN can be captured | Unexpected accessibility service enabled; users report biometric unlock "stopped working" |
| Escobar (S1092) | Requests the DISABLE_KEYGUARD permission to disable the lock screen password | App manifest requesting DISABLE_KEYGUARD with no business reason |
| VajraSpy (S9006) | Requests android.permission.DISABLE_KEYGUARD | Same as above, in app vetting and MDM inventory |
All four are Android examples. They rely on a malicious app being installed first, usually from outside the store, so blocking unknown-source installs and reviewing accessibility permissions does as much as any lock screen setting. The Android Banking Trojans Guide covers the families that use these tricks for fraud. ATT&CK tracks the accessibility abuse itself as T1453 Abuse Accessibility Features.
MDM policy settings that close the gaps
ATT&CK's M1012 Enterprise Policy recommends minimum passcode complexity, a wipe after too many failures and, where needed, disabling biometrics. The settings that implement it:
| Goal | Apple MDM | Android Management API |
|---|---|---|
| Minimum passcode strength | Passcode payload or declarative passcode configuration (minimum length, require alphanumeric) | passwordPolicies with passwordQuality such as COMPLEXITY_MEDIUM or COMPLEXITY_HIGH, or passwordMinimumLength |
| Wipe after failed attempts | Maximum failed attempts in the passcode policy (management can set a threshold below 10) | maximumFailedPasswordsForWipe |
| Limit biometric-only unlock time | Platform limits above; disable Face ID or Touch ID by restriction where policy requires | requirePasswordUnlock; keyguardDisabledFeatures values BIOMETRICS, FACE, DISABLE_FINGERPRINT |
| Reduce lock screen exposure | Restrictions for lock screen notifications and Control Centre where needed | keyguardDisabledFeatures: UNREDACTED_NOTIFICATIONS, TRUST_AGENTS, CAMERA |
Rollout: introduce stronger passcode rules as a compliance requirement with a grace period, since users must change their passcode at the next prompt. Pilot with one group, check help desk volume, then widen. A wipe threshold that is too low causes accidental wipes from children or pockets; pair it with reliable backup of managed data. Rollback is a policy change, but a wiped device cannot be restored without a backup, so confirm backup first.
Choosing between options
- Standard staff: a six-digit or longer non-sequential PIN, wipe threshold of 10, biometrics allowed, Stolen Device Protection encouraged.
- Privileged or high-risk staff: alphanumeric passcode, separate work profile lock on Android, lock screen notifications hidden, and a shorter biometric window.
- Shared or kiosk devices: single-app or dedicated device modes with no personal data, so a bypass yields little.
Detection and response
ATT&CK v20's DET0645 Detection of Lockscreen Bypass correlates, on Android, app permission grant state, managed package inventory and device policy compliance or SecurityLog events where supported; on iOS, installed and managed app lists and MDM security and restriction queries, treated as periodic state. Useful signals:
- Compliance drift: a device reporting no passcode or a passcode below policy.
- Permission red flags: any app holding DISABLE_KEYGUARD or a non-approved accessibility service.
- Lost-device reports: time from report to remote lock, and whether the device checked in after the report.
- Identity anomalies: sign-ins or authenticator approvals from a device after it was reported lost.
When a device is reported lost or stolen, lock or wipe it through MDM, revoke refresh tokens and app passwords, remove the device as an authenticator and check for sign-ins since the loss. The Stolen or Lost Phone guide gives the full sequence.
Metrics
- Percentage of devices compliant with the passcode policy.
- Percentage of iPhones with Stolen Device Protection on, where your MDM reports it.
- Median time from lost-device report to remote lock and to token revocation.
- Count of devices with apps holding DISABLE_KEYGUARD or unapproved accessibility services.
Where identity fits
An unlocked phone is often a second factor as well as a session store: push approvals, passkeys, one-time code apps and SMS all live there. Prefer phishing-resistant authenticators that require user verification at each use, keep app tokens in the Keychain or Android Keystore bound to user authentication, and make token revocation part of every lost-device ticket. See Mobile Access Credentials.
Common failure patterns
- Four-digit or sequential PINs: easy to observe and easy to guess; use complexity-based policy, not just length.
- No wipe threshold: leaving
maximumFailedPasswordsForWipeat 0 (no restriction) removes a key backstop. - Trust agents left on: unlock-on-location or unlock-on-Bluetooth keeps a stolen device open near the owner's home or car.
- Treating a lost phone as a hardware ticket: sessions and authenticators stay live while the device is on its way to a replacement queue.
- Delayed OS updates: lock screen bypass bugs are patched in routine releases.
Framework mapping
| Framework | Reference | Relevance |
|---|---|---|
| ATT&CK for Mobile | M1012 Enterprise Policy; M1001 Security Updates | The listed mitigations |
| NIST SP 800-53 Rev 5 | AC-7 Unsuccessful Logon Attempts; AC-19 Access Control for Mobile Devices; IA-5 Authenticator Management; IA-11 Re-authentication | Throttling, wipe, passcode policy, re-authentication windows |
| NIST CSF 2.0 | PR.AA-03; PR.PS-01 | Device authentication and configuration management |
| ISO/IEC 27001:2022 Annex A | A.8.1 User end point devices; A.8.5 Secure authentication | Device and authentication controls |
Practitioner checklist
- Enforce a complexity-based passcode policy on both platforms and track compliance.
- Set a failed-attempt wipe threshold and confirm managed data is backed up.
- Disable trust agents and hide unredacted notifications on the lock screen for work devices.
- Encourage or require Stolen Device Protection on iPhones; require a separate work lock on Android where risk warrants it.
- Block unknown-source installs and alert on DISABLE_KEYGUARD and unapproved accessibility services.
- Keep OS updates current to close lock screen bypass bugs.
- Make token revocation and authenticator removal part of every lost-device process.
Standards and references
- MITRE ATT&CK: T1461 Lockscreen Bypass (Mobile)
- Apple Platform Security: Passcodes and passwords
- Apple Platform Security: Face ID, Touch ID, passcodes and passwords
- Apple: About Stolen Device Protection for iPhone
- Android Open Source Project: Authentication
- Android Open Source Project: Measuring biometric unlock security
- Google: Android Management API PasswordRequirements
- Google: Android Management API policies reference
Related NHI Mgmt Group resources: MITRE ATT&CK for Mobile Guide · Stolen or Lost Phone · Mobile Device Security Guide · Mobile Device Management Security Guide · Mobile T1458 Replication Through Removable Media · Mobile T1464 Network Denial of Service