27 Device-trust CAA via MDM

Ties access to sensitive apps to the device it comes from, not just to the account. Endpoint verification collects posture signals — OS version, disk encryption, screen lock, admin-approval state, company-owned flag — into the Context-Aware Access attribute set, and an access level built from those attributes is applied through the three DEFAULT policies (all Google-owned apps, all SAML apps, all OAuth apps), which also cover every app enabled later, where a per-app assignment would leave each new app unprotected. Requiring admin approval for devices is what stops an attacker's own laptop enrolling itself into the trusted population. The signals depend on an agent: the Endpoint Verification helper or Chrome extension has to be deployed and the user signed into the managed Chrome profile, or no device reports anything at all.

Documentation: Protect your business with Context-Aware Access ↗ · Deploy Context-Aware Access ↗

Caveats

Block is the only action that is a control¹
Rolling the default policies straight to Block is the classic CAA self-lockout²
An access level nothing can satisfy locks everyone out the moment it goes Active³
CAA does not apply to a session already established⁴
Requires Enterprise Standard+, Education Standard+, Frontline Standard+, Enterprise Essentials Plus…⁵

Monitor is a dry run that always allows, and Warn lets the user through regardless, showing only an in-app warning notification, so a policy parked on Warn admits everyone while the log fills with reassuring rows. Switching a policy to Warn also SILENTLY REMOVES every app that does not support Warn from that policy on save, narrowing coverage without telling you. Read the log’s Event column rather than the action you configured: ‘Access Denied (Monitor mode)’ means nothing was enforced.
Run Monitor first, read the log, then Block, and keep the break-glass admin (№20) OU exempt throughout. The OAuth default policy bites third-party sign-ins, which is where integrations break quietly, so the monitor log earns its keep there most.
And zero device signals is the usual cause. A CloudManagementEnrollmentToken enrols the BROWSER into Chrome Enterprise Core and delivers no device signals by itself; ‘Device state: No Device Signals’ with ‘Device ID: UNKNOWN’ in the CAA log means the user is not signed into the managed Chrome profile with both device-signal toggles on, or the Endpoint Verification helper is not actually deployed on macOS/Windows.
Combine it with session length (№12) and cloud session control (№38), or an attacker with a stolen cookie keeps access from an untrusted device.
Requires Enterprise Standard+, Education Standard+, Frontline Standard+, Enterprise Essentials Plus or Cloud Identity Premium AND an MDM/device-management posture — the licence alone is not enough, and standing up device management is the bulk of the work. Personal/BYOD devices will fail a company-owned condition, so decide the BYOD story before enforcing, not during the incident it causes.

Setup steps

open ↗
https://admin.google.com/ac/managedsettings/724141353720/UniversalAdditionalSettingsTab?vid=EMM_UNIVERSAL_SETTINGS_VIEW · captured 2026-07-15
Devices › Mobile & endpoints › Settings › Universal › Data access
Turn on Endpoint verification so devices report posture signals (OS version, disk encryption, screen lock, admin-approval state) into the Context-Aware Access (CAA) attribute set.

Collect device signals using endpoint verification
ON
Collect device signals from Chrome browser
ON (for the target OU)

Turn endpoint verification on or off ↗ Turn Chrome signals sharing on or off ↗
open ↗
https://admin.google.com/ac/security/context-aware/access-levels · captured 2026-07-15
Devices › Mobile & endpoints › Settings › Universal › Security
Require admin approval for devices so an attacker's own laptop cannot enrol itself into the trusted population.

Device approvals = Require admin approval. Applies to user-owned/personal devices; company-owned devices registered by serial number are auto-approved (except Android work-profile devices)

Require admin approval for device access ↗
open ↗
https://admin.google.com/ac/security/context-aware · captured 2026-07-15
Security › Access and data control › Context-Aware Access › Access levels
Create an access level whose conditions are device attributes, not just network attributes.

Access level 'trusted-device': Device policy
admin-approved AND encrypted storage AND screen lock AND OS version ≥ baseline
company-owned
true

Create Context-Aware access levels ↗
Security › Access and data control › Context-Aware Access › Access levels
Add an access level that only admits a MANAGED Chrome browser at or above a minimum version, written as a CEL expression in the Advanced tab — the Basic editor cannot express either condition. Both attributes come from the Chrome browser signal collection turned on in the first step, so an unmanaged or signed-out browser fails the managed-state check instead of slipping through with no signals. The version floor is a maintenance commitment, not a set-once value: raise it as Chrome releases ship.
```
device.chrome.management_state == ChromeManagementState.CHROME_MANAGEMENT_STATE_BROWSER_MANAGED && device.chrome.versionAtLeast("148.0.0.0")
```
Use case: Managed Chrome browser enforcement ↗
open ↗
https://admin.google.com/ac/security/context-aware/settings · captured 2026-07-15
Security › Context-Aware Access › General settings
Apply the level through the three DEFAULT policies (Google-owned apps, SAML apps, OAuth apps) rather than app-by-app: a default policy also covers every app enabled later, where a per-app assignment leaves each new app unprotected until someone remembers it. Start in monitor mode; per-app assignment remains the exception path for apps needing a stricter level.

General settings: Policy for all Google-owned apps / all SAML apps / OAuth apps = trusted-device; Action = Monitor first, then Block once the monitor log is clean. Do not use Warn (OAuth policies offer only Monitor and Block)

Assign Context-Aware Access levels to apps ↗ Apply a default Context-Aware Access policy for all SAML apps ↗

Ongoing maintenance

automatable: script On every Chrome major release: raise the versionAtLeast() floor in the CEL access level.
requires a human Weekly: work the device-approval queue — pending approvals block real users.

How to verify

From an unmanaged browser, sign in as a test user — the CAA log should show the device failing the level (Blocked, or Access Denied (Monitor mode) while ramping).
From a managed device, confirm the log shows device signals present (no "No Device Signals" / "Device ID: UNKNOWN").

v0.0.3Preventedition Ent Std+ + MDM policy #25 · #4, #7 ↗