Control access to apps based on user & device context

Set up software and create Context-Aware access levels

The first step in setting up Context-Aware access is to create access levels that combine conditions and values that define a user or device context. Access levels define the context within which users can access apps.

For example, you can create an access level for accessing Gmail that requires users to connect from a specific IP address range and require their devices to be encrypted.  

Let’s say that Mary is using Gmail on her laptop in the corporate office and then walks to a nearby coffee shop where she plans to continue using Gmail. Because her IP address changed, she won’t be able to access Gmail at the coffee shop if you specify that users connect to Gmail from a corporate IP address range. Private IP addresses are not supported.

Step 1: Set up software for desktop or mobile devices

Software setups for desktop or mobile devices.

Set up for desktop (endpoint verification)

If you enforce a device policy in an access level, you and your users have to set up endpoint verification. You enable endpoint verification in the Admin console.

Chrome Browser, the endpoint verification extension, and a native helper app (Mac, Windows, and Linux) must be installed on the computers you want to monitor.

Turn on Endpoint verification for desktop

  1. Turn on Endpoint verification in the Admin console.
  2. Deploy the Chrome endpoint verification extension to company computers or tell your users to manually install it from the Chrome Web Store.
  3. From the Admin console home page, go to Device Management and then Endpoint management.
    You see a list of devices with the Chrome Endpoint Verification extension.

Set up for mobile devices (Google Endpoint Management)

Implement Endpoint management for mobile devices

Mobile devices require the implementation of Google Endpoint Management in Advanced Mode or in Basic Mode.

Additional steps

Upload your device inventory of company-owned devices

If you plan to enforce a device policy that requires company-owned devices, Google needs a list of serial numbers for your company-owned devices.

Follow the instructions in “Add devices to your inventory in Inventory company-owned devices. You’ll see how to get a  list of company-owned devices and how to add devices to the list.

Approve or block devices

If you plan to enforce a device policy that requires approved devices, first you have to approve or block devices using endpoint verification.

Step 2: Turn on Context-Aware Access

You can turn on Context-Aware Access at different times in the rollout process. You can turn it on before creating access levels and assigning them to apps, which means that access levels you assign to apps are enforced immediately.

You can also do initial setup and review (access level creation, access level assignment, endpoint verification) without turning on Context-Aware Access. During this time, access level assignments aren’t enforced. When the configuration is complete, you can turn on Context-Aware Access.

To turn on Context-Aware Access:

  1. Sign in to your Google Admin console.

    Sign in using your administrator account (does not end in

  2. From the Admin console Home page, go to Securityand thenContext-Aware Access.
  3. Verify Context-Aware Access is “ON for everyone”. If not, click Turn On.


Step 3: Create an access level


Define access levels 
Access levels consist of one or more conditions that you define and which users must meet to access apps. Access level conditions contain attributes you can select, such as device policy, IP subnet, or another access level.
  1. Select Access levels.
    You see a list of defined access levels. Access levels are a shared resource between Google Workspace, Cloud Identity, and Google Cloud Platform (GCP) so you might see access levels you didn’t create in the list. To indicate which team created an access level, consider making the platform, such as “gcp,” part of the access level name.
  2. On the top right, select Create access level.
    You’ll define the access level by adding one or more conditions to it. Then define each condition by specifying one or more attributes. 
  3. Add an access level name and optional description.
  4. For the access level condition you add, specify if the condition applies when users:
    • Meet attributes—Users must satisfy all the attributes in the condition.
    • Don’t meet attributes—Users don’t meet any of the attributes in the condition. This option specifies the opposite of the condition and is most frequently used for IP subnet attributes. For example, if you specify an IP subnet and “don’t meet,” only users with IP addresses outside of the specified range will match the condition.
  5. Click Add Attribute to add one or more attributes to the access level condition. The attributes you can add are:
    • IP subnet — IPv4 or IPv6 address or routing prefix in CIDR block notation. Note that private IP addresses are not supported
    • Geographic origin — Countries/regions where the user is accessing Google Workspace services.
    • Device policy (only choose the devices policies you need to implement)—
      • Admin approval is required (if required, the device must be approved)
      • Company owned device is required
      • Screen lock is required
      • Device encryption (Not supported, Not encrypted, Encrypted)
    • Device OS (users can only access Google Workspace with the operating systems you select. Set a minimum operating system version, or allow any version. Use the format major.minor.patch for the operating system version)—
      • macOS
      • Windows
      • Linux
      • Chrome OS
      • iOS
      • Android
    • Access level (must meet the requirements of an existing access level).
  6. To add another condition to the access level, click Add condition and add attributes to it.
  7. Indicate the conditions users must meet:
    • And—Users must meet the first condition and the added condition.
    • Or—Users must meet only one of the conditions.
  8. When you’ve finished adding access level conditions, save the access level definition by clicking Save. Now you can assign this access level to apps.

Sample access level

This example shows an access level called “corp_access.” If “corp_access” is applied to Gmail, users can access Gmail only from an encrypted and company-owned device, and only from the US or Canada.
Access level name corp_access
A user gets access if they Satisfy all the attributes in the condition
Condition 1 attribute

Device policy
   Device encryption = encrypted
   Company-owned device = required

Join condition 1 and condition 2 with AND
A user gets access if they Satisfy all the attributes in the condition
Condition 2 attribute

Geographic origin
   Countries = US, Canada


For more examples, see Context-Aware Access examples.

What's next: assign access levels to apps

Was this helpful?
How can we improve it?

Need more help?

Sign in for additional support options to quickly solve your issue

Clear search
Close search
Google apps
Main menu
Search Help Center