BeyondCorp: Design to Deployment at Google

Introduction

Imagine a traditional office building where security guards check your ID at the entrance, and once you're inside, you can freely walk around and access most rooms. That's essentially how traditional corporate networks work - they use a "perimeter security" model where you connect through a VPN (Virtual Private Network), and once you're "inside" the network, you're largely trusted.

BeyondCorp is Google's implementation of a Zero Trust Network - a fundamentally different approach. Instead of trusting everyone inside the network perimeter, Zero Trust assumes that threats can come from anywhere, even from inside the organization. Every access request is verified, regardless of where it comes from.

Why does this matter? In today's world, employees work from coffee shops, home offices, and airports. Cloud services mean company data isn't just sitting in one office building anymore. The old "castle and moat" approach to security - where you're safe once you cross the drawbridge - no longer works.

What Problem Does BeyondCorp Solve?

The goal of Google's BeyondCorp initiative is to improve security for how employees and devices access internal applications. Here's the key difference from traditional security:

Traditional Approach (Perimeter Security):

• Access is granted based on your location (are you on the corporate network?)
• Use a VPN to connect to the office network
• Once connected, you're generally trusted to access most internal resources

BeyondCorp Approach (Zero Trust):

• Access is granted based on who you are and what device you're using
• Your physical location doesn't matter - whether you're in the office or at a coffee shop
• Both internal and external networks are treated as equally untrusted
• Every access request is individually verified based on "trust tiers" - security levels that determine what resources you can access

Think of it like this: instead of checking your ID once at the building entrance, imagine every room requiring its own verification based on who you are, what device you're using, and how secure that device is.

How BeyondCorp Works: Architecture Overview

BeyondCorp is built from several interconnected components that work together to make access decisions. Here's what each piece does:

1. Trust Tiers

Think of these as security clearance levels. Just like government agencies have "Confidential," "Secret," and "Top Secret" classifications, BeyondCorp organizes access requirements into tiers representing increasing levels of sensitivity. A basic tier might access email, while a higher tier might access production systems or sensitive customer data.

2. Resources

This is simply a catalog of everything that needs access control: all the applications, services, and infrastructure in Google's environment. Every internal tool, database, and service is inventoried here.

3. Trust Inferer

This is the "smart analyzer" that continuously watches your device. It asks questions like:

• Is your operating system up to date?
• Is your antivirus running?
• Are you using an approved device?
• Is your device encrypted?

Based on these factors, it assigns your device a trust tier (how much should we trust this device?) and determines which network segments (VLANs) it can access.

4. Access Policy

This is the rulebook - a programmatic set of rules that defines who can access what. It combines information about the resource being requested, required trust tiers, and other conditions that must be met for access to be granted.

5. Access Control Engine

This is the decision maker. It's a centralized service that answers one simple question: "Should this access request be allowed - yes or no?" It makes this decision by consulting:

• The access policy rules
• The Trust Inferer's assessment of the device
• The specific resource being requested
• Real-time user credentials

6. Device Inventory Service

This service maintains a living database of all known devices in the organization. It continuously collects information about devices, processes it, and updates the system when things change (like when a device gets a security update or falls out of compliance).

7. Gateways

These are the entry points where access actually happens. They include SSH servers (for command-line access), web proxies (for accessing web applications), and 802.1x-enabled networks (for network access). Each gateway enforces the decisions made by the Access Control Engine - checking trust tiers, authenticating users, and assigning network access.

Key Implementation Insights

Here are some fascinating details about how Google actually deployed BeyondCorp in practice:

Security Gets Tighter as Stakes Get Higher

The more sensitive the data you're accessing, the more frequently the system checks that you're still at your device. This means higher-trust devices actually get shorter-lived credentials. It's counterintuitive but clever: if you're accessing the most critical systems, we want to verify more often that it's really still you at the keyboard, not someone who stole your laptop.

Network Segmentation Based on Device Health

The Trust Inferer doesn't just assign trust tiers - it also controls which parts of the network (VLANs) your device can access. This allows Google to isolate special environments like lab and test networks, granting access only to devices in the right state. For example, a contractor's laptop might be blocked from development networks even if the user has valid credentials.

The Data Correlation Challenge

One of the trickiest parts of implementing BeyondCorp is combining information from different sources into a single, coherent view of each device. Google's infrastructure has many systems tracking devices (asset management, security tools, network logs, etc.), and they often don't use the same identifiers. Figuring out that "John's MacBook" in one system is the same device as "Device-12345" in another system is surprisingly complex.

Faster Than You'd Think

You might expect delays between when a policy changes (or a device state changes) and when that change takes effect across all gateways. Surprisingly, this hasn't been a problem - updates typically propagate in less than a second. The bigger challenge is that not all information can be precomputed, so some decisions need to happen in real-time.

Digital Certificates as Device IDs

To solve the correlation problem, Google uses X.509 certificates (the same technology that secures HTTPS websites) as a persistent identifier for each device. This certificate serves two purposes:

1. It provides a cryptographically secure, globally unique ID (GUID) that never changes
2. It enables encryption of network traffic

However, the certificate alone isn't enough to grant access - it's just a reliable way to consistently identify devices across all systems. You still need proper authentication and authorization.

Mobile Apps Get the Same Treatment

Native mobile apps (like a company chat app on your phone) aren't treated any differently than web applications. They make API calls to backend services, and those API endpoints sit behind proxies integrated with the Access Control Engine. Every request is checked, whether it comes from a browser or a mobile app.

The Complexity of Exceptions

Like any large system rollout, BeyondCorp needed an exception process for edge cases and migration issues. However, this has led to increased complexity over time. When someone is denied access, the answer to "why?" has become less obvious because there are more factors at play - trust tiers, device state, policy rules, and potential exceptions.

Change Management Challenges

Rolling out BeyondCorp wasn't just a technical challenge - it was a people challenge:

• Over-communication problems: Users who resist change tend to overestimate the impact and request unnecessary exemptions, creating extra work
• Confusion with other changes: Google's infrastructure is always evolving. When users hit access issues, they sometimes blame BeyondCorp when the real problem is something else entirely. This confusion slows down troubleshooting and increases support burden.

Key Takeaways

BeyondCorp represents a fundamental shift in how we think about corporate security:

1. Location doesn't equal trust: Just because you're on the corporate network doesn't mean you should be trusted by default
2. Device health matters: Your device's security posture (is it patched? encrypted? managed?) becomes a key factor in access decisions
3. Continuous verification: Instead of checking credentials once, the system continuously evaluates whether access should continue
4. Implementation is complex: The technical architecture is sophisticated, but the human and organizational challenges (change management, support, exceptions) are equally important

For companies considering Zero Trust, BeyondCorp provides a real-world blueprint - including both the successes and the challenges Google encountered during their multi-year rollout.

Read the Full Paper

• Original PDF
• Annotated copy

---

Over the next few Saturdays, I'll be going through some of the foundational papers in Computer Science, and publishing my notes here. This is #5 in this series.