Implementation Guide to Securing Google Workspace With Zero Trust
Target Audience
Google Workspace Security Administrators, Cloud Identity Architects, and Systems Security Engineers.
The Problem
The right password doesn’t make every sign-in safe.
An employee passes MFA and signs in to Google Workspace. But what if they’re using a personal laptop that hasn’t been updated in months? Or someone has taken over their session? Signing in is only part of the story. To protect company data, you also need to know what device someone is using, where they’re connecting from, and whether that access should be allowed.
The Zero Trust Solution
Google Workspace’s Context-Aware Access (CAA) lets you set access rules based on more than a password and MFA. You can take into account the device someone is using, whether it meets your security requirements, and where they’re connecting from. For example, you could require an encrypted device or block access from certain locations. These rules help you control access to apps like Gmail and Google Drive, including Google Admin console even when someone has the right credentials.
What the End-User Experience Looks Like
For most employees using a compliant company device, Context-Aware Access is nearly invisible. They sign in normally, complete multi-factor authentication, and continue into Gmail, Drive, or another approved application without an additional prompt.
If a device does not meet the policy, the experience depends on the configured action:
Monitor mode: Access continues normally while the potential violation is recorded for administrators.
Warn mode: The user sees a warning explaining that the device or request does not meet company requirements but may be allowed to continue.
Block mode: Access is denied. The user sees Google’s default message along with any remediation instructions and custom help message configured by the organization.
A blocked user might be asked to switch to a company device, enable encryption or screen protection, update the operating system, activate Endpoint Verification in Chrome, or enroll a mobile device in Google endpoint management. Access is restored only after the device becomes compliant and its updated status synchronizes with Google, so remediation may not take effect immediately.
Key Concepts to Understand Before Implementation
Decoupled Posture Signals
To ensure proper architectural planning, administrators should note how Google Workspace separates network-level and device-level indicators:
Network-Level Context (IP & Geo-location)
Google evaluates the requesting client's IP address and IP-derived geographic location natively from incoming TCP/connection headers at the Google Frontend (GFE) layer. This analysis is agent-less and does not require Endpoint Verification or Chrome.
Device-Level Posture (Desktop Windows, macOS, Linux, ChromeOS)
Posture telemetry relies on client-side validation. Google documents support primarily through Google Chrome with the Endpoint Verification extension (and compatible Chromium-based browsers like Microsoft Edge that support the extension) and through Drive for desktop. Desktop browsers or native applications that do not utilize Chrome with the Endpoint Verification extension (or Drive for desktop) cannot report local hardware metrics (encryption, management status, OS version) and will generally fail device posture checks by default. Relying on Edge for automated posture evaluation can lead to unpredictable enforcement or lack of support if a ticket is opened with Google Workspace Support. It is safer to mandate Google Chrome for all enterprise desktop endpoints.
Device-Level Posture (Mobile iOS, Android)
Posture verification runs natively via MDM profiles enrollment configured through Google Endpoint Management (MDM).
Access Control vs. Data Protection (Downloads)
Administrators should distinguish between application access control and data-level extraction controls (downloads/shares). Context-Aware Access determines whether a user can open and run a Google application (like Drive or Gmail). It does not block file downloads once access to the application is authorized. Restricting file downloads, copying, or printing requires separate Data Loss Prevention (DLP) policies and Information Rights Management (IRM) controls.
App vs. API Enforcement Separation: Blocking the Gmail or Drive application under Context-Aware Access does not automatically block programmatic API access to their underlying data. A third-party application or custom script with approved OAuth scopes can still query Gmail or Drive APIs even if browser access is locked down by CAA rules. To establish a more comprehensive access control framework, administrators should assess and configure API access paths separately.
Pre-requisites & Licensing Scope:
Supported Editions: Context-Aware Access is available to users assigned one of the following licenses:
Google Workspace Enterprise Standard or Enterprise Plus
Google Workspace Enterprise Essentials Plus
Google Workspace Education Standard or Education Plus
Google Workspace Frontline Standard or Frontline Plus
Cloud Identity Premium
Licensing Alignment Warning: Only users with supported licenses are subject to Context-Aware Access policies. Unlicensed users in an assigned Google Workspace organizational unit or configuration group will bypass enforcement, allowing them to connect from unmanaged, unencrypted devices.
Administrator Privileges: A super administrator profile, OR a Delegated Administrator role assigned the Security > Data Security privilege combined with Directory > Users > Read rights to assign policy targets across Google Workspace organizational units or configuration groups.
Zero Trust Topology for Google Workspace Context-Aware Access
Implementation Plan (Step-by-Step)
Step 1: Secure License Alignment
Verify that all target users hold a valid, supporting license (such as Enterprise Standard/Plus, Enterprise Essentials Plus, or Cloud Identity Premium) to prevent security bypass issues before configuring policies. Unfortunately, you can only view license information at the individual level so here are your options depending on how large the group or org is:
a. In the Google Admin Console, verify license per user
View Individual Assignments:
Go to Directory > Users. Click the user's name to open their account page. Scroll down to the Licenses section to see their current assignment.
To review in bulk a large volume of users, Go to Directory > Users then click 'Download users' at the top to export a CSV file containing license information for all users.
Review the Licenses [READ ONLY] column in the exported spreadsheet to confirm each user's assigned license.
View users in a Group:
Go to Directory > Groups, hover over the group role and click 'manage group'
Click the user's name to open their account page. Scroll down to the Licenses section to see their current assignment.
b. If any users have unsupported licenses, upgrade their subscription or relocate them to ensure policies apply uniformly.
Step 2: Populate the Company-Owned Device Inventory
Google determines company ownership from the organization’s company-owned device inventory. Required device serial numbers must be uploaded or otherwise present in that inventory.
1. Collect the verified hardware serial numbers for your corporate desktop, laptop, and mobile fleets.
2. In the Google Admin Console, navigate to: Devices > Mobile & endpoints > Company-owned devices.
3. Click the Import company-owned devices button.
4. Select your device category (Computer or Mobile), download the recommended template, and upload your list of serial numbers via a formatted CSV file.
5. Alternatively, configure automated sync tools so serials are automatically present in your inventory (e.g., Apple Business Manager, Android Zero-touch enrollment, or ChromeOS Zero-touch enrollment).
6. Why this is mandatory: If you enforce a company-owned restriction (device.iscompanyowned == true), CAA will cross-reference the client device serial number reported by Endpoint Verification against this list. If the serial number is missing from the inventory, the device is evaluated as personal/unmanaged and blocked.
Step 3: Configure Endpoint Telemetry and Management Systems
Depending on your fleet's profile, choose and deploy the appropriate telemetry components:
1. For Agentless Network Controls (IP or Geographic Boundaries):
No workspace device configuration or client agents are required. Go straight to Step 4.
2. For Mobile Devices (Google Endpoint Management):
Navigate to: Devices > Mobile & endpoints > Settings > Universal settings.
a. Click on the first section called General
b. Verify mobile management is enabled (Basic or Advanced) for iOS and Android platforms to pull native client compliance values. Just looking to make sure it is enabled. How to turn on Basic https://knowledge.workspace.google.com/admin/devices/set-up-basic-mobile-device-management
3. The goal of this step is to enable Endpoint Verification for your organization so that Google Workspace can collect device attributes, security states, and signals (such as OS version, encryption status, and screen lock status) from desktop browsers (Chrome and Microsoft Edge).
a. For Desktops utilizing Chromium-Based Browsers (Chrome or Microsoft Edge):
Navigate to: Devices > Mobile & endpoints > Settings > Universal settings > Endpoint verification.
a. Check Monitor which devices access organization data. Click Save.
Deploy the Endpoint Verification Extension (id: kglclbjooolbidcombeddopnfacgmegh) and the native OS helper installer (.msi/.pkg) across your fleet via Group Policy, Microsoft Intune, Jamf, or equivalent deployment tools.
4. For Native Client Applications (Drive for Desktop):
Deploy Drive for Desktop on corporate Mac and Windows systems. Drive for Desktop natively queries and passes platform posture attributes to the Google Gateway, permitting native file-syncing and local mounting under CAA protections without requiring standard browser-level extensions.
Step 4: Author the Zero Trust Access Level (Advanced CEL Mode)
Goal: Create one access policy that defines the device and connection requirements for accessing company applications. Using Common Expression Language (CEL), require company ownership, administrator approval, encryption, and screen-lock protection; define allowed operating systems and desktop minimum versions; and require an approved corporate public IP address or geographic location.
1. In the Google Admin Console, navigate to: Security > Access and data control > Context-Aware Access > Access Levels.
2. Click Create Access Level.
3. Fill in the identifying fields:
Access level name: ALUnifiedZeroTrust_Policy
Description: Demands local platform disk encryption and minimum OS versions (macOS 14+ or Windows 10+) for company-owned desktops, mobile compliance enrollment, or approved corporate IP networks.
4. Select the Advanced editor radio button and the CEL definition below. Source documentation found here https://docs.cloud.google.com/access-context-manager/docs/custom-access-level-spec
Before pasting the code below, replace these pieces:
1. Replace 192.0.2.0/24 with your real public IP range.
2. Save it in Advanced mode, then assign it in Monitor for testing. Google’s access-level instructions
3. Confirm the intended behavior: a compliant device anywhere in the US can pass, including on a home network. All device requirements still apply.
The Android/iOS checks identify the OS; they do not independently check enrollment. Your Windows 10 minimum is preserved here as requested by the existing logic, not validated as a current security baseline.
// Require company ownership.
device.is_corp_owned_device == true &&
// Require approved device status.
device.is_admin_approved_device == true &&
// Require screen-lock protection.
device.is_secured_with_screenlock == true &&
// Require storage encryption.
device.encryption_status == DeviceEncryptionStatus.ENCRYPTED &&
// Allow the operating systems below.
// Linux and ChromeOS are excluded.
(
// macOS 14.0.0 or later.
(
device.os_type == OsType.DESKTOP_MAC &&
device.versionAtLeast("14.0.0")
) ||
// Windows build 10.0.19045 or later.
(
device.os_type == OsType.DESKTOP_WINDOWS &&
device.versionAtLeast("10.0.19045")
) ||
// Android must also meet all shared device requirements.
device.os_type == OsType.ANDROID ||
// iOS and iPadOS must also meet all shared device requirements.
device.os_type == OsType.IOS
) &&
// Require an approved corporate public IP OR an allowed country.
(
// Replace this example with your actual public IP range.
inIpRange(origin.ip, ["192.0.2.0/24"]) ||
// Allow connections geolocated to the United States.
origin.region_code in ["US"]
)
Click Create.
Tip for deployment: Ensure that your subnet definitions (inIpRange) do not include private RFC 1918 home network spaces (like 192.168.x.x or 10.x.x.x) as public IPs, since GFE evaluates the client's public connection IP origin rather than local behind-the-router private subnets.
Step 5: Map Policies & Configure the Assignment Procedure
Bind your Custom Access Level to targeted Google Applications, selecting your deployment stage, warning actions, and endpoint scopes.
1. In the Google Admin Console, navigate to: Security > Access and data control > Context-Aware Access > Assign access levels to apps.
2. Select your target Google Workspace organizational units or configuration groups (e.g., OU=ZeroTrust-Pilot-Group) on the left panel tree.
3. Select your core communication environments: Drive and Docs, Gmail, Google Admin Console
4. Click Assign in the top navigation panel.
5. Identify your Access Level created in the previous steps: ALUnifiedZeroTrust_Policy.
6. Select the assignment state (Monitor vs. Active):
Keep in mind that assigned access levels are placed in Monitor mode by default. Google recommends evaluating policies in Monitor mode to capture log events and analyze behavior prior to active enforcement. Testing in Monitor mode for at least one week is highly recommended to identify potential impact on user productivity. https://support.google.com/a/answer/9275380?hl=en
a. During Testing Phase (First 7 Days): Leave the default setting on Monitor mode. This allows the gateway to record and audit endpoint violations to the logging panels without dropping any user traffic. DO NOT NOT SKIP TESTING.
b. During Production Phase (Staged Go-Live): Toggle this configuration to Active to begin conditional enforcement where evaluated requests are constrained by the active policy state.
7. SELECT THE ASSIGNMENT ENFORCEMENT ACTION (Warn or Block):
Specify how non-compliant requests are treated when matching violations occur under Active mode:
a. Warn: Prompts non-compliant users with a custom posture warning, while letting them choose to bypass and proceed. Useful as an intermediate rollout step.
b. Block: Restricts authenticated sessions that do not meet the specified posture requirements, preventing utility path connections until security criteria match.
8. SELECT THE APPLICATION PATHWAY SCOPE:
Select the checkbox Apply to Google Workspace desktop and mobile apps. This extends policy validation from web browsers to native desktop sync clients (like Drive for Desktop), native email apps, and programmatic API contexts. If unchecked, compliance is strictly checked at web-browser portals.
9. Click Save and confirm the safety alert box.
Step 6: Assess and Explicitly Configure API Controls (Preventing API Bypass)
Limit Gmail and Drive API access to approved applications and explicitly apply Context-Aware Access requirements to covered API requests.
Blocking access to Gmail or Drive does not automatically block other applications from accessing their data through APIs. Configure both OAuth app permissions and CAA API enforcement. Google’s API enforcement guidance
Open API Controls.
In the Google Admin console, navigate to Security → Access and data control → API controls.
Review application access.
Click Manage App Access. Review configured and accessed applications.
Identify and assess integrations.
Find third-party applications and internal scripts requesting Gmail or Drive permissions. For each integration, record its owner, business purpose, OAuth client ID, and required scopes. Confirm which integrations must remain operational.
Restrict service access.
Under Manage Google Services, select Gmail and Drive, then choose Change access → Restricted after configuring required integrations.
Restricted services permit apps configured as Trusted or Specific Google data. Review any option allowing untrusted apps to request lower-risk scopes; leave it disabled if your policy requires explicit approval.
Important: Restricting services can interrupt existing integrations and revoke tokens. Test required workflows before broad deployment. Google’s API Controls instructions
Approve required integrations and verify CAA enforcement.
Prefer Specific Google data to limit approved integrations to necessary scopes. Use Trusted only when broader access is justified. Trusted status does not establish device compliance.
Return to Security → Access and data control → Context-Aware Access and edit the Gmail and Drive assignments. Under Policy settings, enable the separate option that blocks other apps from accessing selected apps through APIs when access levels are not met. The desktop/mobile-app setting alone does not enable API enforcement.
Review explicit API exemptions carefully. Test both an approved integration that should work and a request that should be denied before enabling broad enforcement. Google’s CAA assignment instructionsBecause app-level blocking does not inherently block background programmatic calling of Gmail/Drive API scopes, you must lock down third-party and custom OAuth scopes.
Step 7: Configure the Additional Custom Remediation Message
Help manage helpdesk volumes by displaying helpful messaging to non-compliant users when they encounter access challenges.
Help users resolve access issues and reduce help-desk requests.
In the Google Admin console, navigate to Security → Access and data control → Context-Aware Access → General settings.
In Additional custom message, enter the following. Replace the example help link with your organization’s URL:
Your device or connection does not meet company access requirements.
Follow the instructions shown on this page.
Desktop: Use Google Chrome with Endpoint Verification enabled. Confirm your company device is approved, encrypted, protected by a screen lock, and running an approved OS version.
Drive for desktop: Sign in with your work account. Your device must also meet company security requirements.
Mobile: Use an approved company device enrolled in Google endpoint management, with encryption and a screen passcode enabled.
Connection: Connect from an approved network or allowed location.
After making changes, sync your device information and try again. Updates may take time.
For help, visit IT access instructions.
Click Save.
Step 8: Validate the Post-Authentication Posture Boundary
Test 1: Monitor Mode Log Auditing (First Week Validation)
1. Navigate to: Reporting > Audit and investigation > Context-Aware Access log events.
2. Execute log queries tracking user session attributes inside your pilot group.
3. Observe evaluation event attributes, such as:
Evaluation Result: Track occurrences recorded under states such as Access Denied, Access Evaluated, or Access Warned.
Satisfied Access Levels / Unsatisfied Access Levels: Cross-reference these lists to pinpoint which endpoints are successfully resolving your ALUnifiedZeroTrust_Policy versus those returning unsatisfied outcomes.
Device State Signal Metrics: Audit device state parameters reported natively by the helper agents or Drive for Desktop.
Test 2: Active App Access Test using Compliant Environments
1. Turn off your corporate network connection and switch to a home broadband network or cellular hotspot (outside of the corporate IP subnet).
2. Accessing with Chromium (Chrome/Edge) with Endpoint Verification active:
Open Gmail/Drive.
Expected Result: Access should be granted after the required device signals have synchronized.
3. Accessing with Drive for Desktop:
Launch Drive for Desktop on macOS or Windows and run a sync task.
Expected Result: POST queries succeed; files sync with native mount points, and access should be granted after the required device signals have synchronized.
4. Accessing with an unmanaged browser (Safari / Firefox):
Attempt to open Gmail or Drive from Safari or Firefox on an unmanaged, personal computer or from a device without Endpoint Verification installed.
Expected Result: Access is blocked and the configured default, remediation, and custom messages are displayed. (Because basic CAA device posture does not analyze Safari or Firefox natively on desktops).
Test 3: API Protection Bypass Test
1. Attempt to run a custom API Python script or use an unapproved third-party backup tool to query Google Drive scopes using an OAuth token generated for a pilot user account.
Expected Result: The API call is immediately rejected with an unauthorized_client or programmatic OAuth block error, validating that Step 6 successfully restricted raw API bypass attempts.
Operational Governance, Security & Best Practices
Standardize on Primary Core Channels (Chrome & Drive for Desktop)
Avoid relying on unmanaged browser pathways. Basic CAA deployment processes rely fundamentally on Chrome with Endpoint Verification or specialized Google-distributed native OS clients (Drive for Desktop). Restrict alternative browser routes by policy to ensure unified telemetry ingestion.
Audit Policy Activity with Documented Log Fields: Avoid relying on unlisted or guessed JSON keys. Standard Google Workspace Context-Aware Access logs document structural authorization conditions through properties tracking whether a request was Denied or Evaluated, lists of satisfied and unsatisfied access levels, and specific device state parameters returned by active endpoints. Base your triage spreadsheets on these validated criteria.
Staged Rollout Methodology
Deploy newly engineered CAA rules using a progressive enforcement curve. Standard recommendations follow these specific phases:
Phase 1: Assign the policy in Monitor mode to a pilot OU or configuration group for at least one week. Review Access Denied (Monitor mode) events before activating enforcement.
Phase 2: Transition to Warn Mode. Introduce soft-posture validation gates, allowing administrators to alert off-posture end-users about missing helper tools, unencrypted partitions, or outdated OS versions without dropping operational access.
Phase 3: Transition to Active Block Mode. Transition rules to Active/Block mode once evaluated telemetry logs settle to compliant margins.
Distinct Data-Protection Controls (Preventing Downloads): Keep in mind that Context-Aware Access is strictly an application entry gate. If a user connects via a compliant corporate desktop and gains access to Google Drive, CAA does not police whether they can download files. To explicitly prevent users from downloading, printing, or copying files within Drive, administrators must author separate Google Workspace Data Loss Prevention (DLP) scripts and Information Rights Management (IRM) parameters located in the Admin Console under Security > Access and data control > Data protection.
Establish a Secured Break-Glass Account: It is highly recommended to maintain a dedicated Super Admin configuration account excluded from Context-Aware Access device policies, secured with standard hardware-backed FIDO2 security keys, to help avoid accidental domain lockouts during global configuration updates.
Standardize this now!