Find the answers to frequently asked questions for Context-Aware Access
Why aren’t Context-Aware Access policies applied to some users in my company?Users may not all have the same licenses assigned to them. Verify that your users are members of an organizational unit or group that has Context-Aware Access-supported Google Workspace editions. Check Billing in the Admin Console to verify user licenses.
Verify that the access setting in the Context-Aware Access policy is the one you intend - either Meet attributes or Don’t meet attributes.
If you enforce a device policy at an access level, you and your users have to set up endpoint verification. You enable endpoint verification in the Admin console. Go to Set up software and create Context-Aware access levels for details.
If an access level denies a user request but the access level appears to be configured correctly, the user may need to force the server-side device state to refresh. Go to Use mobile devices with access levels - Troubleshooting for details.
Chrome browser users (desktop and mobile), must turn on sync in Chrome browser. Go to Turn sync on and off in Chrome for details.
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 Private Relay, or by removing the access level that contains IP subnets.
Google recommends that you do not use the Google Cloud Platform (GCP) interface to add or modify Context-Aware access levels if you are 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.
