Over the past few years, Google has been moving away from VPN-based security for our employees, and towards a trust model that’s based on people and devices, rather than networks. We call it BeyondCorp—moving beyond a corporate network for internal services and applications. It’s the basis for Cloud Identity-Aware Proxy, which can be used to authenticate users for applications running on Google Cloud Platform.

We recently published our fifth research paper on BeyondCorp, this time focused on the employee experience—how they first end up using this system, and what it looks like when things go wrong. We discuss how onboarding has gotten easier with no VPN, how loaners are quick to activate, and how we give employees the ability to handle and resolve their own issues when the Chrome extension is getting in their way.

When new employees join Google, access is based on machines and identity, not the network. We tell them about our access policy: you can get to the tools you need no matter where you are, so long as you’re on your corporate issued laptop (a slight oversimplification, I’ll admit). As we prepare their computers for delivery on their first day at work, we make sure our inventory provisioning procedures add the devices to our asset management system and assign an owner. Then, when each employee signs into their own machine, we kick off automated requests for machine certificates. These are used to guide the machine to the right VLAN. This onboarding process streamlines our new device setup, and eliminates the need to install VPN software on each employee’s laptop.

After their first day, the most interaction employees will have with BeyondCorp is through a Chrome extension, which shows the current status of their connection. This gives our IT teams and end users a way to find errors, troubleshoot and fix them quickly. Anyone can turn the proxy off manually using the extension—a common need when using captive portals or local network hardware.

The latest paper also discusses how we expose details about denial of access. While we want to make sure our employees, and the service desk assisting them, can quickly resolve access errors, we also need to make sure we don’t expose too much data to attackers in the way we say “nope, not allowed” to some requests. Building this explanation engine helped us troubleshoot BeyondCorp as we deployed more broadly, and it gave our troubleshooting teams insight into what’s going wrong when someone reports an unexpected access denied message.

BeyondCorp has helped us streamline the onboarding process, and given employees the tools they need to fix problems when things go wrong. We hope it will inspire you as well. You can read the research paper on Research at Google.