BeyondCorp Enterprise, in depth: device signals, access levels in YAML and CEL, a tier ladder, enforcement across IAP, Workspace and Chrome, and a rollout that does not lock people out

What the product is in late 2026

Product names in this area have moved several times, so it helps to separate the durable building blocks from the packaging. Checked against Google's documentation on 2026-10-01, the pieces are these. Access Context Manager stores access levels: named, reusable conditions about the request and the device. Endpoint Verification collects device attributes from Chrome and reports them to the organization's device inventory. Identity-Aware Proxy enforces identity and access levels in front of applications served through Google Cloud. Context-Aware Access applies the same kind of conditions to Google Workspace and to SaaS applications that sign in through Google. The Chrome Enterprise Premium layer adds protections inside the browser: data loss prevention controls on copy, paste, download and print, real-time URL and file scanning, and malware sandboxing.

Two components that older guides describe are gone. The BeyondCorp Enterprise client connector was deprecated in March 2023 with a shutdown planned for the end of that year. The app connector, which tunnelled traffic from IAP to applications outside Google Cloud through an agent running next to them, carries a notice stating that from May 2026 new connectors can no longer be created and that support for existing ones would stop by the end of July 2026. The notice names no successor. If you still have app connectors, treat them as unsupported and plan a different path to those applications; do not follow older tutorials that create new ones.

The model: signals, levels, enforcement

The architecture has three layers, and keeping them separate is what makes it manageable. Signals describe facts about the request: the user's identity and groups, the source IP and region, the time, and the device's operating system, encryption, ownership and management state, optionally enriched by endpoint security vendors; Google's documentation lists integrations such as CrowdStrike, Check Point, Lookout, Tanium and VMware. Access levels are named policies over those signals, written once and reused. Enforcement points evaluate the levels on each request: IAP for your own applications, Context-Aware Access for Workspace and SaaS, and Chrome itself for in-browser data controls.

The practical consequence is that you design levels for the whole organization, not per application. An application's policy then says only "members of this group, with this level". When the definition of a managed device changes, you change one level and every application that uses it follows.

Device signals and how fresh they are

Device attributes come mostly from Endpoint Verification. It is deployed as a Chrome extension, pushed by the administrator, and a separate helper application for Windows, macOS and Linux that is required for some signals and integrations, including certificate-based access and some third-party posture integrations. Once installed, the device appears in the inventory with its identifiers, operating system, owner, encryption state, whether it has a password, and the times it first and last synchronised.

That last field matters more than it looks. An access level evaluates the attributes the inventory holds, which are only as current as the last sync. A laptop that was encrypted at the last sync and has since had encryption disabled still looks encrypted until it syncs again, and a laptop that has not synced at all looks like an unknown device. Two operational rules follow. Device-based levels are a strong control against unmanaged and lost devices, but not a real-time integrity check, so pair them with endpoint protection that acts locally. And most "why am I blocked?" tickets are sync problems: an extension disabled by the user, a helper app missing, or the user signed into a different Chrome profile from the one that carries the work account.

Access levels: basic and custom

Access levels come in two forms. A basic level is a list of conditions in YAML, combined with AND or OR; each condition can test IP subnetworks or a device policy such as minimum operating-system versions. A custom level is a single expression in CEL, the Common Expression Language, which can test device attributes such as device.encryption_status, device.is_corp_owned_device, device.is_admin_approved_device and vendor compliance flags, the request's origin.region_code and request.time, and other levels through levels.NAME. Everything lives inside one access policy per organization.

# corp_network.yaml: a basic access level is a list of conditions
- ipSubnetworks:
    - 203.0.113.0/25
# supported_os.yaml
- devicePolicy:
    osConstraints:
      - osType: DESKTOP_WINDOWS
        minimumVersion: 10.0.1809
      - osType: DESKTOP_CHROME_OS
        minimumVersion: 11316.165.0

# One access policy per organization holds the levels (create it once)
gcloud access-context-manager policies create --organization=ORG_ID --title="corp policy"

# Basic levels from YAML; --combine-function decides AND or OR across conditions
gcloud access-context-manager levels create corp_network \
  --title="Corporate egress" --basic-level-spec=corp_network.yaml \
  --combine-function=OR --policy=POLICY_ID

gcloud access-context-manager levels create supported_os \
  --title="Supported OS" --basic-level-spec=supported_os.yaml \
  --combine-function=AND --policy=POLICY_ID

# A custom level in CEL, composing the levels above with device attributes
cat > managed_device.yaml <<'EOF'
expression: "levels.supported_os &&
  device.encryption_status == DeviceEncryptionStatus.ENCRYPTED &&
  (device.is_corp_owned_device || device.is_admin_approved_device)"
