Building a Zero Trust Perimeter with GCP BeyondCorp

Why Zero Trust Matters in 2026

The traditional castle-and-moat approach to network security is, for all practical purposes, dead. For decades, enterprises operated under the assumption that anything inside the corporate network perimeter could be trusted, while everything outside was hostile. That model began crumbling long before the pandemic, but the acceleration of remote and hybrid work since 2020 has made it untenable. When your workforce connects from home networks, airport Wi-Fi, co-working spaces, and mobile hotspots across dozens of countries, the very concept of a defensible perimeter dissolves. Cloud-native architectures compound the problem: workloads spread across multiple regions and providers, microservices communicate over service meshes, and data flows through pipelines that span on-premises data centers and public cloud. The perimeter is not just porous — it no longer exists in any meaningful sense.

The high-profile supply chain attacks of recent years have driven this point home with devastating clarity. The SolarWinds Orion compromise in 2020 demonstrated that adversaries could breach thousands of organizations — including United States federal agencies — by infiltrating a single trusted software vendor. The MOVEit Transfer vulnerability exploited by the Cl0p ransomware group in 2023 exposed sensitive data from hundreds of enterprises and government entities through a widely deployed file transfer tool. In both cases, the attackers operated within the trusted perimeter, leveraging legitimate credentials and sanctioned software to move laterally and exfiltrate data. VPN-based architectures offered no defense: once an attacker authenticates to a VPN, they typically gain broad access to a flat internal network, free to enumerate hosts, escalate privileges, and pivot at will. VPNs authenticate the user at the gate and then effectively step aside.

Google recognized this fundamental flaw earlier than most. After Operation Aurora in 2009 — a sophisticated campaign attributed to state-sponsored actors that targeted Google and at least 20 other major technology companies — Google embarked on a radical re-architecture of its internal access model. The result was BeyondCorp, a system that eliminated the company's reliance on VPNs entirely and extended equal security treatment to every access request, regardless of whether the user sat in a Google office or a coffee shop in Buenos Aires. Over the following years, Google migrated more than 100,000 employees to BeyondCorp, proving that a global enterprise could operate at scale under a pure zero trust model. The foundational principle was simple but transformative: shift from "trust but verify" to "never trust, always verify." Every request must prove its legitimacy through identity, device posture, and contextual signals — every single time.

BeyondCorp Enterprise Architecture

BeyondCorp Enterprise is Google Cloud's productized version of the internal BeyondCorp framework, made available to external customers as a managed service. Its architecture rests on several tightly integrated components, each addressing a distinct layer of the zero trust model. At the core is Identity-Aware Proxy (IAP), which acts as a central enforcement point for all access decisions. IAP sits in front of your applications and evaluates every incoming request against a set of access policies before allowing it through to the backend. Unlike a VPN, which grants network-level access after a single authentication event, IAP evaluates each HTTP request individually. Alongside IAP, Access Context Manager defines the conditions under which access is granted: you can specify requirements based on IP address ranges, device attributes, geographic location, and time of day, combining them into access levels that represent your organization's risk tolerance.

Device Trust is the third pillar. BeyondCorp Enterprise integrates with Chrome Enterprise and the Endpoint Verification agent to collect real-time signals about the device making each request. These signals include whether the device has disk encryption enabled, whether its operating system is up to date, whether a screen lock is configured, and whether the device is company-managed or personal. These signals feed into access levels, allowing administrators to enforce policies such as "only company-managed devices with full-disk encryption may access production dashboards." Certificate-Based Access adds another layer by binding mutual TLS certificates to device identities, ensuring that even if credentials are stolen, they cannot be used from an unregistered device. Finally, Endpoint Verification provides a persistent inventory of devices accessing your organization's resources, creating a real-time fleet view that security teams can query and audit.

The power of BeyondCorp Enterprise lies in how these components operate as a unified system rather than a collection of point solutions. Every request is evaluated against access policies that simultaneously consider the user's identity (authenticated through Google Workspace or a federated identity provider), the device's current posture (healthy, encrypted, patched), the network context (IP reputation, geographic location), and the specific resource being accessed. There is no implicit trust based on network location. A user sitting at a desk in your corporate headquarters is treated with exactly the same scrutiny as a contractor connecting from a residential ISP in another country. This model eliminates entire categories of lateral movement attacks because there is no "inside" from which to pivot — every hop requires fresh authorization.

