Say a 14-person property management firm. Everybody reads work mail on their own phone, which nobody ever sat down and agreed to, and the device list in the Admin console shows 31 entries: two phones belonging to people who left last year, a tablet nobody recognises, and the same iPhone three times because its owner reset it twice. Nobody there believes it is managed, because nobody was asked to install anything.
That belief is the useful mistake. Google endpoint management started collecting those devices the day the first person added a work account, and its basic layer is on by default. What is missing is not management. It is the two or three decisions that turn an inventory into a boundary. Here is the order we work in, with Google's guidance read on 14 October 2026.
What you already have, whether you switched it on or not
Basic mobile management is enabled by default and needs nothing installed on anyone's phone. Google's comparison of the management levels gives it four jobs: basic passcode enforcement, remote wipe of the work account, app management on Android, and details about every device carrying a work account. Password requirements live under Devices, then Mobile and endpoints, then Settings, then Universal. Laptops run through a separate system, endpoint verification, and a rule written for one does not cover the other.
Two consequences matter for a small team. Under basic management every device is approved the moment it appears, so blocking one is a manual action after the fact. And the inventory is already evidence: before we touch a setting we sort it by last sync and ask who each entry belongs to. Half the work on a first engagement is deleting the answer "nobody".
What we check before changing a level
- The edition each person holds. Advanced mobile management is licence-gated per user, so the answer can differ inside one company with mixed plans.
- The device list itself. Platform, operating system version, last sync, state. It tells you whether a policy lands on 12 phones or 31.
- The organisational unit layout. The level is set per organisational unit, and separately for Android and iOS, so the units have to mean something first.
Basic or advanced, decided by what you need to be able to do
Advanced mobile management adds stronger passcode and security policy enforcement, device approvals, remote wipe of the whole device rather than only the account, app management on iOS, and work profiles on Android. It also cannot co-exist with another enterprise mobility management provider, so a half-finished deployment from two years ago gets resolved first. The price is a management client on the phone: on iOS the Google Device Policy app plus a configuration profile, which Google documents as always required on iOS 13 and later, and on Android the Android Device Policy agent, accepted through the prompts on screen rather than installed by hand. A personal Android device under advanced management must set up a work profile to reach work data, and that is not optional for either side.
The licence question decides this more often than the feature list does. Google's setup page lists advanced mobile management on Business Plus, Enterprise Standard and Plus, Frontline, Education Standard and Plus, Enterprise Essentials and Essentials Plus, the older G Suite plans and Cloud Identity Premium. Business Starter and Business Standard are not on it, and Google is explicit about the failure mode: turn advanced management on for a user whose licence does not support it and only basic settings apply to that user's devices. The switch flips, the policy does not arrive, and nothing announces it.
Because the level is set per unit and per platform, a mixed answer is often the right one: company iPhones under advanced management, personal Android phones left on basic. On iOS, enrolment type is its own decision, and on a phone the employee bought it is the whole conversation. Device Enrollment is the default and gives the organisation full control including the ability to wipe everything on the device. User Enrollment keeps work and personal data separate.
One trap on the way back down: moving a user from advanced to basic does not unmanage their phone. Google documents that the device stays managed through the Device Policy app until the user factory resets it, or removes the work profile on Android, and that only basic policies are enforced in the meantime. Plan a downgrade as a user-facing task, not a toggle.
What admin approval blocks, and what it does not
This is the setting small teams ask for by name, usually as "I want to approve new phones before they get the mail". It exists, under Devices, then Mobile and endpoints, then Settings, then Universal, then Security, then Device approvals, where you tick the box to require admin approval and give an address to notify. Setting it needs the mobile device management administrator privilege, one of the prebuilt roles worth handing out instead of super admin.
Admin console
Devices
Mobile and endpoints
Settings
Universal
Security -> Device approvals
Data access -> Android sync / iOS sync
Two preconditions: device approvals for Android and iOS require advanced mobile management, so the licence question comes first, and company-owned devices you registered by serial number are approved automatically, except for Android devices with a work profile.
Now the part that surprises people. Approval gates the work data on that device, and Google states plainly that requiring it does not stop the person reaching other Google data unless you also create a Context-Aware Access policy that blocks access based on the pending approval status. A phone sitting in your approval queue can still open Gmail in the browser. If the point was to keep an unapproved device away from company mail, approval on its own does not finish the job.
The closing move is a Context-Aware Access level carrying the device policy condition that admin approval is required, assigned to Gmail and Drive in block mode. Check the edition before promising it. Google's main Context-Aware Access page lists Frontline Standard and Plus, Enterprise Standard and Plus, Education Standard and Plus, Enterprise Essentials Plus and Cloud Identity Premium, and Business Plus is not on it, while other Google pages on app access protection do mention Business Plus. We verify that in the tenant rather than quote either page at a client. Where Context-Aware Access is not available, approval is a notification and a record, not a gate.
Give the attributes time: Google warns that enforcing a device policy before the device has reported in can deny access to a user who meets it, and that under basic management the operating system version and encryption status can take a few days to sync.
A blunter lever sits beside it: under Data access, clearing the Android or iOS sync checkbox stops work data in Google apps such as Gmail, Calendar and Drive, and Google notes that browser access to web apps still works. On mobile, the browser is the hole in almost every control.
The phones endpoint management will never see
A mail client signed in with an app password is not a managed device and never appears as one. Neither is the warehouse scanner that sends through SMTP, or the CRM that mails invoices for you. Google has been moving third-party access to OAuth, lists app passwords as the remaining exception and does not recommend them for most uses, and it retired the password-based mail accounts that used to be pushed through mobile management. The control that matters here is not in the device menus: it is the POP and IMAP settings, where you can restrict users to OAuth mail clients only.
These are also the senders that outlive the person who set them up, which makes them a deliverability problem as much as an access one. We check both sides the same day: which devices hold a work account, and which systems are authorised to send mail using the domain. The second half is a DNS question you can run yourself in about thirty seconds.
Account wipe or device wipe
Wipes run from Devices, then Mobile and endpoints, then Devices, where each entry offers Wipe Account and Wipe Device. On a personal device with a work profile, an account wipe removes the work profile and its data and leaves personal data alone, which is what you want for a departure. On a company-owned Android both options factory reset the phone. Three details save arguments later:
- Deleting is not wiping. Google states that removing a device from the list does not remove work data from it, except on iOS. The entry disappears, the mail does not.
- A device that was under advanced management may only support a full wipe. On basic now but advanced before, account wipe can be unavailable and the whole phone is the only option.
- Blocking is reversible and visible. It stops the device reaching a managed account and prevents further access requests, and blocked devices stay in the list until you delete them. Unblocking behaves like approving.
Departures are where this gets tested, so it runs inside the offboarding checklist rather than as a separate job: suspend, wipe the account from each listed device, delete the stale entries.
What we watch afterwards
- The approval queue. A queue nobody reads is worse than no approval requirement, because it looks like a control. The notification address should reach two people.
- Stale entries and old operating systems. A last sync months old is usually a lost phone, a reset, or somebody who left, and the inventory is the only place most small companies see that four phones stopped getting security updates.
- The day a licence changes. Moving a user to a plan that does not support advanced management quietly drops them to basic policies. Plan edition changes and device management together, not six weeks apart.
- Who holds the groups. Where policies are targeted through groups rather than units, the membership is the policy, which is why groups are an access boundary.
How Guanacos Tech helps
We do this as part of Workspace work for small and mid-sized teams across North America and Latin America: read the device list with you, check what each licence actually supports, pick basic or advanced per platform, set approvals with a policy behind them rather than only a notification, and write down what happens the day somebody loses a phone. For a team of ten to thirty it is an afternoon, and it closes the gap between what the console shows and what is true. How we work fits on one page. If you would rather have it done than researched, we are Google Workspace consultants, and half an hour is enough to say what we would change first.
Sources
- Google Workspace Admin Help: Compare mobile management features
- Google Workspace Admin Help: Set up advanced mobile management
- Google Workspace Admin Help: Require admin approval for device access
- Google Workspace Admin Help: Apply universal settings for mobile devices and endpoints
- Google Workspace Admin Help: Approve, block, unblock, or delete a managed device
- Google Workspace Admin Help: Protect your business with Context-Aware Access
- Google Workspace Admin Help: Wipe corporate data from a device
- Google Workspace Admin Help: Switch device management before downgrading