Beyond Corp – Google’s approach to enterprise security

What is Beyond Corp?

Beyond corp is a concept which was developed and is used by Google and is by now adopted by some other companies. The idea behind it was to get away from the intranet and its perimeter defense, where, if you breach the perimeter you can access much of the enterprise data. With Beyond Corp, your enterprise applications are not hidden behind a perimeter defense but are instead deployed to the internet, only accessible via a centralized access proxy. With the deployment of the enterprise applications to the internet, Google establishes a zero trust policy – anyone no matter from which IP tries to access a enterprise application has to have sufficient rights, determined through device and user data.

The trigger for this to happen was the “Operation Aurora” in 2009, an advanced persistent threat (APT) supposedly originating from China, where data from Google and around 35 other companies in the USA was stolen. Since you wont detect an APT through monitoring, because the many single steps in themselves are uncritical and hard to relate if the attackers take their time (talking about several weeks), but are easy to achieve once you entered the intranet successfully,  Google decided to start the Beyond Corp project to find a more secure architecture for their enterprise.


Components of the beyond corp infrastructure

Securely identifying the device

Device Inventory Database & Device Identity

Beyond corp uses the concept of “managed devices”. A managed device is managed, maintained and monitored by the enterprise IT. It has to have an entry in the device inventory database and receives a “managed device certificate” after fulfilling several security requirements. Only managed devices can access corporate applications. The certificate provides the device identity to the system, is renewed periodically if the device fulfills the security requirements or is revoked if it doesn’t. The certificate itself doesn’t provide any access rights, it only servers as key for a set of information about the device which is stored in the device inventory database like patch and installation history.


Securely identifying the user

User and group database

The user and group database is closely connected to the HR management and stores data about (as the name suggests it) users and groups.It provides processes for managing job categories, usernames and group memberships, needs to be updated whenever an employee leaves or a new one starts working at the enterprise and gives all demanded information about a user that wants to access enterprise resources to the beyond-corp system.

Single sign on

The single sign on system only works for specific resources and usually provides a short living token, depending on the trust tier the respective device and user is given.


Removing trust from the network

Deployment of an unprivileged network

A core concept of Beyond Corp is the zero trust policy and with it the deployment of an unprivileged network. This network is physically inside the google enterprise and connects managed devices to the internet and limited infrastructure services (DNS, DHCP, NTP, …). Devices which aren’t managed devices or don’t have a sufficient trust level, are instead connected to a guest network. To authenticate to the unprivileged network a 802.1x authentication with several RADIUS servers is used. The authentication is able to dynamically handle authentications instead of a switch with a static configuration. It can also tell the switch to which appropriate network (VLAN) to connect the managed device to.


The Access Proxy

All Google enterprise applications are exposed to internal and external clients through the access proxy. This access proxy enforces encryption between client and application and servers as a reverse proxy. It has to be configured for each application which is exposed through it. The configuration contains rules which are used to determine if a device is provided with access to the application. The access proxy also contains common features like global reachability, load balancing, access control, application health checks, and DDOS protection.


Inventory based access control

Trust Inference for devices and users

As mentioned before Beyond Corp works with a so called “trust level” or “trust tier”. This is the level of access a device or user is given and is dynamically determined through monitoring and interrogating of multiple data sources from the databases (device inventory and user and group database) and the managed device certificate. The level of trust given to a user or device can change over time and is determined by the “Trust Inference” which can also use data like the access location of the device and its patch level.

Pipeline into the Access-Control Engine

The Pipeline component provides the data for the access control engine decision making. It accumulates data like the trust tier of user and device, and inventory details about the user, his group and the device he does the request with. It also holds a certificate whitelist.

The pipeline divides the data it receives into two categories:

Observed Data (programmatically generated):

Observed data is the data the Beyond Corp system generates when a device requests a resource behind the access proxy. It is data that periodically changes like the user operating system (its version), installed software, the last time a security scan was performed and what its result was.

Prescribed Data (manually maintained by IT Operations)

Prescribed data is the data the Beyond Corp system could access at any time because it is stored in the databases. This data is maintained by the IT department. Prescribed data is for exampled the assigned owner of a device, users and groups allowed to access a device and explicit access to particular VLANs in the unprivileged network.


If there are differences in the data, the system tries to merge the records for the device, or create a new one if it hasn’t any records already. Since merging records could mean, that there is new data about the device available, the trust inference has to evaluate the trust level again. After the information is evaluated, overrides like whitelists are applied and the data is passed to the access control engine.

