Control access to apps based on user and device context

Context-Aware Access overview

This feature is available with G Suite Enterprise, G Suite Enterprise for Education, G Suite Enterprise Essentials, and Cloud Identity Premium editions.

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:

  • G Suite Enterprise
  • Cloud Identity Premium
  • G Suite Enterprise for Education
  • G Suite Enterprise Essentials (domain verified only)

Users with any other type of edition (such as G Suite Basic or G Suite Business) 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 G Suite services (continuous policy evaluation)

    Example: If a user signs in to a core G Suite 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+
    • Groups for Business
    • Google Chat (you can apply access control policies to Google Chat using Hangouts Chat)
    • Hangouts Chat 
    • Jamboard Service
    • Keep
    • Sites
    • Tasks
  • (Beta) SAML apps (policy evaluation on sign-in)
    • Third party SAML apps that use Google as the identity provider.
    • 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.

    • We recommend against creating device policies for SAML apps. CAA doesn’t collect mobile device information. If a user signs into a SAML app on a mobile device that uses a web browser for sign-in, access is blocked.

You can’t enforce Context-Aware policies on:
  • G Suite mobile apps, such as the Gmail app or the Apple Mail app (all access allowed)
  • Desktop apps, such as Drive File Stream (all access allowed)
  • (Beta) SAML mobile apps that use a web browser for sign-in (all access denied)
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 G Suite 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 G Suite 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 G Suite 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.
  • 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?