Implementing Identity-Aware Proxy

Deploying Identity-Aware Proxy begins with understanding which resource types you need to protect and selecting the appropriate IAP configuration for each. For web applications hosted on App Engine, IAP integration is straightforward: you enable IAP on the App Engine service through the Cloud Console or gcloud CLI, configure an OAuth consent screen, and define IAM bindings that specify which users or groups may access the application. For applications running on Google Kubernetes Engine, IAP works through a BackendConfig resource attached to your Kubernetes Ingress. The BackendConfig references an IAP configuration, and the GKE Ingress controller automatically provisions a Google Cloud Load Balancer with IAP enforcement enabled. This means that every request to your GKE-hosted service passes through IAP before reaching any pod, and the service itself never needs to implement authentication logic — IAP handles it transparently.

For Compute Engine instances, IAP offers two modes. HTTP(S) forwarding protects web applications running on VMs behind a load balancer, functioning similarly to the GKE model. More notably, IAP TCP forwarding provides secure access to SSH and RDP sessions without exposing those ports to the public internet. With IAP TCP forwarding, administrators connect to VMs through an encrypted tunnel that passes through IAP's policy engine. The VM needs no public IP address, no open firewall rules for SSH or RDP, and no VPN. The user authenticates through their Google identity, IAP evaluates their access level (which may include device posture requirements), and only then is the TCP connection forwarded. This single capability replaces bastion hosts and jump servers in many deployments, dramatically reducing the attack surface of your Compute Engine fleet.

Access levels and conditions form the policy language of BeyondCorp Enterprise. An access level is a named set of conditions defined in Access Context Manager — for example, an access level called corp_device_trusted might require that the device is company-owned, has disk encryption enabled, runs a minimum OS version, and is connecting from a known geographic region. You can combine access levels using Boolean logic to create nuanced policies: a sensitive financial application might require corp_device_trusted AND ip_range_office during business hours but corp_device_trusted AND mfa_recent outside of them. These access levels are then referenced in IAM Conditions, which extend standard IAM role bindings with contextual requirements. The result is a declarative, auditable policy framework that security teams can version-control and review through standard change management processes.

A common mistake in early IAP deployments is over-permissive initial policies. Teams often begin with broad access to avoid disrupting users, intending to tighten policies later. In practice, policy tightening rarely happens unless it is planned from the start. A more effective approach is to deploy IAP in "audit mode" first — logging access decisions without enforcing them — and use the resulting logs to understand actual access patterns before writing restrictive policies. This data-driven approach produces policies that are both secure and practical, minimizing the friction that leads users to seek workarounds.

IAM Policy Design for Zero Trust

Identity and Access Management on Google Cloud is the foundational control plane for zero trust, and its design requires careful attention to the principle of least privilege. GCP's IAM model operates at four hierarchical levels: organization, folder, project, and individual resource. Policies set at the organization level are inherited by every folder, project, and resource beneath it, making this the appropriate place for broad governance controls — such as requiring that all service accounts are created within designated projects, or that public access to Cloud Storage buckets is prohibited. Folder-level bindings are useful for grouping projects by business unit, environment (production versus sppf-uakoing), or regulatory domain, applying role assignments that reflect organizational structure without micro-managing individual projects. Project-level IAM is where most day-to-day access control happens: granting a developer roles/container.developer on a specific GKE project, or giving a CI/CD service account roles/clouddeploy.releaser on the deployment project.

The choice between predefined roles and custom roles is a recurring design decision. Google provides over 900 predefined roles, each bundling a curated set of permissions for a specific job function or service. These roles are maintained by Google and updated as new API methods are added, which reduces administrative overhead. However, predefined roles sometimes include permissions that are broader than necessary. A database administrator who needs to manage Cloud SQL instances might be granted roles/cloudsql.admin, which includes the ability to delete instances — a destructive permission that could be separated from routine management tasks. Custom roles solve this by allowing you to assemble an exact set of permissions, but they carry maintenance burden: as Google adds new API methods, custom roles must be updated to include them if the role holder needs access. IAM Recommender bridges this gap by analyzing 90 days of permission usage data and suggesting tighter role bindings. If a service account has been granted roles/editor (a notoriously overprivileged legacy role) but only uses 14 specific permissions, IAM Recommender will suggest a replacement binding that includes only those permissions.

