BeyondCorp is a Zero Trust Policy Based Management System framework originally created by Google that shifts Access Controls from the perimeter to individual devices and users.

BeyondCorp Framework real-time authentication and authorization of users, devices and resources.

The end result allows employees to work securely from any location without the need for a traditional VPN.

When a highly sophisticated Advanced Persistent Threat attack named Operation Aurora occurred in 2009, Google began an internal initiative to reimagine their security architecture with regards to how employees and devices access internal applications.

Beyondcorp Architecture

BeyondCorp Google Cloud Platform#

BeyondCorp is now available as a Google Cloud Platform service called Identity Aware Proxy (IAP). IAP uses identity to protect access for applications deployed on GCP. Administrators create policies to determine which user or group identities should have access to GCP-hosted applications.

BeyondCorp Component Architecture #

Beyondcorp Architecture

Trust Evaluation #

Once the incoming records are merged into an aggregate form, the Trust Inferer is notified to trigger re-evaluation of the device. This analysis references a variety of fields and aggregates the results in order to assign a Trust Tier.

The Trust Inferer currently references dozens of fields, both platform-specific and platform agnostic, across various data sources; millions of additional fields are available for analysis as the system continues to evolve.

Beyondcorp Device Evaluation

For example, to qualify for a high Trust Tier, we might require that a device meets all (or more) of the following requirements:

  • Be encrypted
  • Successfully execute all management and configuration agents
  • Install the most recent Operating System security patches
  • Have a consistent state of data from all input sources
This precomputation reduces the amount of data that must be pushed to the gateways, as well as the amount of computation that must be expended at access request time. This step also allows us to be confident that all of our Access Proxy are using a consistent data set. We can make trust changes even for inactive devices at this stage.

For example, in the past, we denied access for any devices that may have been subject to Stagefright before such devices could even make an access request. Precomputation also provides us with an experiment framework in which we can write pre-commit tests to validate changes and canary small-percentage changes to the policy or Trust Inferer without impacting the company as a whole.

Of course, precomputation also has its downsides and can’t be relied on completely. For example, the Access Control Policy may require real-time two-factor authentication, or accesses originating from known-malicious netblocks may be restricted.

Somewhat surprisingly, latency between a policy or device state change and the ability of gateways to enforce this change hasn’t proven problematic. Our update latency is typically less than a second.

The fact that not all information is available to precompute is a more substantial concern.


ScaleFT is a commercial company now provides the BeyondCorp foundation.

More Information#

There might be more information for this subject on one of the following: