Control access to apps based on user & device context

Assign Context-Aware access levels to apps

After you create access levels, you’re ready to assign them to apps. Access levels define the context within which users can access apps. You can define user context such as user identity, device security status, IP address, and geographical location.

Note: When you are assigning access levels, be sure to assign them to apps, and not to the Admin console. There is a separate feature to assign access levels to the Admin console. Check your access level assignment, and don’t accidentally assign your access levels to the Admin console.

Assign Context-Aware access levels

Before you begin: To apply the setting for certain users, put their accounts in an organizational unit (to set by department) or a configuration group (to set for users across or within departments).

  1. Sign in to your Google Admin console.

    Sign in using your administrator account (does not end in @gmail.com).

  2. In the Admin console, go to Menu ""and then"" Securityand thenAccess and data controland thenContext-Aware Access.
    ""
  3. Click Assign, then Assign access levels. You see a list of apps.
  4. On the left, select an organizational unit or group. To apply the setting to everyone, leave the top organizational unit selected. Otherwise, select a child organizational unit or a configuration group.

    ""

  5. Find the app you want and on the right, click Assign.  You may have to scroll to see the Assign button for the app you want. Also, be sure not to unintentionally assign the access level to the Admin console.

    ""

    To assign the same access levels to multiple apps at once, check the boxes next to the apps and click Assign at the top of the list.

    ""

    You see a list of all access levels. Access levels are a shared resource between Google Workspace and Google Cloud so you might see access levels you didn’t create in the list.

  6. Select one or more access levels (up to 10) for the app.

    Users are granted access to the app when they meet the conditions specified in just one of the access levels you select (it’s a logical OR of the access levels in the list). If you want users to meet the conditions in more than one access level (a logical AND of access levels), create an access level that contains multiple access levels. If you want to assign more than 10 access levels for an app, you can use nested access levels to do so.

    Note for mobile apps: For integrated Gmail (which contains Gmail, Google Chat, and Google Meet), you can grant or deny access to all 3 services at once. To set up integrated Gmail, you turned on Meet and Chat for Gmail. For details on integrated Gmail, go to Set up integrated Gmail for your organization. If Google Chat and Google Meet are implemented as separate apps (not as part of integrated Gmail), you need to grant or deny access to those apps separately.

  7. To apply the access levels to users of desktop, Android, and iOS apps (as well as web apps), check the Apply to Google desktop and mobile apps box. This option applies to Native apps only.

    We recommend that you check this box whenever you assign access levels to apps and always deploy Endpoint verification from a security standpoint.

    The following table summarizes the behavior based on whether you check the Apply to Google desktop and mobile apps box and whether you deploy Endpoint verification. The rows in bold underscored text display the recommended settings.

    Key terms for this table:

    • Access level applied: Access is granted based on the access levels you set up in Context-Aware Access configuration.
    • Access allowed: Context-Aware Access is not applied and all access is allowed.
    • Access blocked: Access is blocked because Context-Aware Access isn't configured, or you don't have Endpoint verification turned on.

    Access Level

    CAA Enabled

    Allow/Block (Native and Web)

       

    Mobile

    Desktop

       

    Mobile Native

    Mobile Web

    Desktop Web

    Desktop Native

    Endpoint verification deployed?

    Access Level with only IP/Geo attributes

    Apply to Google desktop and mobile apps box checked

    Access level applied

    Access level applied

    Not required

    Apply to Google desktop and mobile apps box not checked

    Access allowed

    Access level applied

    Access level applied

    Access allowed

    Not required

    Access Level with Device attributes

    Apply to Google desktop and mobile apps box checked

    Access level applied

    Access level applied

    Yes

    Apply to Google desktop and mobile apps box checked

    Access level applied

    Access blocked

    No

    Apply to Google desktop and mobile apps box not checked

    Access allowed

    Access level applied

    Access level applied

    Access allowed

    Yes

    Apply to Google desktop and mobile apps box not checked Access allowed Access level applied Access blocked Access allowed No
  8. Click Save. If a user meets the conditions in at least one of the selected access levels, the user can access the app. The access level name displays in the assigned access levels list next to the app.

Delete access levels (which are a shared resource)

Access levels are shared across Google Workspace and Google Cloud. Admins can create access levels through the Admin console, Google Cloud (console and API), and the Google Cloud SDK.

Because access levels are shared across platforms, you might see items like these in the assigned access levels list:

  • Access levels you didn’t create
  • Access levels marked as “deleted” that you didn’t delete

Recommendation: If you are a Workspace-only user, do not add or modify Context-Aware access levels using the Google Cloud Platform (GCP) console, or any method other than the Context-Aware Access interface. Doing so can cause this error: Unsupported attributes are being used on Google Workspace and blocked users.

Delete and unassign access levels

Because access levels are a shared resource, they can be deleted in the Admin console or another platform. If you delete an access level in the Admin console, all app assignments that were created in the Admin console for that access level are removed (unassigned).

If an access level is deleted on another platform (for example, the Google Cloud Platform console), the access level is marked as deleted. However, the access level is still assigned to apps and access to those apps is blocked. If you see deleted access levels, remove (unassign) them to unblock access.  If the deleted access level was assigned to Admin console, you will lose access to Admin console immediately and have to contact Google support team to regain the access.

To delete access levels, you need specific admin privileges.

Expand section  |  Collapse all & go to top

Remove deleted access levels for all apps
This is the most efficient way to remove deleted access levels and unblock apps.
  1. Sign in to your Google Admin console.

    Sign in using your administrator account (does not end in @gmail.com).

  2. In the Admin console, go to Menu ""and then"" Securityand thenAccess and data controland thenContext-Aware Access.
  3. On the top right, click Unassign Access Levels. When prompted, confirm by clicking Unassign Access Levels again.
    The system removes deleted access levels from all apps. No apps are blocked.
Was this helpful?
How can we improve it?

Need more help?

Sign in for additional support options to quickly solve your issue

Search
Clear search
Close search
Google apps
Main menu
Search Help Center
true
73010
false
false