Context-Aware Access

Versions: Standard and Plus

Context-Aware Access is how to limit a user's access to a given service within Google based on criteria. That criteria can be geolocation, 2-step Verification, IP address, or whether access is from an approved device. The criteria, called access levels in Google Workspace, can apply to users, groups, and organization units. You can use several criteria markers to determine which users are within scope or out of scope, based on the context of defined access levels.

One of the big things to be aware of is that Context-aware access does not prevent access to another service or a service outside of the defined scope. And it does not prevent users from signing into the account. It only prevents access to the Google service(s) covered by the scope.

Warning: Context-aware access does not stop users from signing in. It stops them from accessing services.

Context-Aware Examples

Now that we know what Context-Aware access is, let’s look at some examples that apply it to education. Later in this article, we will cover the how-to for creating one of these examples.

Restricting an app by time frame

If you want a group of users to only use an app during a set time, you can restrict their access for the blocked out hours. Maybe you do not want students to use Chat or staff to use Gmail outside of school hours. When restricting staff access for Gmail, staff members cannot use their email outside school hours. They can only check and send emails during working hours.

When access is not permitted, the service is still working. A third party can still send an email to a staff member, but the user cannot check their email nor send or receive emails. They have no way of knowing that an email came in.

Reducing VPN Access by location

Let’s say you want to reduce VPN access. More specifically, when utilizing a VPN to access content outside an expected area. If you know your school’s public IP address and send all proxies back into the IP, you can restrict account access by users outside of the United States of America. This Context-Aware Access prevents direct access to the account from someone on foreign soil.

Remember earlier when we covered knowing what it is vs. what it isn’t? In this latest example, users can get around the access rule if they VPN into the United States. Once on the VPN, they can access any service.


Warning: Context-aware access is a paid feature available with Standard and Plus versions of Workspace. For the feature to work the licenses must be applied to end users. What does that mean? If you set up Context-aware access and have configured it for the user OU, but have not applied end user licenses, the access rule will do nothing.

There are a few steps to take before you can use Context-Aware Access, including:

  1. Set up software for desktop or mobile devices, if needed.
  2. Turn on Context-Aware Access.
  3. Create an access level.

See Set up software and create Context-Aware access levels for more information for the steps above.

With the setup complete, it’s time to assign access levels to apps, groups, and the Admin console.

Example: Build a Network-Based Context-Aware Rule

Now we are ready to build a Context-Aware Rule. Now we are read to build a basic rule restricting access to only those on our organizations network. If you'd like to build an advanced rule see Context-Aware Access examples for Advanced mode.

  1. Go to Context-Aware Access.
    Admin console > Security > Access and data control > Context-Aware Access
  2. Click Access levels.
  3. Click Create Access Level.
  4. Fill in the Details section Name and Description.

    Pro Tip: Choose a name and description here that reflects the restriction, rather than the people or groups it can be applied to and that you or other admins can easily identify.

  5. In the Conditions section, select Meet Conditions for the Apply condition if users field.
  6. Click Add Attribute.
  7. In the Add Attribute drop-down list, select IP subnet.
  8. Select is for the condition.
  9. In the IP number field, enter an IPv4 or IPv6 address, or a routing prefix in CIDR block notation.

    Note: In this example, there is only one condition. Once you build these conditions out, a rule can have multiple conditions. You determine if the rule grants access if it meets those listed conditions or if it does not meet the conditions. The easiest way to remember how this should be set is, whatever you have your rule set as, it is true when we apply it, they get access, if the rule is false with the request, it is denied. Remember the underlying service must be on, if it is off, then the user will never get access.

  10. Click Save.
  11. At the What’s next prompt, click Assign Access Level. The Assign access levels page opens.

    Note: If the user doesn’t have any rule applying either by group or by OU, they are always granted access. If they have one or more rules applied that they fall under, if any of the rules are true, they are granted access, if not, then they are denied access. Users will see a message when they are denied, either a default message, remediation message which is system generated giving steps to not be denied, or custom messages. See the end of this article for more information on remediation messages and custom messages.

  12. For this example, we will apply it to an OU. Navigate to the OU the rule applies to.

    Caution: If you are following along and building this example, be sure to use a test OU before applying to your environment.

  13. Check the checkbox next to an app to select it or check the select all checkbox at the top to select all apps. In this example, we are selecting all.
  14. Click Assign above the apps list. Be sure to not click Assign at the top right or else you will assign the access level to the Admin console, potentially locking out all admins.
  15. Check the necessary Access levels. Here we are selecting the access level we created earlier.
  16. Click Save. You'll see the access level assignment in the Access level column for each app that you assigned.

User message - access denied

In this example, when a user is not on the designated IP, they will be denied access when they try to access any of the applied apps.

Remediation message

End user remediation will enable admins to provide their users with details about why their access has been denied and what steps need to be taken to restore access. See Allow users to unblock apps with remediation messages in Context Aware Access for more information.
Security > Context-Aware Access > User Message

Custom user message

You can customize the message your user sees from the Context-Aware Access page in the Admin console. When customizing messages, be sure to add descriptive text to help your staff understand what the user is experiencing.
Security > Context-Aware Access > User Message

Monitoring CAA rules with the Investigation Tool

Once you have a rule in place, you’ll be able to check its enforcement in the Investigation Tool. Once you investigate, you can also build an activity rule or create a custom chart for the information.

Ready to upgrade?

If you do not have an upgrade version of Workspace and you would like to learn more about implementing context-aware features, learn more about upgrading your Google Workspace for Education edition.


Document Version Date Description of Change
1.0 3/18/2024 Updated link to open in a new tab


Articles in this section