People who are targeted by skilled attackers need their phone's strongest settings switched on together and kept on, and Android Advanced Protection does that with one control. Google introduced the device-level Advanced Protection setting with Android 16, announced on 13 May 2025, as an extension of its Advanced Protection Program for Google Accounts. Turning it on enables a predetermined set of protections across apps, networks, USB, the browser, messaging and calls, adds optional tamper-resistant Intrusion Logging, and blocks the covered settings from being switched off quietly. This guide explains what each protection does, what it changes for the user, how to roll it out to executives, journalists and other high-risk staff, and how to use Intrusion Logging in an investigation. It is written for mobile and endpoint administrators, security teams supporting high-risk people, and the users themselves. For the wider programme across platforms, see the Executive and VIP Device Protection Guide.
This is an independent guide from NHI Mgmt Group, based on Google's public documentation as of November 2026. It is not sponsored or reviewed by Google. Product features change, so confirm settings against Google's current documentation.
Key takeaways
- One switch, many settings. Device protection turns on Google Play Protect enforcement, sideloading blocks, Memory Tagging Extension in supported apps, theft and USB locks, 2G blocking on supported devices, scam protections and stricter Chrome behaviour.
- The settings stay on. While Advanced Protection is active, the system blocks accidental or malicious disabling of the covered features; turning it off needs biometric or PIN authentication.
- Intrusion Logging is the investigator's friend. Optional, end-to-end encrypted device and network logs kept on Google servers for 12 months, readable only by the account holder, who can download and share them with a forensic expert.
- Expect trade-offs. Google states that the mode prioritises security over some functionality: sideloaded apps stop updating, some accessibility tools are limited to verified ones, USB data needs an unlocked screen, and 2G-only areas may lose cellular service.
- Pair device and account. Device protection hardens the phone; Account protection (the Advanced Protection Program) hardens the Google Account with passkeys or security keys. High-risk users should have both.
How identity and access work in Android Advanced Protection
Advanced Protection sits on top of the device's normal identity controls rather than replacing them. Three identities matter: the person unlocking the device, the Google Account on it, and the apps that ask for access.
- Screen lock first: a screen lock (PIN, pattern or password) must be set before Advanced Protection can be turned on. If it is later removed, the program stays active but some protections may not work well and the device shows a warning. Google also notes that the screen lock is part of the key recovery for Intrusion Logging, so removing it can make logs permanently undecryptable if the device is lost.
- Locks that react to risk: Failed Authentication Lock locks the device after repeated failed attempts; Inactivity Reboot restarts a device that has been locked for 72 hours, so its data is unreadable until the next unlock; Theft Detection Lock and Offline Device Lock lock the screen on suspected snatch-and-run motion or long offline use.
- Watch Unlock restricted: the phone does not auto-unlock just because a paired watch is nearby, so physical proximity of a second device is not enough to open it.
- Account protection: enrolling the Google Account in the Advanced Protection Program requires a passkey or security key at sign-in, limits Google Account data access to Google apps and verified third-party apps, and limits app installs to verified stores. See the Google Advanced Protection Program Guide and the Passkeys for Everyone Guide.
Our recommendation (NHI Mgmt Group): use a six-digit or longer PIN or an alphanumeric password for high-risk users, keep biometrics for convenience, and enrol both Device protection and Account protection on the same day so the phone and the account are hardened together.
Admin roles and privileged access
Advanced Protection is a user-controlled setting on the device. The person holding the phone turns it on and off, and turning it off requires biometric or PIN authentication. That design matters for high-risk users because an attacker with brief access to an unlocked phone cannot simply flip individual protections off.
| Action | Where (Google, checked November 2026) | What happens |
|---|---|---|
| Turn on | Settings > Security & privacy > Other settings > Advanced Protection (or Settings > Google > All services > Personal and device safety > Advanced Protection), then Device protection; menu names vary by device maker | Protections switch on; a reboot may be needed ("Restart" or "Restart later") |
| Add Intrusion Logging | Optional during setup; choose the Google Account that will hold the encrypted log backup | Device and network events start uploading, encrypted |
| Add Account protection | Optional enrolment of the Google Account in the Advanced Protection Program | Passkey or security key required at sign-in |
| Turn off | Same path, turn off Device protection, authenticate with biometrics or PIN | Settings revert to their previous state, possibly after a reboot; Account protection stays until unenrolled separately |
Corporate-managed devices: as of November 2026 Google's Advanced Protection pages describe it as a user setting. For company-owned phones, agree the process with your EMM administrator, test on pilot devices enrolled the same way as production, and check how your EMM's own app distribution and policies behave with sideloading blocks before wide rollout. See the Android Enterprise Security Guide and the Mobile Device Management Security Guide.
Support staff: treat a request to turn Advanced Protection off as a security event for a high-risk user. Our recommendation: record who asked, why and for how long, and agree a time to turn it back on.
Integrations, API tokens and service accounts
Advanced Protection is also a signal that apps can read. Chrome, Google Messages and Phone by Google already use it as a single control point, and Google's developer documentation lets any app check and react to the state.
- Permission: apps declare
android.permission.QUERY_ADVANCED_PROTECTION_MODEin the manifest. - State check: the
AdvancedProtectionManagersystem service reports whether the mode is enabled; Google recommends an on-demand query during app initialisation. - Runtime changes: apps register a callback to learn when the user turns the mode on or off. Callbacks end when the app terminates, so register them at start-up.
- What apps should expect: Google lists disabled 2G and WEP connections, blocked sideloading, active forensic logging, blocked calls from unknown numbers and spam protection for links in messaging apps.
For in-house app teams: if your organisation ships an app to high-risk staff or customers, read the mode and tighten behaviour when it is on, for example by requiring re-authentication for sensitive actions, disabling optional web content or plugins, and shortening session lifetimes. That is your design choice; the platform only provides the signal. See the Android App Security Guide and the Kotlin and Android Secure Coding Guide.
Tokens on the device: Advanced Protection does not change how apps store OAuth refresh tokens or API keys. Our recommendation: for high-risk users, keep corporate tokens in managed apps inside a work profile, use short-lived tokens, and revoke them centrally if the device is lost.
Logging and detection
Intrusion Logging is the part of Advanced Protection that changes incident response for mobile devices. Google describes it as a privacy-preserving, tamper-resistant backup of device logs, visible only to the user.
| Logged event type (Google, checked November 2026) | Investigation value |
|---|---|
| App process starts; app installs, updates and uninstalls | Spot an unexpected app or a short-lived process |
| Wi-Fi and Bluetooth start and stop | Correlate with location and time of suspected compromise |
| DNS lookups and IP addresses | Match against known malicious infrastructure from threat intelligence |
| File transfers over USB | Detect data copied off or on during physical access |
| Changes to system certificates | Find interception set-ups that rely on a rogue certificate |
| Device lock and unlock events | Build a timeline of when the phone was in use |
- Encryption: data is end-to-end encrypted on the device before upload; keys are protected by the Google Account password and screen lock credentials, so Google cannot read the logs.
- Retention: 12 months on Google servers, then automatic deletion. Neither the user nor Google can delete logs early, even if the account is closed or the feature is turned off. Turning logging off stops new events at once; earlier logs remain for the 12 months.
- Access: Settings > Security & privacy > Advanced Protection > Intrusion Logging > Access logs, select the device, then Download & decrypt. Logs can be downloaded from any Android device signed in to the same Google Account. After download, the user is responsible for protecting the files.
- Chrome DNS: Chrome's own resolver can bypass Android's, so its DNS events may not appear. Google's fix is to turn off Chrome's "Use secure DNS" and use Android Private DNS (Settings > Network & internet > Private DNS).
- Volume: during heavy activity the frequency of logged events may be reduced.
Process (our recommendation): agree in advance with each high-risk user how logs will be shared with your incident response team or an external mobile forensics provider, over which channel, and how the copies are stored and destroyed. See the Mobile Forensics Guide and the Spyware and Stalkerware Guide.
Measuring the rollout
- Coverage: percentage of named high-risk users with Device protection on (target: all).
- Account pairing: percentage of those users also enrolled in Account protection.
- Logging: percentage with Intrusion Logging enabled and a tested download-and-share route.
- Exceptions: number of turn-off requests per quarter and median time until protection is back on.
- Help desk load: tickets caused by sideloading, USB or 2G effects in the first month, used to improve user briefings.
Hardening baseline
The table lists what Device protection switches on, as described by Google in November 2026, and the effect a user will notice.
| Area | Protection | What the user notices |
|---|---|---|
| Apps | Google Play Protect stays on | The Play Protect toggle cannot be turned off |
| Apps | Unknown apps blocked | No installs from unknown sources, and no updates for apps already installed that way |
| Apps | Memory Tagging Extension (MTE) | Helps stop memory corruption in supported apps on supported hardware; may slow performance |
| Apps | Accessibility limited to verified tools | Unverified accessibility services cannot be used |
| Device safety | Theft Detection Lock, Offline Device Lock, Failed Authentication Lock | Screen locks on suspected theft, long offline use or repeated failed unlocks |
| Device safety | Inactivity Reboot | Reboots after 72 hours locked |
| Device safety | USB Protection | New USB data connections need an unlocked screen; charging continues |
| Device safety | Watch Unlock restricted | A nearby watch no longer unlocks the phone |
| Messages | Scam and spam protection, link warnings, Scam Detection required | Warnings on links from unknown senders and on likely scam notifications |
| Network | 2G blocked on supported devices | No cellular service where only 2G is available |
| Phone by Google | Caller ID and spam identification; call screening in supported regions | Spam calls identified or declined |
| Web (Chrome) | Safe Browsing live threat protection, HTTPS where possible, JavaScript optimiser off, WebGPU off | Some heavy web apps may run slower |
| Investigation | Intrusion Logging (optional) | None day to day |
USB Protection details
- Google states USB Protection is available on Pixel 6 and later and turns on automatically with Device protection; effectiveness can differ by manufacturer.
- A data connection started while unlocked stays active after the screen locks, until it is unplugged. Brief disconnects on a locked screen are tolerated for a few seconds for loose cables.
- USB stays unprotected until boot completes. Our recommendation: brief users to unplug before locking the phone in an untrusted place, and never to unlock it for an unknown cable or kiosk.
Phased rollout (our recommendation)
- Name the population: executives, board members, journalists, legal, people handling sensitive negotiations, and anyone already subject to targeted phishing. Use the risk tiers in the Executive and VIP Device Protection Guide.
- Check devices: confirm each phone runs Android 16 or later from a manufacturer that ships the feature; Google notes some protections depend on device support (USB Protection on Pixel 6 and later, 2G blocking on supported devices, MTE on supported hardware).
- Inventory sideloaded apps: list any apps the user installed outside Google Play or the manufacturer's store; plan replacements, because they will stop receiving updates.
- Pilot: enable on two or three volunteer devices for two weeks, including travel to a low-coverage area, and log every friction point.
- Brief and enrol: a 20-minute session per user to turn on Device protection, Intrusion Logging and Account protection together, register two security keys or passkeys, and explain what will change.
- Rollback path: the user can turn it off with biometrics or PIN and settings revert; record the reason and set a date to re-enable.
- Review quarterly: new protections arrive through updates, so re-read Google's page and update user briefings.
For the full settings picture outside this mode, see the Android Security and Privacy Settings Guide; for separating personal apps on the same phone, see Android Private Space.
Framework mapping
| Advanced Protection feature | NIST SP 800-53 Rev 5 | NIST CSF 2.0 | ATT&CK Mobile technique it helps against |
|---|---|---|---|
| One locked configuration for high-risk devices | CM-6 Configuration Settings, AC-19 Access Control for Mobile Devices | PR.PS-01 | Baseline for all techniques below |
| Sideloading block, Play Protect | CM-7 Least Functionality, SI-3 Malicious Code Protection | PR.PS-05 | T1474 Supply Chain Compromise |
| Chrome restrictions, Safe Browsing, link warnings | SC-18 Mobile Code, SI-3 | PR.PS-05 | T1456 Drive-By Compromise, T1660 Phishing |
| USB Protection | AC-19 | PR.PS-01 | T1458 Replication Through Removable Media |
| Failed Authentication Lock, Inactivity Reboot, Theft Detection Lock | AC-19, IA-2 | PR.AA-03 | T1461 Lockscreen Bypass |
| Intrusion Logging | AU-9 Protection of Audit Information | DE.CM-09 | Supports investigation of all of the above |
Common misconfigurations
- Device protection without Account protection: the phone is hardened but the Google Account can still be phished with a password and code. Enrol the account with passkeys or security keys at the same time.
- Intrusion Logging left off: it is optional at setup. Turn it on for high-risk users, because the logs only cover activity from the moment it is enabled.
- Removing the screen lock: protections may degrade and Intrusion Logging recovery depends on it. Keep a strong screen lock in place.
- Surprise sideloading breakage: apps installed from unknown sources stop updating. Inventory and replace them before enabling.
- Chrome DNS gaps in logs: with Chrome's secure DNS on, Chrome lookups may be missing. Use Android Private DNS instead, as Google advises.
- Unplanned travel impact: 2G blocking can leave a user without cellular service in 2G-only areas. Brief travellers and plan Wi-Fi or satellite alternatives. See the Mobile Communications Protection for High-Risk Individuals Guide and the Cellular Baseband and IMSI Catcher Guide.
Practitioner checklist
- Maintain a named list of high-risk users and confirm each has a phone on Android 16 or later with the feature available.
- Inventory and replace sideloaded apps before enabling Device protection.
- Turn on Device protection, Intrusion Logging and Account protection together, with two registered passkeys or security keys.
- Keep a strong screen lock and brief users on why it must stay.
- Switch Chrome to Android Private DNS where full DNS logging is needed.
- Agree a secure route for sharing downloaded Intrusion Logging files with your responders.
- Treat turn-off requests as security events with a re-enable date.
- Pilot with corporate EMM enrolment before broad rollout on company-owned devices.
- Track coverage, logging and exception metrics quarterly, and re-read Google's documentation for new protections.
Standards and references
- Google: Android Advanced Protection help
- Google: Log device activity with Advanced Protection (Intrusion Logging)
- Google: USB threats with Advanced Protection Mode
- Android Developers: Advanced Protection Mode
- Google Online Security Blog: Advanced Protection, Google's strongest security for mobile devices
- Google: Android theft protection features
- Google: Advanced Protection Program
Related NHI Mgmt Group resources: Executive and VIP Device Protection Guide · Google Advanced Protection Program Guide · Android Security and Privacy Settings Guide · Mobile Forensics Guide · Spyware and Stalkerware Guide