How to Configure Google Workspace Context-Aware Access using BeyondCorp

The Death of the VPN

For decades, enterprise security relied on a simple perimeter model: the VPN. If you were inside the corporate network (or tunneled in via VPN), you were trusted. If you were outside on the public internet, you were untrusted. This model broke when the entire workforce shifted to remote work and cloud-native applications like Google Workspace.

Google revolutionized this with BeyondCorp, a Zero Trust security architecture. Instead of trusting the network perimeter, BeyondCorp trusts the context of the individual login attempt. With Context-Aware Access (CAA), a system administrator can create dynamic policies that evaluate the user’s identity, device health, and geographic location in real-time before granting access to Google Drive or Gmail.

For example, you can build a policy stating: “A user can only access Google Drive if they are logging in from a corporate-owned, encrypted laptop running the latest OS, located within the United States.” If a user tries to access Drive from a personal, malware-infected iPad in a foreign country, they are instantly blocked, even if they have the correct username, password, and 2FA token.

Step 1: Enabling Endpoint Verification

Before CAA can evaluate device health, it needs an agent running on the employee’s computer to report that health back to Google.

1. Log into the Google Workspace Admin Console.
2. Navigate to Devices > Mobile > Endpoints > Settings > Universal settings.
3. Under Endpoint Verification, check the box to enable it.
4. You must now deploy the Endpoint Verification Chrome extension (and the associated native helper app for Windows/macOS) to all corporate devices via your MDM (Mobile Device Management) tool or Google Admin policy.

Step 2: Defining the Access Level

An “Access Level” is the specific criteria that a device must meet.

1. Navigate to Security > Access and data control > Context-Aware Access.
2. Click Access levels, and then Create Access Level.
3. Name it Corporate-Secure-Devices.

Building the Conditions

1. Click Add Attribute.
2. Select Device Policy.
3. Check the boxes for the conditions you require. For example:
   • Require screen lock
   • Require device encryption (Crucial for laptops)
   • Require company owned device (Requires you to upload device serial numbers to Google Admin)
4. Click Save.

Step 3: Binding the Policy to Applications

You have defined what a “Secure Device” is, but you haven’t applied that definition to anything yet. You must bind the Access Level to a specific Google service.

1. Go back to the main Context-Aware Access dashboard.
2. Click Assign Access Levels.
3. You will see a list of your Organizational Units (OUs). Select the OU containing your high-risk users (e.g., Finance Department).
4. You will see a list of Google Workspace Apps. Locate Google Drive and click Assign.
5. Check the box next to the Corporate-Secure-Devices access level you just built.
6. Click Save.

The Zero Trust Experience

The policy is instantly active. If a Finance employee goes to a public library, logs onto a public computer, and attempts to open drive.google.com, Google’s BeyondCorp engine will intercept the request.

The engine will evaluate the context: Does this computer have the Endpoint Verification extension? Is the hard drive encrypted? Is the serial number in our corporate database? The public library computer will fail all these checks. The employee will immediately receive a red “Access Denied by Corporate Policy” screen, successfully preventing a massive data exfiltration event without ever relying on a legacy VPN.