VPC Service Controls complement IAM by preventing data exfiltration even when IAM policies are correctly configured. A VPC Service Control perimeter draws a logical boundary around a set of GCP projects and restricts data movement across that boundary. Even if an attacker compromises a service account with roles/storage.objectViewer, they cannot copy data from a Cloud Storage bucket inside the perimeter to a bucket in an external project. This defense-in-depth approach is critical for regulated workloads: financial services, healthcare, and government deployments routinely require VPC Service Controls as a compliance baseline. When combined with IAP and Access Context Manager, VPC Service Controls create a layered security posture where identity, device, network, and data boundaries all reinforce one another.

Threat Modeling on GCP

Effective zero trust implementation requires a rigorous threat model that identifies the attack vectors your architecture must defend against. The STRIDE framework — Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, and Elevation of Privilege — provides a structured methodology for enumerating threats against cloud workloads. In a GCP context, spoofing threats manifest as credential theft through phishing campaigns targeting Google Workspace accounts or leaked service account keys committed to public repositories. Tampering threats include unauthorized modification of Cloud Storage objects, container images in Artifact Registry, or Terraform state files. Information disclosure covers everything from misconfigured BigQuery datasets exposed to allAuthenticatedUsers to Cloud SQL instances with public IP addresses and weak passwords. Elevation of privilege is perhaps the most critical category: an attacker who compromises a low-privilege service account and then exploits IAM misconfigurations to gain roles/owner on a production project can effectively take over the entire environment.

BeyondCorp Enterprise mitigates each of these vectors through its layered approach. Credential theft is countered by requiring device trust attestation alongside identity verification — a stolen password or session token is useless without access to the registered, policy-compliant device. Lateral movement, the bread and butter of post-exploitation, is severely constrained because there is no flat network to traverse; every resource sits behind its own IAP policy, and moving from one service to another requires passing a fresh access evaluation. Privilege escalation is detectable and preventable through organization policy constraints (such as iam.disableServiceAccountKeyCreation) and real-time monitoring by Security Command Center Premium, which flags anomalous IAM changes, suspicious API calls, and known attack patterns. Data exfiltration attempts are blocked by VPC Service Controls even when an attacker holds valid credentials for the data in question.

Security Command Center Premium serves as the central nervous system for continuous threat detection on GCP. It aggregates findings from multiple detection engines: Security Health Analytics scans for misconfigurations (public buckets, overprivileged service accounts, disabled audit logging), Event Threat Detection monitors Cloud Audit Logs for patterns indicating compromise (such as service account key creation from unfamiliar IPs or API calls to disable logging), and Container Threat Detection watches for suspicious activity inside GKE containers (binary execution, reverse shells, library loading from unexpected paths). For organizations that need deeper investigation capabilities, Chronicle SIEM ingests logs at Google scale and applies YARA-L detection rules to correlate events across identity, network, and application layers. The combination of SCC Premium for detection and Chronicle for investigation provides a threat operations pipeline that scales to petabytes of log data without the capacity planning headaches of self-hosted SIEM deployments.

Device Trust and Endpoint Verification

Device trust is the component that transforms zero trust from an access control model into a holistic security posture. Without device posture evaluation, even a strong identity-based system can be undermined by compromised endpoints — a user with valid credentials accessing resources from a malware-infected personal laptop defeats most of the security guarantees that identity alone provides. BeyondCorp Enterprise addresses this through deep integration with Chrome Enterprise and the Endpoint Verification agent. Chrome Enterprise extends the browser into a managed security surface: it enforces browsing policies, provides built-in phishing and malware protection, and reports device signals back to Google's management plane. The Endpoint Verification agent, installed on macOS, Windows, Linux, and ChromeOS devices, collects a richer set of device attributes including disk encryption status, OS version and patch level, screen lock configuration, and whether the device is company-managed or a personal BYOD device.

