Control access to apps based on user & device context

Deploy Context-Aware Access

Prepare for a smooth rollout of Context-Aware access.

A successful deployment of Context-Aware access protects Workspace data from risky users, while ensuring that legitimate users are not blocked. Consider these rollout recommendations to mitigate the risk of numerous blocked users.

Use monitor mode to test access levels

You can initially assign an access level in monitor mode, rather than active mode. Monitor mode lets you simulate the effects of enforcing an access level without actually blocking user access.

When applying a new access level, it’s a good idea to leave it in monitor mode for at least one week. During that period, logged events in the Context-Aware Access log show which users would be blocked if the access level were in active mode. After verifying that an access level is working the way you want it to, you can turn on actual enforcement by switching the access level to active mode.

For detailed instructions on using monitor mode, see Assign Context-Aware access levels to apps.

Other rollout recommendations

Phase your rollout. Begin with one organizational unit or group as a pilot group, and see how the policy works for them. If those users can access apps successfully, then phase in the next group of users. If they’re satisfied, then implement access policies for all of your users.
Assign access policies to selected apps. Try deploying policies on apps that aren't heavily used in your environment. Track of what happens with those apps, and then employ the policies on more heavily used apps as you go.
Avoid locking out users or partners. 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 users and partners need.
Don’t use Google Cloud Platform (GCP) to add or change access levels if you’re a Workspace-only customer. If you add or change access levels using a method other than the Context-Aware access interface, this error message may result: Unsupported attributes are being used on Google Workspace, and users can be blocked.
Plan help desk support for users who might need help during the rollout.

Monitor your rollout

Whatever implementation method you use, monitor the results of your implementation by seeking user feedback, and consulting the Context-Aware Access log events for records of denied users.

Prepare for deployment

For a smooth deployment, follow these steps before creating or implementing new access policies.

1. Inform your users

Talk to your users to find out what they need to protect in their work environment. Since you'll be implementing Context-Aware Access by organizational unit or group, the needs of different users in your organization can vary. Let them know the possible consequences of the policies you create and assign: for example, that they might be blocked at different times for various reasons. Advance communication helps promote user acceptance.

2. Organize your users into organizational units or groups

You can assign access levels by org unit. Or if you already have org units set up for other purposes, you can create and then assign levels to configuration groups. In either case, be sure the users you want to grant access to are in the right organizational units or groups.

3. Survey enterprise devices

Before you implement device-based policies, be sure the devices in your enterprise are under proper IT management and in compliance with company standards. Verify whether devices are encrypted, running an up-to-date operating system, and are company-owned or personal devices.

4. Enroll mobile devices with endpoint management

Mobile devices must be managed with Google endpoint management (either basic or advanced).

5. Enforce endpoint verification before creating policies

Enforce the use of Endpoint verification so you know which devices are accessing (or will be accessing) Google Workspace data. In Chrome extensions, you must specify Force install for Endpoint verification and require an access key. Go to Set up endpoint verification for details.

Set up endpoint verification and turn on Context-Aware Access

Software setups for desktop or mobile devices.

Set up endpoint verification

If you enforce a device policy in an access level, you and your users have to set up endpoint verification. You enable endpoint verification in the Admin console. For instructions, see Turn endpoint verification on or off.

Note: 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 and refresh their browser page before you enforce a Context-Aware device policy.

Review which devices have endpoint verification

Sign in to your Google Admin console.
Sign in using your administrator account (does not end in @gmail.com).
Go to Menu DevicesOverview.
Click Endpoints.
Click Add a filter.
Select Management TypeEndpoint Verification.
Click Apply.

Set up mobile devices (Google endpoint management)

To enforce access levels for mobile devices, the user of the device must be managed under either basic or advanced mobile management.

Additional steps

Expand all | Collapse all

Upload your device inventory of company-owned devices

To enforce a device policy that requires company-owned devices, Google needs a list of serial numbers for your company-owned devices.

For instructions, go to Add devices to your inventory in Add company-owned devices to the inventory.

Note: Devices with Android 12 or later and a work profile are always reported as user-owned, even if you add them to the company-owned inventory. For these devices, if an access level requires that a device is company-owned, the action isn’t taken, and if an access level requires that a device is user-owned, the action is taken. For more information, go to View mobile device details, Learn about device details, and in the Device Information table, scroll down to the Ownership row.

Approve or block devices

To enforce a device policy that requires approved devices, first you have to approve or block devices.

Turn on and turn off Context-Aware Access

You can turn on Context-Aware Access at different times in the rollout process. You can turn it on before creating access levels and assigning them to apps, which means that access levels you assign to apps are enforced immediately.

You can also do initial setup and review (access level creation, access level assignment, endpoint verification) without turning on Context-Aware Access. During this time, access level assignments aren’t enforced. When the configuration is complete, you can turn on Context-Aware Access.

You can turn off Context-Aware Access if there are user issues, and you want to pause the app while you investigate which policies are creating the issues. After you determine which access level is causing the issues, you can modify the policy or remove it as needed for specific organizational units or groups.

Expand all | Collapse all

To turn on Context-Aware Access

Sign in to your Google Admin console.
Sign in using your administrator account (does not end in @gmail.com).
In the Admin console, go to Menu SecurityAccess and data controlContext-Aware Access.
Verify Context-Aware Access is ON. If not, click Turn On.

To turn off Context-Aware Access

Sign in to your Google Admin console.
Sign in using your administrator account (does not end in @gmail.com).
In the Admin console, go to Menu SecurityAccess and data controlContext-Aware Access.
Click Turn Off.

What's next:

Create and assign access levels

These articles step you through creating access levels and assigning them to apps:

Explore use cases

These articles show common use cases for implementing Context-Aware Access in your environment:

Was this helpful?

How can we improve it?