Google endpoint management decides which phones, tablets and computers can reach Gmail, Drive and the rest of Google Workspace, so the admins and automation that control it can approve, block or wipe every device in the organisation. This guide covers the customer-side settings in the Google Admin console: Basic and Advanced mobile management, device approvals, compromised device blocking, Context-Aware Access device levels, device management admin privileges, the Cloud Identity Devices API and its service accounts, device log events and a hardening baseline. It is written for Workspace administrators, endpoint teams and security reviewers. For tenant-wide Workspace controls such as 2-Step Verification for admins, see the Google Workspace Security Guide; for MDM principles across platforms, see the Mobile Device Management Security 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
- Choose Advanced management where licences allow. Basic management is on by default and needs no app; Advanced adds device approvals, encryption, restrictions, compromised device blocking, full wipe and device audit events.
- Require admin approval for new devices. Turn on Require admin approval under Security, Device approvals in Universal settings, and send the notification to a group of approving admins.
- Scope device admins to organisational units. Create a custom role with Services, Mobile Device Management, Manage Devices and Settings and assign it per OU rather than handing out super admin.
- Treat the Devices API service account as a privileged admin. It needs domain-wide delegation and acts as an impersonated administrator, so keep its scope to cloud-identity.devices and avoid downloaded keys where you can.
- Gate apps with device-based Context-Aware Access. Access levels using screen lock and minimum OS version stop unmanaged or outdated devices reaching data, but never assign them to the Admin console.
How identity and access work in Google endpoint management
Devices reach Workspace through a user's Google Account; endpoint management decides whether that account may sync on the device, and Context-Aware Access decides whether a request is allowed based on device state. Admins act through the Admin console with roles and privileges. Security is a shared responsibility: Google runs the platform, and the customer chooses the management level, approval rules, policies and who can change them.
| Management level | What it gives you | User impact |
|---|---|---|
| Basic mobile management | Password requirements, remote account wipe, Android managed apps, hijacking protection, device activity alerts | On by default; no app to install |
| Advanced mobile management | Device approvals, stronger passwords, encryption, device restrictions, compromised device blocking, full device wipe, iOS app management, Android work profile, device audit events | Users install the device policy app; one advanced-managed Google Account per device |
| Computer security | Device blocking, remote sign-out, endpoint verification, Context-Aware Access signals | Endpoint verification or Drive for desktop on the computer |
| Windows device management | Windows 10 and 11 settings, BitLocker, updates, Google Credential Provider for Windows (GCPW) | Enrolment through GCPW |
| Company-owned devices | Inventory by serial number, enrolment and management in one place | Pre-registered devices |
Set the level under Menu, Devices, Mobile and endpoints, Settings, Universal, General, Mobile management. Choose Basic, Advanced or Custom (per platform) and use Override and Inherit to set it per organisational unit. Advanced management for iPhones and iPads needs an Apple push certificate, renewed every year; without it the Advanced option is not available for iOS. Users need a licence that supports Advanced management, otherwise Basic settings apply to their devices.
Availability: Basic management is listed for most Workspace and Cloud Identity editions, including Cloud Identity Free. Advanced management is listed for editions such as Business Plus, Enterprise Standard and Plus, Frontline, Education Standard and Plus, and Cloud Identity Premium. Context-Aware Access, the security investigation tool and activity rules are listed for Enterprise Standard and Plus, Frontline Standard and Plus, Education Standard and Plus, Enterprise Essentials Plus and Cloud Identity Premium. Confirm your edition in Google's documentation.
Enrolment, approvals and device policy
Device approvals
- Setting: Require admin approval, under Security, Device approvals in Universal settings, applied per OU.
- Who it covers: Android and iOS devices under Advanced management, and computers with endpoint verification, fundamental management with Chrome signals sharing, or Google Drive for desktop.
- Pending devices: Users see a message that an admin must review the device before they can access work data. Approval is per device; approve individually or with a rule.
- Automatic approvals: Company-owned devices registered by serial number (except Android devices with a work profile), and company-owned devices running Drive for desktop when Drive for desktop is restricted to authorised devices, are approved automatically. Keep the inventory accurate, because inventory is now an approval decision.
- Alerts: Enter a group address of approving admins so requests are not missed.
Policy settings from Google's device management security checklist
| Control | Applies to | Setting or action |
|---|---|---|
| Require passwords | All mobile; type, strength and length with Advanced | Universal settings, password requirements |
| Require encryption | Advanced | Universal settings, encryption |
| Block compromised devices | Advanced | Stops work account sync on rooted Android or jailbroken iOS |
| Block non-compliant Android devices | Advanced | Device management rules that block and notify |
| Auto Account Wipe | Android, Advanced | Removes work data and managed apps after a set number of inactive days |
| Block risky Android apps | Android, Advanced | Block app installation from unknown sources: on; Allow users to turn off Google Play Protect: off |
| Device restrictions | Advanced | For example block USB file transfer on Android, block iOS backup to personal cloud |
| Endpoint verification | Computers | Turn on for device signals and Context-Aware Access |
| Drive for desktop | Computers | Restrict to company-owned devices in your inventory |
| Windows privileges | Company-owned Windows | Set users' administrative permission level and security settings |
Our recommendations for values, where Google's checklist leaves them open: a minimum six-digit device PIN or stronger, Auto Account Wipe after 30 days of inactivity for Android, and encryption required for every Advanced-managed device.
Context-Aware Access device levels
Create access levels from conditions such as screen lock and minimum iOS and Android versions on the Basic tab, then assign them to apps per OU with Apply to Google desktop and mobile apps checked. Several access levels on one app use OR logic; put conditions that must all hold into a single level. Assignments for large OUs can take up to 24 hours to apply. Google advises not to assign access levels to the Admin console, and Workspace-only admins should not edit access levels in the Google Cloud console. Customise the remediation message so blocked users know how to fix their device. See the Zero Trust Identity Guide for the wider model.
Admin roles and privileged access
Super administrators hold device management privileges by default. For everyone else, create a custom role under Account, Admin roles, Create new role, select Services, Mobile Device Management, Manage Devices and Settings, and assign it with an optional OU scope. If multi-party approval is on, another admin must approve the assignment, and the request expires after three days.
| Task | OU-scoped device admin | Our guidance |
|---|---|---|
| Review devices and device details | Yes, within assigned OUs | Help desk by region or business unit |
| Approve, block, delete and wipe devices | Yes, within assigned OUs | Same team; log wipes with a ticket |
| Apply mobile and endpoint settings | Yes, within assigned OUs | Endpoint engineers only |
| Device reports and log events, rules, web and mobile apps, Apple VPP, Apple push certificate | Top-level organisation admins | Small central team; certificate owner named with a renewal reminder |
| Advanced management for iOS | Super admin | Change control for any management level change |
- Protect admin accounts: Enforce 2-Step Verification with security keys for every account holding device privileges. A device admin can wipe the CEO's phone.
- Audit tool access: The Audit and investigation tool needs the Audit and Investigation administrator privilege; grant it to security analysts separately from device management.
- Apple push certificate: Create it with a shared, monitored Apple ID owned by the organisation, not a personal account. Google states that the yearly renewal needs the Apple ID used to create the certificate; without it you create a new certificate and iOS users re-register.
Integrations, API tokens and service accounts
The Cloud Identity Devices API manages Android, iOS and desktop devices, both personal and company-owned, and the user accounts on them. It can wipe devices, sign users out remotely, search devices and set custom state per user account for use in Context-Aware Access levels. Google documents the Devices API pattern as a service account with domain-wide delegation that impersonates an administrator, and audit logs record its actions as that administrator.
| Credential | Risk | Control |
|---|---|---|
| Service account with domain-wide delegation | Acts as an admin across the domain for the scopes granted | Grant only https://www.googleapis.com/auth/cloud-identity.devices in the delegation entry, and confirm any narrower scope in Google's current Devices API docs |
| Downloaded JSON service account key | Long-lived secret; Google flags keys as a security risk | Prefer keyless options; if a key is unavoidable, store it in a secrets manager and rotate |
| Impersonated admin user | Every API action is logged as this user | Dedicated admin identity with a device-only custom role |
| Third-party MDM or security connectors | OAuth grants to device data | Review under app access control and restrict to approved apps |
- Dedicated impersonation subject (ours): Create an admin account used only by the integration, give it the device-only custom role, and impersonate that account rather than a super admin. Domain-wide delegation scope and the subject's role together set the blast radius.
- Review delegation grants: List domain-wide delegation entries quarterly and remove unused client IDs. See How to audit Google Workspace domain-wide delegation grants and the Google Workspace Domain-Wide Delegation Security Guide.
- Keys: Follow the Google Cloud Service Account Keys Security Guide for key restriction and replacement.
Logging and detection
Device log events (Reporting, Audit and investigation) record device attributes such as compromised state, ownership changes, compliance state, failed unlock attempts (logged after more than five), setting changes such as developer options, unknown sources and USB debugging, and app installs when Android app auditing is on. Full mobile audit events need Advanced management. Export up to 100,000 rows to Sheets or CSV, or up to 30 million rows from the security investigation tool. Reporting rules create alerts and activity rules automate responses. Admin console changes to device settings appear in the Admin log events. See the Google Workspace Audit Log Detection Guide.
| Signal | Source | Response |
|---|---|---|
| Device compromised state changes to compromised | Device log events | Confirm compromised device blocking applied; contact the user |
| Device setting change: USB debugging or unknown sources on | Device log events | Check policy; treat as a possible tampering signal |
| Ownership change from personal to company owned | Device log events | Verify against inventory, since company-owned devices can be auto-approved |
| Bulk wipes or blocks by one admin | Admin log events | Confirm tickets; check the admin's sign-in |
| New domain-wide delegation entry or device role assignment | Admin log events | Two-person review |
Metrics: percentage of devices under Advanced management; devices pending approval for more than two working days; compromised or non-compliant devices with work sync still active; days until Apple push certificate expiry; accounts holding Manage Devices and Settings; Devices API delegation entries without a named owner.
Hardening baseline
- Inventory: Review Devices for all mobile and endpoint devices, add company-owned devices by serial number and note which OUs use Basic or Advanced.
- Pilot Advanced: Create the Apple push certificate with an organisation Apple ID, turn on Advanced for a pilot OU, and check the device policy app enrolment on each platform.
- Policies: Set password, encryption, compromised device blocking, Play Protect and unknown sources settings for the pilot, then add Auto Account Wipe and restrictions.
- Approvals: Turn on Require admin approval with a group alert address; approve existing devices first so users are not locked out.
- Context-Aware Access: Build a device level, assign it to one app for the pilot OU, read the results, then widen. Never assign it to the Admin console.
- Roles and API: Replace super admin use with OU-scoped device roles; restrict Devices API delegation to the devices scope and a dedicated subject.
- Roll out by OU: Expand ring by ring. To roll back, set the OU to Inherit or back to Basic; note that Android devices moved from Advanced to Basic may only support full device wipe.
Small organisations can run Basic management with 2-Step Verification and a short approved-device list. Larger estates should run Advanced, approvals, Context-Aware Access and OU-scoped admins, with alerts flowing to the SOC.
Common misconfigurations
- Basic management left as the only control: Approvals, compromised device blocking and full audit events need Advanced. Move sensitive OUs to Advanced first.
- Apple push certificate on a personal Apple ID: Renewal needs that Apple ID and its password, so plan for the owner leaving. Use an organisation Apple ID.
- Access level assigned to the Admin console: Google advises against it; keep device conditions on user-facing apps.
- Stale company-owned inventory: Registered serial numbers are auto-approved. Remove sold or recycled devices.
- Devices API impersonating a super admin: The integration inherits full tenant rights. Impersonate a device-only admin.
- Approval alerts to one person: Requests stall during leave. Use a group address.
Framework mapping
| Control | NIST SP 800-53 Rev 5 | CIS Controls v8.1 |
|---|---|---|
| Device inventory and approvals | CM-8 System Component Inventory | Control 1 |
| Password, encryption and restrictions | AC-19 Access Control for Mobile Devices, CM-6 | Control 4 |
| OU-scoped device admin roles | AC-6 Least Privilege | Control 5 and 6 |
| Devices API service account and delegation | AC-2, IA-5 | Control 5 |
| Device log events and alerts | AU-2, AU-6, SI-4 | Control 8 |
Practitioner checklist
- Move sensitive OUs to Advanced mobile management and create the Apple push certificate with an organisation Apple ID.
- Turn on Require admin approval with a group alert address.
- Require passwords and encryption, and block compromised devices.
- Turn on unknown sources blocking and keep Google Play Protect on for Android.
- Turn on endpoint verification and restrict Drive for desktop to company-owned devices.
- Assign device admin rights through OU-scoped custom roles and protect them with security keys.
- Limit Devices API delegation to the devices scope and a dedicated admin subject.
- Apply device-based Context-Aware Access levels to apps, never to the Admin console.
- Alert on compromised state, risky setting changes and bulk wipes.
Standards and references
- Google: Overview, Manage devices with Google endpoint management
- Google: Set up advanced mobile management
- Google: Require admin approval for device access
- Google: Device management security checklist
- Google: Assign device management administrator privileges
- Google: Renew an Apple push certificate
- Google: Device log events
- Google: Context-Aware Access device policy enforcement
- Google Cloud: Setting up the Devices API
Related NHI Mgmt Group resources: Mobile Device Management Security Guide · Google Workspace Security Guide · Google Workspace Security Checklist · Google Workspace Domain-Wide Delegation Security Guide