Skip to content

BeyondCorp and zero trust: an overview

A 2021 client presentation on replacing network-perimeter trust with device identity, user identity, access proxies, and per-request authorization.

Held
Event
Client Presentation
Location
Online

BeyondCorp · zero trust · security

Google's BeyondCorp model removes implicit trust from the corporate network. It identifies each person and device, exposes services through access proxies, and evaluates authorization for every request.

Presentation

Download slides (PDF) ↓

Notes

I delivered this overview online for a client on February 10, 2021. The eleven-slide deck condenses Google’s published BeyondCorp papers. It is an introduction to the model, not a report of a client implementation.

Why the network perimeter stops working

The deck starts with the traditional “moated fortress”: employees work in offices, internal services sit behind a trusted network, and outside users receive narrow public interfaces. That boundary becomes harder to defend as an organization adds cloud services, branches, partners, remote workers, and external specialists.

A network location also grants more trust than most work requires. Teams compensate by adding more perimeters, authentication systems, and temporary exceptions. Those layers slow onboarding and cross-team work, while a breach inside one perimeter can expose every service behind it.

The BeyondCorp model

BeyondCorp moves the access decision away from network location. The model in the deck has four parts:

  • The organization identifies people through a central user and group system connected to its employment records.
  • It identifies devices through an inventory, recorded device state, and certificates.
  • It exposes services over public DNS and HTTPS through internet-facing access proxies.
  • An access-control engine evaluates the person, device, groups, service, and other policy inputs for each request.

This is still a trust model. It replaces the broad fact that a client is “inside” with narrower, continuously updated evidence about who is requesting access, which device they use, and what the policy permits.

How a request is evaluated

A person initiates a request from an identified device and completes the required authentication. The access proxy asks the access-control engine whether that person and device may use the requested service. The engine evaluates current data from the user, group, and device systems. Only an authorized request reaches the service.

The service therefore does not rely on a VPN connection as proof of identity. The proxy and policy engine make the authorization decision at the point of access, and roles can limit the grant to the function the person needs.

Working with external collaborators

This model changes external onboarding too. A company can enroll a managed device or evaluate a personal device with more limited policy inputs. Central access control then governs onboarding and removal without placing the collaborator inside a broad network perimeter.

The deck argues for small teams that work with the rest of the organization rather than building isolated systems. New services should use the same identity, group, and access-proxy systems early. Rapid prototypes remain possible, but their route into the existing security model should be explicit.

I revisit this request-based model in BeyondCorp in the age of AI agents, where one human instruction can become many tool calls under delegated authority.

Sources used for the presentation