Enable Verified Access with Chrome devices

What is Verified Access?

Verified Access ensures that a device connecting to your network has been unmodified and is policy- compliant. Verified Access serves as an access point for a network service (such as a VPN gateway, a sensitive server, an enterprise Certificate Authority (CA), or an enterprise Wi-Fi access point) to get a hardware-backed cryptographic guarantee of the identity of the device and user that’s trying to access it. Learn more about how Verified Access works.

How does it work?

Verified Access uses the Trusted Platform Module (TPM) - present in every Chrome OS device - to enable enterprise network services to cryptographically confirm the identity and status of verified boot and enterprise policy using a Google server-side Application Programming Interface (API).

You need to enable the Verified Access feature in the Google Admin console and force-install a Chrome extension on your users’ Chrome devices. Once you’ve done this, your network service talks to the Verified Access API to determine the policy compliance and talks to Google to (optionally) determine the identity of the client device. See step 3 below for more about the network service endpoint.

Set up Verified Access for my company

Step 1: Enroll Chrome devices

Verified Access only works for the managed enterprise users on the devices enrolled in the domain that you manage. Learn how to enroll a Chrome device.

Step 2: Install a Verified Access extension

To use Verified Access in your organization, you need to have a Chrome extension that calls Verified Access API on the client devices. You can get an extension from an independent software vendor (ISV), such as Cloudpath, or use Google Verified Access API Developer Guide to implement your own extension.

Make sure that this extension is deployed to Chrome Web Store or an enterprise Chrome Web Store specific to your organization.

Note: There are two APIs in the chrome.enterprise.platformKeys namespace - challengeUserKey and challengeMachineKey. In step 4, if you’re doing device verification, you need to call “challengeMachineKey”. If you’re doing user verification, you need to call “challengeUserKey”. Consult with your ISV if you have questions.

Step 3: Configure your network service endpoint

You need to have a network service that understands Verified Access protocol and makes authorization decisions based on the results of the Google Verified Access API call. Examples are VPN appliances that support Verified Access, or Certificate Service extensions that let you issue client device certificates to the compliant devices. Similar to the Chrome extension described above, you can obtain these from an ISV or follow the instructions in the Google Verified Access API Developer Guide to implement your own.

Verified Access diagram

You will need to:

  • Know the Google service account used by this endpoint when it talks to Google API (ask your vendor).
  • Grant access to this account in your organization's Admin console in the next steps.

Step 4: Configure Admin console policies

You can choose to configure device or user verification. Security-conscious enterprises typically do user verification because it verifies both the user and device, whereas; only doing device verification means that anyone using the device could access the protected network.

Configure device policies

  1. Set Verified Access policy to Enable for Enterprise Extensions.
  2. Set the Verified Mode policy value to require verified boot mode (or not) for your device checks.
  3. Under Verified Mode, add the service account email used by your network service endpoint to one of these lists:
  •  Service accounts that are allowed to receive device ID 
  • Service accounts that can verify devices but do not receive device ID

Configure user policies

  1. Set the Verified Access policy to Enable for Enterprise Extensions.
  2. Set the Verified Mode policy value to require verified boot mode (or not) for your device checks.
  3. Under Verified Mode, add the service account email used by your network service endpoint to one of these lists:
  • Service accounts that are allowed to receive user data
  • Service accounts that can verify users but do not receive user data 

Enable application policies (mandatory)

  1. Enable Force Installation.
  2. Enable Allow access to challenge enterprise keys.

Note: The chrome.enterprise.platformKeys API is only available to extensions that are force-installed by policy.

That’s it! You’ve set up Verified Access. Questions? See the Verified Access API Developer Guide.

Was this article helpful?
How can we improve it?