Journalists, campaign staff, executives, activists and administrators are phished with lures built for them personally, and ordinary two-step verification with codes or prompts does not stop a well-run adversary-in-the-middle attack. Google's Advanced Protection Program (APP) is Google's strongest account setting for people at high risk of targeted attacks: it requires a passkey or security key to sign in, limits which apps can reach account data, adds checks on downloads and tightens account recovery. This guide explains what enrolment changes, how to enrol personal and Google Workspace accounts, what breaks, how recovery works, the admin controls and logs in Workspace, and how APP relates to Android's device-level Advanced Protection. It is written for security teams protecting high-risk staff, Workspace administrators, and individuals who support at-risk people. Facts were checked on Google's own help and product pages on 8 November 2026; Google adds protections over time, so confirm details on the linked pages.
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
- Phishing-resistant sign-in is mandatory. Enrolled accounts must sign in with a passkey or a FIDO-compliant security key; a password sign-in also requires a security key, and app passwords are revoked on enrolment.
- Third-party access shrinks. Only Google apps and verified third-party apps can access sensitive account data, and in Workspace, apps requesting high-risk scopes are blocked unless the admin trusts them.
- Recovery is deliberately slow. Google says a recovery request takes a few days to verify; in Workspace, recovery goes through the administrator. Register a backup key before you need it.
- Workspace admins enable it, users enrol. Admins turn on enrolment per organisational unit under Security, Authentication, Advanced Protection Program, but Google states enrolment cannot be made mandatory.
- Android has a separate device setting. Android Advanced Protection hardens the phone itself (sideloading block, USB protection, 2G block, optional intrusion logging) and can also enrol your Google Account.
How identity and access work in Google Advanced Protection
Google describes APP as for people most at risk of phishing, hacking and targeted digital attacks, and states it costs nothing to use (security keys must be bought if you choose them). It works on consumer Google Accounts and on Workspace and Cloud Identity accounts. Enrolling changes four things at once.
| Protection | What Google states it does | Threat it addresses |
|---|---|---|
| Strong sign-in | Passkey or security key required; password sign-in needs a security key; app passwords blocked and existing ones revoked | Phishing (ATT&CK T1566), MFA Interception (T1111), MFA Request Generation (T1621) |
| Restricted data access | Only Google apps and verified third-party apps can access sensitive data; Apps Script requesting sensitive data may be blocked | Consent phishing and Steal Application Access Token (T1528) |
| Download checks | Chrome warns when Safe Browsing cannot confirm a download is safe; the user can send it to Advanced Protection for scanning; dangerous files are blocked | Malicious attachments and drive-by downloads |
| Strict recovery | Recovery requests take a few days for Google to verify; Workspace users recover through the admin | Account takeover through social-engineered recovery |
Passkeys and security keys
- Passkeys: unlocked with a fingerprint, face scan or device screen lock, and can be created on a phone, a computer or a hardware security key. Signing in with a passkey skips the separate second step.
- Hardware keys: connect by USB or NFC. Google sells Titan Security Keys and states any FIDO-compliant key works. See the Hardware Security Keys Guide.
- Backups: Google recommends a primary key plus at least one backup, and carrying a key whenever you may sign in on a new device or travel.
- Platform notes from Google: Linux may need a udev rule for security keys; Android TV may need the account removed and re-added using a phone on the same Wi-Fi network.
Enrolment steps (personal accounts)
- Add a recovery email address and phone number to the account.
- Turn on 2-Step Verification.
- Create a passkey or order at least two security keys (primary and backup).
- Start enrolment from the Advanced Protection page in your Google Account and register the passkey or keys.
- Sign back in on each device and app; review which third-party apps still work.
- Enrol other accounts the same person uses: Google recommends enrolling both work and personal accounts for people at high risk.
Rollback: on a signed-in device, open the Security section of the Google Account and select Unenroll under Advanced Protection Program. Plan a reason and a date for re-enrolment, because an unenrolled high-risk account is the easiest target you have.
Admin roles and privileged access
Google's Workspace guidance lists Workspace and Cloud Identity super admins and delegated admins first among the users who should enrol. They are the accounts whose compromise hands an attacker the tenant.
| Admin task | Where in the Admin console | Privilege Google states |
|---|---|---|
| Enable user enrolment | Menu, Security, Authentication, Advanced Protection Program; select the organisational unit; "Enable user enrollment" (selected by default) | Super administrator |
| Set security code policy | Same page: "Don't allow users to generate security codes", "Allow security codes without remote access" (default) or "Allow security codes with remote access" | Super administrator |
| Check a user's status | Directory, Users, user, Security: "Advanced Protection" shows On | Users > Read |
| Unenrol a user | Directory, Users, user, Security card: set "Advanced Protection" to Off and save; the user cannot re-enrol afterwards | Security > User Security Management |
| Restore access after lost keys | Strict account recovery runs through the administrator | Admin with user security rights |
- Prerequisite: 2-Step Verification must be enabled for the entire top-level organisation, including all domains. APP then takes over 2SV policy for enrolled users and its settings take precedence, even where the domain uses a third-party identity provider.
- No forced enrolment: Google states admins cannot make enrolment mandatory. Make it a condition of holding an admin role through policy, and verify it with the status check above.
- Security codes: one-time codes for platforms that cannot use keys or passkeys, generated on a device and browser that can. Google says they weaken protection; "with remote access" is the least secure option. Choose "Don't allow" for admin organisational units.
- Disabling enrolment does not unenrol anyone: turning the organisational setting off leaves existing users enrolled.
For the wider admin model, see the Google Workspace Security Guide.
Integrations, API tokens and service accounts
This is where enrolment causes most friction, and where most of the protection comes from.
- High-risk scopes blocked: in Workspace, apps requesting high-risk scopes are blocked unless the admin explicitly trusts them or they are on the default trusted list. Google names Google native apps, Apple native iOS apps, Apple Mail on macOS and Mozilla Thunderbird. The trusted apps list applies to the whole organisation.
- Sign in with Google: still works, subject to the same verified-app restriction.
- App passwords: blocked, and existing ones revoked at enrolment. Any mail client or device still using an app password stops working.
- Apps Script: scripts can run, but those requesting sensitive data such as email, documents or photos may be blocked.
- Sessions reset: after enrolment, users are signed out of all devices and third-party apps and must sign in again, which also ends any stolen session (T1539).
- Nest: works with enrolled accounts; Google recommends all members of a Nest home enrol.
Where identity fits
APP protects a human account, but the integrations it blocks are non-human identities: OAuth clients, refresh tokens, app passwords and scripts acting on the user's behalf. Inventory them before enrolment so that business-critical automation moves to a properly owned service account rather than being quietly re-trusted. Domain-wide delegation is granted by administrators rather than by user consent, so do not assume APP enrolment reviews it; check it separately with the Google Workspace Domain-Wide Delegation Security Guide.
Android Advanced Protection
Android Advanced Protection is a device setting, separate from the account programme but linked to it. It requires a screen lock. Turn it on in Settings, Security & Privacy, Other settings, Advanced Protection (or Google, All services, Advanced Protection), switch on Device protection, optionally enable Intrusion Logging, and optionally enrol your Google Account under Account protection. Some devices need a restart, and Google notes some protections can stay on after Device protection is turned off if the account is enrolled.
| Area | Protections Google lists |
|---|---|
| Apps | Google Play Protect cannot be turned off; installs and updates from unknown sources blocked; Memory Tagging Extension for supported apps; accessibility limited to verified tools |
| Device safety | Theft Detection Lock, Offline Device Lock, Inactivity Reboot after 72 hours locked, USB Protection while locked, Failed Authentication Lock, restricted Watch Unlock |
| Network | 2G Network Protection on supported devices (may lose service where only 2G exists) |
| Messages and Phone | Spam and scam protection, unsafe link warnings, Scam Detection required; caller ID and spam, Automatic Call Screen in supported regions |
| Web | Safe Browsing Live Threat Protection; Chrome enforces HTTPS where possible and turns off its JavaScript optimiser and WebGPU |
| Investigation | Optional Intrusion Logging: security logs stored in the cloud with end-to-end encryption to support investigation of suspected compromise |
The iPhone equivalent for device hardening is covered in the Apple Lockdown Mode Guide; general Android settings are in the Android Security and Privacy Settings Guide.
Logging and detection
| Signal | Where to find it | What to look for |
|---|---|---|
| Enrolment and disable events | Reporting, Apps reports, User activity, filtered by organisational unit (Reports privilege) | Entries such as "[user] has enrolled for Advanced Protection" and disable entries for high-risk users |
| Admin changes to APP settings | Reporting, Audit and investigation, Admin log events (Audit & Investigation privilege) | Event names "Application Setting Creation" or "Application Setting Change" with description "Advanced Protection Program" |
| Per-user status | Directory, Users, Security | "Advanced Protection" On for every admin and named high-risk user |
| Device compromise evidence (Android) | Intrusion Logging backups in the chosen Google Account | Preserve before wiping a suspect device |
Alert on any change to the security code setting and on any high-risk user being set to Off. Correlate with the Google Workspace Audit Log Detection Guide.
Metrics that show it is working
- Coverage: percentage of super admins, delegated admins and named high-risk users enrolled (target 100%).
- Backup readiness: percentage of enrolled users with two or more registered keys or passkeys.
- Security code exposure: number of organisational units allowing security codes with remote access (target zero for admins).
- Unenrolment events: count per quarter, each with a recorded reason.
- Recovery time: median time to restore a locked-out enrolled user, tested in drills.
Hardening baseline
- Prepare: enforce 2SV across the top-level organisation, buy two keys per high-risk user, and inventory third-party apps, app passwords and scripts those users rely on.
- Pilot: place two or three volunteers (ideally the security team) in a dedicated organisational unit, enable enrolment there, set security codes to "Don't allow", and record what breaks for two weeks.
- Trust deliberately: add only business-required apps to the trusted list, recognising it applies organisation-wide.
- Enrol admins: all super and delegated admins, then executives, communications, finance approvers and anyone publicly visible.
- Cover personal accounts: offer guidance and keys for high-risk staff's personal Gmail accounts, since attackers pivot there. See the Personal Security for High-Risk Individuals Guide.
- Harden devices: turn on Android Advanced Protection or Lockdown Mode on high-risk users' phones; protect iCloud backups with security keys, as Google warns restoring an iCloud backup signs the user in on the new device.
- Drill recovery: run a lost-key exercise so the admin recovery path is known and verified out of band.
- Elections: Google offers enhanced protection for election season through a request form, and free Titan keys to eligible political teams through Defending Digital Campaigns.
Framework mapping
| APP capability | NIST SP 800-53 Rev 5 | NIST CSF 2.0 |
|---|---|---|
| Passkey or security key sign-in | IA-2, IA-5 | PR.AA-03 |
| Verified-app restriction, blocked app passwords | AC-3 | PR.AA-01 |
| Download scanning, unknown-source install block | SI-3, CM-11 | PR.PS-01 |
| Enrolment and settings audit | AU-6 | DE.CM-03 |
Common misconfigurations
- Single key, no backup: one lost key and a few days locked out. Register at least two.
- Security codes with remote access for admins: Google calls it the least secure option; it reopens the remote phishing path APP closes.
- Trusting apps to stop complaints: every trusted app applies organisation-wide and widens the attack surface for all enrolled users.
- Enrolling the work account only: attackers target the personal account and pivot. Google recommends enrolling both.
- Assuming disabling enrolment rolls users back: Google states existing users stay enrolled; check status per user, and review domain-wide delegation separately.
- Weak recovery verification: help desks that restore access on a phone call undo the programme. See the Account Recovery and Help Desk Security Guide.
Practitioner checklist
- Enforce 2-Step Verification across the top-level organisation and all domains.
- Enable enrolment for admin and high-risk organisational units; set security codes to "Don't allow".
- Issue two FIDO-compliant keys or passkeys per high-risk user and confirm both are registered.
- Inventory and migrate app passwords, OAuth apps and Apps Script before enrolment.
- Enrol every super and delegated admin and verify "Advanced Protection" shows On.
- Alert on Admin log events for Advanced Protection Program setting changes and on user unenrolments.
- Turn on Android Advanced Protection (with Intrusion Logging) or Lockdown Mode on high-risk users' phones.
- Run a lost-key recovery drill and document the out-of-band identity check.
- Extend guidance and keys to high-risk staff's personal Google accounts.
Standards and references
- Google: Advanced Protection Program
- Google Account Help: Get Google's strongest account security with Advanced Protection
- Google Workspace Help: Protect users with the Advanced Protection Program
- Google Workspace Help: Enable user enrollment in the Advanced Protection Program
- Google Workspace Help: Manage Advanced Protection Program user enrollment
- Android Help: Advanced Protection
- MITRE ATT&CK: Phishing (T1566)
- NIST: SP 800-53 Rev. 5 Security and Privacy Controls
Related NHI Mgmt Group resources: Personal Security for High-Risk Individuals Guide, Passwordless and Passkeys Guide, Hardware Security Keys Guide, Google Workspace Security Guide.