Access Control Engine

The Access Control Engine is  usually physically located in the access proxy and decides if a device receives access to the requested resource or not. The decision made is based on the trust tier, which the trust inference defined, the configuration of the access proxy for the respective application, which defines the rules that needs to be fulfilled to receive access and data from the databases and certificate, which need to match the requirements of the access proxy configuration. It is also possible to give partial access to an application (like only show data lists and hide more critical things like search boxes).


The challenges of migrating from a intranet enterprise network to the Beyond Corp system and using it are different in origin and effect. To start off: the migration from an in years developed and grown intranet to beyond corp is most likely a immense challenge in itself. Furthermore, incorrect data about devices might enter the network and have to be filtered out by putting effort in maintaining the device inventory database.

Another challenge would be if device records get corrupted because components withing the device change (like motherboards), which have then to be resolved yet again by a maintaining instances. Since the Beyond Corp system is in charge of a smart and real time decision making system, that decides if a device can access the required resource or not, it is important to have a disaster recovery, so that in any case it is possible to regain control about the system.

Another challenge of the Beyond Corp system is to integrate a  user friendly but yet secure user experience.



There are several advantages the Beyond Corp system has over classic intranet systems. It is way harder for anyone to be able to do identity phishing with the beyond corp system because the authentication process is tied to the devices, so it isn’t enough to phish a username/password combination, you’d also have to get a managed device with a valid certificate that isn’t marked as stolen in the system.

Since the Beyond Corp system is accessible via internet there is no more VPN for i.e. home office needed, reducing the effort for the IT department which doesn’t have to set up any more VPN connections to the intranet.

Several other advantages evolve around the fact, that the Beyond Corp system does real-time trust evaluation, intelligent decision making and enforces security controls for user and devices. The last advantage I want to mention is that since all enterprise application are exposed via the access proxy, it is a single point that has to be focused on securing. Of course this might also be a disadvantage since any mistakes made in the configuration of the access proxy might affect all applications.



Beyond Corp has many advantages compared to the classic intranet approach and is, in a time of excessive usage of mobile devices and home office, the right step going into the future. I can see many enterprises never migrating to BeyondCorp because of old legacy applications that cannot really be imported into the new system. The migration is an immense task, that is most likely harder with a bigger enterprise. That aside, Beyond Corp solves many of the intranet’s security and usability problems and isn’t restricted to a physical space, which eases the remote access because you no longer need to set up a VPN access.


Possible Research Questions

How to secure the access proxy? / Access proxy as most vulnerable part of Beyond Corp?

As spoken about in the advantage section, the access proxy is the core to secure in the Beyond Corp System. So how can we secure it correctly? What should we focus on when setting it up, and what are things you might not think about, but could turn out to be crucial. Furthermore, how can you assure that the prescribed data (like the whitelist) hasn’t been corrupted at some point?

How to hack Beyond Corp? / Social engineering vs. Beyond Corp?

It is a fact, that no system (with everyday usage by persons) is perfectly secure and cannot be hacked if you have enough skill and knowledge about the system. So how could you approach to hack a Beyond Corp system? Would it be enough to convince someone with your social engineering skills to hand over his or her device without flagging it as stolen for a longer period of time? Where is the most valuable enterprise data you want to access and what are the steps to get there?

How does Beyond Corp work with IoT?

Since all devices accessing the enterprise applications have to provide a managed certificate, how could the Internet of things work with a Beyond Corp system? Many devices of the IoT aren’t capable of providing a certificate so would it be a correct approach to just whitelist all of those devices? How would that impact enterprise security?



If you are interested in informing you further about Beyond Corp, have a read at some of the sources. The Google documentation are well written and quite easy to understand and give a good insight into their approach to it. The other sources I used are mostly blogs which describe the subject from a different perspective and help to not get lost in Google’s shiny world of their own technology.

Google Sources:

Beyond Corp: The Access Proxy

Beyond Corp – A New Approach To Enterprise Security

Beyond Corp: Design To Deployment At Google

Migrating To Beyond Corp: Maintaining Productivity While Improving Security

Beyond Corp: The User Experience

Beyond Corp


Other Sources

thinkst thoughts – Farseeing: a look at Beyond Corp

The Newstack – Beyond Corp: How Google ditched VPNs for remote employee access

DZone – Fundamentals of the Beyond Corp ‘Zero Trust’ Security Framework