Control access to apps based on user and device context

Context-Aware Access overview

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.

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

Editions

You can apply Context-Aware Access policies only to users who have one of these editions:

  • Enterprise
  • Cloud Identity Premium
  • Google Workspace for Education Plus

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:
  • Core services (continuous policy evaluation)

    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.

    • 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
  • SAML apps (policy evaluation on sign-in)
    • 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’t enforce Context-Aware policies on:
  • Mobile apps, such as the Gmail app or the Apple Mail app (all access allowed)
  • Desktop apps, such as Drive for desktop (all access allowed)
Platform requirements

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—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

  • Device type—Desktop, laptop, or mobile device
  • Operating system—Mac, Windows, Chrome
  • Access—Web browser only
  • Software—Any browser

Device policy platform support

  • Device type—Desktop and laptop
  • Operating system—Mac, Windows, Chrome
  • Access—Web browser only
  • Software—Chrome web browser, Chrome Endpoint Verification extension
Admin requirements
These admins can set Context-Aware Access policies:
  • 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

When a user tries to access an app and that user doesn’t meet the access level conditions, they see an error message you’ve customized.
Your message should include information about who to contact to get access. It applies to all apps for users in an organizational unit. If the admin contact information is different for another location, you can create different messages for other organizational units.
For example, if you’ve defined a device policy for Gmail access, and a user tries to access Gmail from the Safari browser on a Mac or iPhone, they will see this message.  That’s because device policies allow users to access apps only from the Chrome browser and only from desktops or laptops (not mobile devices). See platform requirements.

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.

What's next: create access levels

Was this helpful?
How can we improve it?

Need more help?

Sign in for additional support options to quickly solve your issue