Control access to apps based on user & device context

Protect your business with Context-Aware Access

Supported editions for this feature: Frontline Standard; Enterprise Standard and Enterprise Plus; Education Standard and Education Plus; Enterprise Essentials Plus; Cloud Identity Premium. Compare your edition

Using Context-Aware Access, you can create granular access control security policies for apps based on attributes such as user identity, location, device security status, and IP address.

You control user access based on their context, such as whether their device complies with your IT policy.

Context-Aware Access sample use cases

You can use Context-Aware Access when you want to:

Allow access to apps only from company-issued devices
Allow access to Drive only if a user storage device is encrypted
Restrict access to apps from outside the corporate network

You can also combine more than one use case into a policy. For example, you could create an access level that requires app access from devices that are company-owned, encrypted, and meet a minimum operating system version.

Note: Context-Aware Access policies can control app access only from end user accounts. They don't restrict access to Google APIs from service accounts.

Support for editions, apps, platforms, and admin types

Expand section | Collapse all & go to top

About editions

You can apply Context-Aware Access policies only to users who have a license for one of the editions identified at the top of this article.

Users with any other type of edition can access apps as usual—even if you apply a Context-Aware Access policy to all users in the same organizational unit or group. Users who don't have one of the supported editions aren't subject to Context-Aware Access policies that are enforced in their organizational unit or group.

Apps

You can apply Context-Aware Access policies to web apps on desktop, mobile apps, and built-in apps on desktop. Access for apps is evaluated continuously after access is granted. The exception is SAML apps, which are evaluated on sign-in.

Google Workspace apps (core services)

For apps that are core services, policy evaluation is continuous. For example, if a user signs in to a core service at the office and walks over to a coffee shop, a Context-Aware Access policy for that service is rechecked when the user changes location.

This table shows the supported apps for web apps on desktop, mobile apps, and built-in apps on desktop.

Core services	Web apps (desktop or mobile)	Built-in apps on mobile* (Mobile devices are managed using Google endpoint management basic or advanced.)	Built-in apps on desktop
Google Calendar	✔	✔
Google Cloud Search	✔	✔
Google Drive and Google Docs (includes Sheets, Slides, and Forms)	✔	✔	✔ (Google Drive for Desktop)
Gemini	✔
Gmail	✔	✔
Google Meet	✔	✔
Google Vault	✔
Groups for Business	✔
Google Chat	✔	✔
Jamboard Service	✔	✔
Google Keep	✔	✔
Google Sites	✔
Google Tasks	✔	✔
Google Admin console	✔	✔

*Mobile apps support notes:

You can’t enforce Context-Aware Access policies for mobile on third-party built-in apps (for example, Salesforce).
You can enforce Context-Aware Access policies on SAML apps accessed using Chrome web browser.
Mobile devices are managed using Google endpoint management basic or advanced.

Additional Google services

For additional Google services, policy evaluation is continuous. These services are web apps only.

Looker Studio—Turns data into easy-to-read charts and interactive reports.
Google Play Console—Offer Android applications that you develop to the rapidly growing Android user base.

SAML apps

For SAML apps, policy evaluation occurs on sign-in to the app.

This includes third-party SAML apps that use Google as the identity provider. A third-party identity provider (IdP) can also be used (third-party IdP federates to Google Cloud Identity and Google Cloud Identity federates to SAML apps). For details, go to About SSO.
Context-Aware Access policies are enforced when a user signs in to a SAML app.
Example: If a user signs in to a SAML app at the office and walks over to a coffee shop, a Context-Aware Access policy for that SAML app isn’t rechecked when the user changes location. For SAML apps, the policy is rechecked only when the user session ends and they sign in again.
If a device policy is applied at an access level, a user can be approved only by a third-party SAML app through the Chrome browser with endpoint verification enabled.
If a device policy is applied, web browser access on mobile (including mobile apps that use a web browser for sign-in) is blocked.

Platform requirements

You can create different types of Context-Aware Access policies for accessing apps: IP, device, geographic origin, and custom access-level attributes. For guidance and examples of supported attributes and expressions for creating custom access levels, go to the Custom access level specification.

Also, for details on supported BeyondCorp Alliance partners, go to Set up third-party partner integrations.

Platform support such as device type, operating system, and browser access varies by policy type.

Policy types include:

IP—Specifies an IP address range from which a user can connect to an app
Device policy and Device OS—Specifies characteristics about the device from which a user accesses an app, such as whether the device is encrypted or requires a password
Geographic origin—Specifies countries where a user can access apps

IP and geographic origin platform support

Note that if an internet service provider (ISP) changes IP addresses between different geographic regions, there is a delay while these changes take effect. During this delay, Context-Aware Access may block users if their access is enforced by geolocation attributes.

Device type—Desktop, laptop, or mobile device
Operating system
- Desktop—Mac, Windows, ChromeOS, Linux OS
- Mobile—Android, iOS
Access
- Web browser for Desktop and Drive for desktop
- Web browser and built-in first-party apps on mobile
Software—No agent required (except Safari with Apple Private Relay turned on). If Apple Private Relay is configured in iCloud, the device IP address is hidden. Google Workspace receives an anonymous IP address. In this case, if there is a Context-Aware access level assigned as the IP subnet, then access is denied to Safari. Fix this by turning off Apple Private Relay, or by removing the access level that contains IP subnets.

Device policy platform support

Device type—Desktop, laptop, or mobile device
Operating system
- Desktop—Mac, Windows, ChromeOS, Linux OS
- Mobile—Android, iOS. Note that for pre-6.0 Android, you must use Google endpoint management in Basic Mode for Endpoint Verification.
Company-owned–Not supported for devices with Android 12 or later and a work profile. These devices are always reported as user owned, even if they’re in the company-owned inventory. For more information, go to View mobile devices, Learn about device details, and in the Device Information table, scroll down to the Ownership row.
Access
- Chrome browser for desktop and Drive for desktop
- Chrome browser for built-in first-party apps on mobile
Software
- Desktop—Chrome web browser, Chrome Endpoint Verification extension
- Mobile—Manage mobile devices with Google endpoint management (either basic or advanced).

Admin requirements

These admins can set Context-Aware Access policies:

Super admin
An admin with each of these privileges:
- Data Security>Access level management
- Data Security>Rule management
- Admin API Privileges>Groups>Read
- Admin API Privileges>Users>Read

_{Google, Google Workspace, and related marks and logos are trademarks of Google LLC. All other company and product names are trademarks of the companies with which they are associated.}

Was this helpful?

How can we improve it?