EOF
gcloud access-context-manager levels create managed_device \
  --title="Managed device" --custom-level-spec=managed_device.yaml --policy=POLICY_ID

Composition through levels. is the feature to build around. Define small, single-purpose levels, such as supported operating system, corporate network and managed device, and compose them into the few levels applications actually reference. Small levels are easier to test and to explain to the person who is blocked, because the failing piece has a name. The operating-system version strings above are the examples from Google's documentation; set your own minimums from your fleet's patch policy, and check the exact attribute names and enum values against the custom access level specification before you copy them, because a typo in CEL is rejected only when you create the level.

A tier ladder that applications can share

Most organizations need three or four tiers, not one per application. A ladder that has worked well looks like this.

# high_trust.yaml: managed device AND on the corporate network or in an approved region
expression: "levels.managed_device &&
  (levels.corp_network || origin.region_code in ['US', 'GB'])"

Each tier is a superset requirement of the one below, which makes the user-facing rule easy to state: "production needs a company laptop, and from outside the approved regions it is blocked". Tie each tier to data classification rather than to the team that owns the application, so a new application is assigned a tier by what it holds.

Enforcement points

For applications behind IAP, a level is attached as an IAM condition on the IAP access role, testing request.auth.access_levels for the level's full resource name, as described in the IAP article. For Workspace and SaaS applications that use Google as the identity provider, the administrator assigns levels to applications for organizational units or groups in the Admin console's Context-Aware Access settings. For Google Cloud APIs themselves, as opposed to applications, access levels can also appear in VPC Service Controls ingress rules, which are covered in VPC Service Controls.

In-browser data protection works differently: it is enforced by Chrome policy on managed browsers and profiles, so it only applies when the user is in the managed Chrome profile. If people can reach the same application from another browser, that path skips every in-browser control. The usual answer is to require a level that only managed Chrome can satisfy for the applications where data controls matter.

Worked example: a rollout that does not lock people out

A 600-person company wants source code and internal dashboards limited to managed devices. The rollout that works is staged.

1. Week 1: deploy Endpoint Verification to everyone, including the helper app through the existing software-management tool, and change no access policy. Measure: after a week, 540 devices are synced, 38 are personal devices and 22 users have never synced.
2. Week 2: create the small levels and the composed managed_device level. Using the inventory, list which users would fail it and why. The answer is 31 unencrypted laptops, 12 outdated Windows builds, the 22 never-synced users and the 38 personal devices. The personal-device owners also have company laptops, so they lose only that access path; fix the fleet and contact the 22 before enforcing anything.
3. Week 3: enforce on a pilot of one team for one application. Because IAM allow policies are additive, a user who is in both the pilot group with a conditional binding and an older group with an unconditional binding still gets in without meeting the level. Remove or narrow the unconditional bindings, or the pilot proves nothing.
4. Week 4 onward: widen by group, one tier at a time, with a published self-service page explaining how to check device status and an on-call contact for blocked users. Keep a small break-glass group with an unconditional binding, protected by strong authentication and alerting on every use.

The arithmetic is the point: enforcing on day one would have fully blocked 65 of 600 people, about 11 percent, most of them for reasons they could not fix themselves, and cut off 38 more from their personal devices without warning.

Failure modes and trade-offs

• Additive IAM bypass. An old unconditional grant silently overrides the new conditional one. Audit bindings on every protected resource before claiming enforcement.
• Stale or missing signals. Blocks for compliant users, and passes for devices that changed since their last sync. Monitor sync age and treat posture as periodic, not live.
• Bypass paths around the proxy. An application that is also reachable directly, by IP or another load balancer, ignores every level. Close those paths first; cloud zero trust lists the usual ones.
• Level sprawl. One level per application becomes impossible to reason about. Keep a small ladder built from composed levels.
• Retired components. Designs that depend on the client connector or app connector are now unsupported.

The trade-off overall is control against friction and dependence. Device-aware access removes the VPN as the gate and makes stolen passwords far less useful, but it ties access to Chrome, to Google's identity and to the health of an endpoint agent. For a deeper discussion of the model independent of any vendor, see zero trust architecture.

What to do next

1. Inventory which of your applications sit behind IAP, which are Workspace or SaaS, and which are reachable some other way.
2. Deploy Endpoint Verification with its helper app and watch sync coverage for a week before writing any policy.
3. Create small single-purpose access levels, then compose three or four tier levels from them with levels.NAME.
4. Assign each application a tier from its data classification and record it.
5. Before enforcing, list who would fail each level and why, and fix the fleet first.
6. Audit IAM bindings for unconditional grants that would bypass the new conditions, and keep a monitored break-glass group.
7. Replace any remaining app connector or client connector dependency, since both are past end of support.