Supported editions for this feature: Enterprise; Education Plus; Cloud Identity Premium. Compare your edition
Using Context-Aware Access, you can create granular access control policies to apps based on attributes such as user identity, location, device security status, and IP address.
Context-Aware Access gives you control over which apps a user can access based on their context, such as whether their device complies with your IT policy.
You can still set access policies, such as 2-Step Verification, for all members of an organizational unit or group. Context-Aware Access provides additional granular and contextual controls for those users.
Access for apps is evaluated continuously after access is granted. The exception to this rule is SAML apps, which are evaluated on sign-in.
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 OS version.
Context-Aware Access support
You can apply Context-Aware Access policies only to users who have 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
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 Native apps (built-in apps) on desktop.
|
Core services |
Web apps (desktop or mobile) |
Native apps on mobile* |
Native apps on desktop |
|
Calendar |
✔ |
✔ |
|
|
Cloud Search |
✔ |
✔ |
|
|
Drive and Docs (includes Sheets, Slides, and Forms) |
✔ |
✔ |
|
|
Gmail |
✔ |
✔ |
|
|
Google Meet (you can apply access control policies to Google Meet using Hangouts Meet) |
✔ |
✔ |
|
|
Hangouts Meet |
✔ |
✔ |
|
|
Google Vault |
✔ |
||
|
Google Currents (formerly Google+) |
✔ |
✔ |
|
|
Groups for Business |
✔ |
||
|
Google Chat (you can apply access control policies to Google Chat using Hangouts Chat) |
✔ |
✔ |
|
|
Hangouts Chat |
✔ |
✔ |
|
|
Jamboard Service |
✔ |
✔ |
|
|
Keep |
✔ |
✔ |
|
|
Sites |
✔ |
||
|
Tasks |
✔ |
✔ |
|
|
Drive for desktop |
✔ |
*Mobile apps support notes:
- You can’t enforce Context-Aware Access policies for mobile on third-party native apps (for example, Salesforce).
- You can enforce Context-Aware Access policies on SAML apps accessed using mobile web browsers (Safari and Chrome).
- Mobile devices are managed using Google Endpoint management basic or advanced.
SAML apps
For SAML apps, policy evaluation occurs on sign-in to the app.
- 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 Set up single sign-on for managed Google Accounts using third-party Identity providers.
- 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, web browser access on mobile (including mobile apps that use a web browser for sign-in) is blocked.
You can create different types of Context-Aware Access policies for accessing apps: IP, device, and geographic origin.
Platform support, such as device type, operating system, and browser access varies by policy type.
Policy types
- 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 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, Chrome OS, Linux OS
- Mobile—Android, iOS
- Access—
- Web browser for Desktop and Drive for desktop
- Web browser and Native first party apps on mobile
- Software—No agent required
Device policy platform support
- Device type—Desktop with laptop or mobile device
- Operating system—
- Desktop—Mac, Windows, Chrome OS, 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.
- Access—
- Web browser for desktop and Drive for desktop
- Web browser for Native first party apps on mobile
- Software—
- Desktop—Chrome web browser, Chrome Endpoint Verification extension
- Mobile—Most attributes supported without installing any software. For a few attributes, a device policy application (MDM advanced) is needed.
- Super admin
- Delegated 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
User experience
Best practices for rolling out Context-Aware Access policies
Follow these best practices to help ensure a smooth rollout of Context-Aware Access policies in your company. These best practices are based on customer feedback.
Avoid locking out employees, partners, or external collaborators
- Don’t block access to Google Workspace services, such as Gmail, that you use to share communications with your users (and that they also need to communicate with you).
- Identify IP ranges that partners, external collaborators, and clients need.
- Keep in mind that some Google Workspace services, such as Forms and Sites, don’t have a mobile app and will be blocked on phones.
Roll out device policies in phases
- Discover—Enforce the use of Endpoint verification so you know which devices are accessing (or will be accessing) Google Workspace data. Find out information about each device, such as if it’s encrypted, running an up-to-date operating system, and if it’s a company-owned or personal device.
Note that if you enforce a Context-Aware device policy before the user can sign in to Endpoint verification, the user may get access denied even if their device meets the enforced Context-Aware policy. This is because syncing the device attributes through Endpoint verification may take a few seconds. To avoid this, be sure to have users sign into Endpoint verification before you enforce a Context-Aware device policy. - Remediate—Get your devices under IT management and in compliance with company standards in preparation for device policy enforcement. This should help reduce help desk tickets and support calls.
- Enforce—Enforce policies to restrict access to apps based on device context. Identify the organizations, sub-organizations, and groups, and then apply device policies in a phased rollout. Base your rollout plan on the device composition of each organization or group, and plan for sufficient help desk support.