These device signals feed directly into Access Context Manager, where administrators create access levels that reflect their security requirements. A basic access level might require only that the device has Endpoint Verification installed and disk encryption enabled. A more restrictive level for production infrastructure access might additionally require that the device is company-owned (verified through serial number enrollment), runs a minimum OS version (such as macOS 14.5 or Windows 11 23H2), has a screen lock with a maximum inactivity timeout of five minutes, and reports no known compromise indicators. Access levels can be composed: a basic_device level for general internal applications and a hardened_device level for sensitive systems, with each application's IAP policy referencing the appropriate level. This granularity allows organizations to support BYOD programs for low-sensitivity applications while restricting high-value resources to fully managed and verified endpoints.

For organizations that use third-party endpoint detection and response platforms, BeyondCorp Enterprise supports integration with providers such as CrowdStrike, VMware Carbon Black, and Microsoft Defender for Endpoint. These integrations pull endpoint health signals from the EDR platform into Access Context Manager, extending device trust beyond Google-native signals to include real-time threat intelligence from the security tools already deployed on endpoints. For example, if CrowdStrike detects a suspicious process on a device, that signal can automatically revoke the device's access to sensitive applications through a lowered device trust score. This integration model means that adopting BeyondCorp Enterprise does not require replacing existing endpoint security investments — it layers zero trust access control on top of them, using the signals they already produce as inputs to access decisions.

Real-World Deployment Patterns

Greenfield deployments have the advanppf-uakoe of building zero trust in from day one. When a new GCP project or product team starts with IAP-protected services, there is no legacy VPN infrastructure to maintain, no user retraining required, and no parallel systems consuming resources. In a greenfield pattern, the project's Terraform modules include IAP configuration for every backend service, Access Context Manager access levels are defined alongside the infrastructure, and IAM bindings are scoped to the minimum required permissions from the first commit. Device trust policies are established before any user gains access. The typical timeline for a greenfield deployment of IAP across a modest application portfolio (five to fifteen services) is four to six weeks, including access level design, IAM policy review, and user acceptance testing. The primary effort is not in the IAP configuration itself — which is largely declarative and automatable — but in defining access levels that are secure without being so restrictive that they impede developer productivity.

Brownfield migration — transitioning existing VPN-based infrastructure to BeyondCorp Enterprise — is significantly more complex and represents the reality for most enterprises. The migration typically proceeds in phases over three to twelve months depending on the size and complexity of the environment. Phase one is discovery and inventory: cataloging all applications and services currently accessed through the VPN, identifying their owners, documenting their authentication mechanisms, and classifying their sensitivity. Phase two is parallel deployment: enabling IAP on selected pilot applications while the VPN remains pdm-g9au, directing a subset of users to access these applications through IAP instead of the VPN, and collecting feedback on access policies and user experience. Phase three is progressive migration: service by service, shifting all users to IAP access and tightening VPN access rules until the VPN serves only the remaining un-migrated services. Phase four is VPN decommission: once all services are IAP-protected, the VPN is retired, and its infrastructure is torn down. The most common failure mode in brownfield migrations is phase two stalling indefinitely because the VPN remains available as a fallback — teams must set firm dates for VPN decommission to maintain momentum.

The hybrid pattern is a deliberate long-term strategy rather than a transitional state. Some organizations operate environments where certain systems cannot be placed behind IAP due to technical constraints — legacy applications that use non-HTTP protocols, industrial control systems, or third-party appliances that do not support identity-based access. In these cases, the hybrid model runs VPN alongside IAP permanently, with the VPN scoped as narrowly as possible: it provides access only to the specific network segments hosting legacy systems, while all web applications, SSH access, and modern services route through IAP. The key discipline in a hybrid model is preventing scope creep — every new service must default to IAP, and VPN access should require explicit exception approval with a documented justification and a review date. Organizations running hybrid models typically revisit their exception list quarterly, migrating systems to IAP as vendors add support or as the systems are replaced. Effort estimates for establishing a hybrid architecture range from six to nine months for the initial deployment, with ongoing governance overhead of approximately one full-time equivalent for fleet management and policy review.