Security
Zero trust for Google Workspace
Zero trust on Google Workspace is delivered through Context-Aware Access policies that evaluate device state, location and IP on every request, combined with managed-device requirements and session length limits. Context-Aware Access needs Enterprise Standard or above, and a staged rollout across 3 phases avoids locking out the administrators who wrote the policy.
| Licence | Enterprise Standard+ or Cloud Identity Premium |
|---|---|
| Signals | Device state, IP range, geography, OS version |
| Enforcement scope | Per app, per access level, per org unit |
| Break-glass | 1 excluded super admin, hardware key only |
| Rollout | 3 phases: monitor, pilot group, enforce |
| Typical timeline | 6 weeks for 200 seats |
Access levels are the building block
An access level is a named set of conditions — corporate IP range, encrypted disk, screen lock enabled, minimum OS version, approved geography. Levels are defined once and then attached to applications for particular org units, which is why the modelling work matters more than the console work.
Model the levels around how people actually work rather than around an ideal. A field engineering team on cellular connections cannot satisfy a corporate-IP condition, and writing one anyway produces a helpdesk queue rather than security. Two or three well-chosen levels usually cover an organisation; a dozen produces conflicts nobody can reason about.
- Baseline: any device, 2FA enforced, no geographic restriction
- Standard: company-managed device with disk encryption and screen lock
- Sensitive: managed device plus approved country plus recent OS
- Admin: managed device plus hardware security key
Device trust comes before policy
A policy that requires a managed device is meaningless until devices are enrolled and reporting state. Endpoint management enrolment therefore runs first, and the policy phase does not begin until enrolment coverage is above ninety-five per cent with a named owner chasing the remainder.
Personal devices are the awkward case. Basic mobile management covers most needs without agent installation, and where staff decline enrolment the honest answer is a reduced access level rather than an exception that quietly bypasses the model.
Three phases, and the break-glass account
Phase one runs every policy in monitor mode and reports what would have been blocked. Phase two enforces for a volunteer pilot group of ten to twenty users drawn from different teams. Phase three enforces by org unit on a published schedule with a support window staffed for the first two days of each wave.
Before any of that, a break-glass super-admin account is created, excluded from all context policies, secured with two hardware keys held separately, and tested. It is the difference between a bad afternoon and an unrecoverable tenant, and it takes fifteen minutes.
What zero trust does not cover
Context-Aware Access evaluates the conditions of a request. It does not know whether the person holding a compliant, enrolled, correctly located laptop is the employee or someone who has taken their session. Session length limits and reauthentication on sensitive applications narrow that window but do not close it.
Nor does it help with data already exported. A user who satisfies every condition can still download a shared drive to a managed laptop and take it with them, which is a data-loss-prevention and offboarding problem rather than an access one.
What we see that others don't say
The first serious zero-trust incident in most tenants is self-inflicted: a policy requiring a company-managed device is applied to the admin group before the admins' own laptops are enrolled, and the only route back is a break-glass account that nobody created.
What this doesn't cover
- Context-Aware Access needs Enterprise Standard or above. On Business editions we deliver 2FA enforcement, session controls and app allowlisting, and say plainly what is unavailable.
- Zero trust does not remove the need for offboarding discipline; a compliant device belonging to a leaver is still compliant until the account is suspended.
- We do not deploy third-party ZTNA appliances or VPN replacements; scope here is Google-native controls.
- Policies that block legitimate work get switched off within a week. We design for what people actually do rather than for an ideal published architecture.
Get a fixed price for this
Send your seat count, current platform and deadline. You get a fixed price and an available cutover date, usually within one working day, from the engineer who would run the work.
Prefer to talk? Call +44 20 7183 3436 (Mon–Fri 08:00–18:00 GMT), or message WhatsApp +44 7403 423563.
Questions we get asked
- Do we need Enterprise for zero trust on Workspace?
- For Context-Aware Access, yes — Enterprise Standard or above, or Cloud Identity Premium. Business editions still support 2FA enforcement, session length limits and application allowlisting.
- How long does a zero-trust rollout take?
- About six weeks for two hundred seats, most of which is device enrolment and pilot feedback rather than console configuration.
- What happens if a policy locks everyone out?
- The excluded break-glass super admin, secured with hardware keys, restores access. Creating and testing it is the first task of the engagement, before any policy is written.
How this page is verified
Reviewed by Workspace Migration Services security desk, Workspace security and compliance reviewers. Last checked .
- Context-Aware Access edition requirements reflect Google Workspace Admin Help as published on 2026-08-06.
- Rollout phasing and timelines reflect Workspace Migration Services deployments completed to 2026-08-06.
- Break-glass practice follows Google's documented super-admin recovery guidance.
Sources you can check
Cite this page
Free to reuse with attribution. Copy whichever form your publication needs.
Plain citation
Workspace Migration Services, "Zero trust for Google Workspace", https://workspacemigration.services/security/google-workspace-zero-trust (last checked 2026-08-06).HTML with source link
<p>Context-Aware Access on Google Workspace requires Enterprise Standard, Enterprise Plus, Education Standard, Education Plus or Cloud Identity Premium; it is not available on Business editions. Source: <a href="https://workspacemigration.services/security/google-workspace-zero-trust">Zero trust for Google Workspace</a> — Workspace Migration Services.</p>Embed this table
<table>
<caption>Zero trust for Google Workspace — Workspace Migration Services, 2026-08-06</caption>
<tr><th>Licence</th><td>Enterprise Standard+ or Cloud Identity Premium</td></tr>
<tr><th>Signals</th><td>Device state, IP range, geography, OS version</td></tr>
<tr><th>Enforcement scope</th><td>Per app, per access level, per org unit</td></tr>
<tr><th>Break-glass</th><td>1 excluded super admin, hardware key only</td></tr>
<tr><th>Rollout</th><td>3 phases: monitor, pilot group, enforce</td></tr>
<tr><th>Typical timeline</th><td>6 weeks for 200 seats</td></tr>
</table>
<p><a href="https://workspacemigration.services/security/google-workspace-zero-trust">Zero trust for Google Workspace</a> — data maintained by Workspace Migration Services.</p>Related pages
Stage a zero-trust rollout
Break-glass first, enrolment second, monitor mode third, and enforcement on a published schedule. Six weeks for two hundred seats, with a staffed support window.