This chapter covers Google's BeyondCorp Zero Trust security model, which replaces traditional VPN-based network security with identity- and device-centric access controls. For the GCDL exam (Objective 2.5), this topic appears in approximately 5–8% of questions, focusing on understanding the core principles, components, and how it differs from perimeter-based security. You will learn the architecture, key mechanisms, and real-world deployment considerations that the exam tests.
Jump to a section
Imagine a company's office building. In the traditional VPN model, the building has a single guarded entrance (the VPN gateway). Everyone must pass through this entrance, show their badge (authenticate), and then they can roam freely inside (access any internal resource). The guard trusts anyone inside the building. BeyondCorp inverts this: there is no guarded entrance at all. Instead, every single door inside the building (every application, server, file) has its own biometric scanner. To open any door, you must present your identity and device credentials right there, regardless of whether you are inside or outside the building. The building itself is treated as hostile—any door can be attacked. So even if you are already in the lobby, you still need to scan your fingerprint to enter the server room. This is the Zero Trust principle: never trust the network location, always verify identity and device health at every access request. Google's implementation uses a central policy engine (the Access Proxy) that acts like a universal door controller: it checks user identity (via SSO), device inventory (via device management), and context (like IP reputation) before allowing access to any resource. The old VPN gateways are replaced by this proxy, which sits in front of every application and enforces policy per request.
What is BeyondCorp and Why Does It Exist?
BeyondCorp is Google's implementation of the Zero Trust security model, first detailed in a series of papers starting in 2014. Traditional network security relies on a strong perimeter: firewalls and VPN gateways protect internal resources, and once inside the network, users are implicitly trusted. This model fails when attackers breach the perimeter (e.g., via phishing, malware) or when users access resources from untrusted networks (e.g., coffee shop Wi-Fi).
BeyondCorp eliminates the concept of a trusted internal network. It treats every access request as originating from an untrusted network, regardless of the user's location. Access decisions are based on: - User identity: Authenticated via single sign-on (SSO) and multi-factor authentication (MFA). - Device identity and health: The device must be known, managed, and compliant with security policies (e.g., OS version, disk encryption, antivirus). - Context: Factors like IP address, geolocation, time of day, and behavior patterns.
How BeyondCorp Works Internally
Google's BeyondCorp architecture consists of several key components that work together to enforce access control at the application layer, not the network layer.
#### 1. Access Proxy (Google's Identity-Aware Proxy - IAP)
The Access Proxy is the core enforcement point. It sits in front of every internal application and intercepts all HTTP/S requests. When a user tries to access an application, the proxy:
Terminates the TLS connection.
Redirects the user to authenticate via Google's SSO (OAuth 2.0 / OpenID Connect).
After authentication, the proxy obtains identity and context tokens.
It then evaluates access policy (defined in the policy engine) based on user, device, and context.
If allowed, it proxies the request to the backend application, optionally re-encrypting TLS.
The proxy is stateless and horizontally scalable. It does not require any changes to backend applications—they see the proxy as the client. Google uses a global HTTP(S) load balancer with IAP enabled, which is available as a GCP service.
#### 2. Policy Engine (Context-Aware Access)
The policy engine evaluates access rules. Policies are written in a structured format (e.g., YAML) and can include conditions such as:
- user.email == "user@example.com"
- device.os_version >= "10.15"
- request.ip in ["203.0.113.0/24"]
- access_levels: ["MFA_REQUIRED", "CORPORATE_DEVICE"]
Policies are evaluated per request. The engine returns a decision (allow/deny) along with optional context (e.g., session duration). Default deny is enforced—if no policy matches, access is denied.
#### 3. Device Inventory and Management
Every device that accesses corporate resources must be registered in a device inventory system. Google uses its own device management (Endpoint Verification) that integrates with MDM/UEM solutions like Jamf, MobileIron, or Google's own device management. The device must report:
Device ID (unique hardware identifier)
OS type and version
Patch level
Disk encryption status
Presence of security software
This information is cryptographically attested via client certificates or TPM (Trusted Platform Module). The inventory is continuously updated; if a device falls out of compliance (e.g., missing a security patch), its access is revoked in near real-time.
#### 4. Certificate Authority and Client Certificates
Each managed device receives a client certificate from Google's internal CA. This certificate is used for TLS mutual authentication between the device and the Access Proxy. The certificate is bound to the device's hardware identity (e.g., using key attestation on Android or iOS, or TPM on Windows). The certificate lifecycle: - Issuance: On device enrollment, the device generates a key pair and sends a CSR to the CA. The CA verifies device ownership and issues a certificate with a typical validity of 1–2 years. - Renewal: The device automatically renews before expiry. If renewal fails (e.g., device is out of compliance), the certificate is revoked. - Revocation: If a device is lost or compromised, the admin revokes its certificate via the device management console. Revocation propagates within minutes via CRL or OCSP.
#### 5. Single Sign-On (SSO) and Multi-Factor Authentication (MFA)
Authentication is handled by Google's identity platform (Cloud Identity or Workspace). The Access Proxy redirects unauthenticated users to the SSO login page. MFA is enforced based on policy (e.g., always for sensitive apps, or only from untrusted networks). The authentication tokens (OAuth 2.0 access tokens) are short-lived (default 1 hour) and must be refreshed.
Key Values, Defaults, and Timers
Session timeout: Default 1 hour for access tokens. Can be configured from 15 minutes to 24 hours.
Device compliance check interval: Every 15 minutes by default. Device must report compliance; if not, access is blocked on next request.
Certificate validity: 1 year for device certificates, renewable.
Policy evaluation cache: Decisions are cached for 5 minutes by default to reduce latency, but can be set to 0 for real-time enforcement.
IAP OAuth client ID: Each IAP-secured app has a unique OAuth 2.0 client ID; the client secret is stored in the proxy configuration.
Configuration and Verification Commands (GCP)
For Google Cloud's Identity-Aware Proxy (IAP), which is the commercial implementation of BeyondCorp principles, typical configuration steps:
1. Enable IAP on a backend service:
gcloud iap web enable --resource-type=backend-services \
--service=BACKEND_SERVICE_NAME --oauth2-client-id=CLIENT_ID \
--oauth2-client-secret=CLIENT_SECRET2. Create an access policy (context-aware access):
gcloud iap web add-iam-policy-binding --resource-type=backend-services \
--service=BACKEND_SERVICE_NAME --member=user:alice@example.com \
--role=roles/iap.httpsResourceAccessor3. Verify IAP status:
gcloud iap web get-iam-policy --resource-type=backend-services \
--service=BACKEND_SERVICE_NAMECheck device compliance (Endpoint Verification):
User must install the Endpoint Verification Chrome extension or mobile app. The device status is visible in the admin console under "Devices".
Interaction with Related Technologies
BeyondCorp works alongside: - VPC Service Controls: To prevent data exfiltration from Google Cloud services even if access is allowed. - Cloud Identity-Aware Proxy (IAP): The direct GCP service that implements BeyondCorp for web applications and VMs (via SSH/RDP over IAP). - Access Transparency: Logs all access to customer data by Google support personnel, complementing the Zero Trust model. - BeyondCorp Remote Access: A newer product that extends Zero Trust to non-web applications (e.g., SSH, RDP) using a client-side connector.
User Requests Application Access
A user opens a browser and navigates to an internal application URL (e.g., `https://internal-app.example.com`). The DNS resolves to the IP of the Access Proxy (Google's IAP). The browser sends an HTTP GET request. The proxy terminates the TLS connection and checks for an existing session cookie. If none exists, it returns a 302 redirect to the SSO login page.
Authentication via SSO
The user is redirected to Google's SSO page (e.g., accounts.google.com). The user enters credentials and, if required, completes MFA (e.g., a TOTP code or push notification). Upon successful authentication, Google's identity platform issues an authorization code and redirects back to the Access Proxy with the code. The proxy exchanges the code for an access token (OAuth 2.0) and an ID token (OpenID Connect). The access token has a default lifetime of 1 hour.
Device Identity and Health Check
The Access Proxy now needs device information. The user's device has a client certificate installed (from device enrollment). The proxy requests TLS mutual authentication: the device presents its certificate. The proxy validates the certificate against the internal CA, checks revocation status (via OCSP), and extracts the device ID. The proxy queries the device inventory service to check compliance: OS version, patch level, encryption status, and last check-in time (must be within 15 minutes). If the device is non-compliant or unknown, access is denied.
Policy Evaluation
With user identity (from ID token), device ID and health, and request context (source IP, time, geolocation), the proxy assembles an access request to the policy engine. The policy engine evaluates the request against all applicable policies. For example, a policy might state: `allow if user in group 'engineering' AND device.os == 'macOS' AND device.disk_encrypted == true`. The engine returns an allow/deny decision. If no policy matches, default deny applies. The decision is cached for 5 minutes.
Access Granted or Denied
If allowed, the proxy forwards the request to the backend application. It sets a session cookie for future requests (valid for 1 hour or until policy change). The backend sees the request as coming from the proxy's IP, not the user's, because the proxy acts as a reverse proxy. The proxy can optionally inject the user identity into HTTP headers (e.g., `X-Goog-Authenticated-User-Email`). If denied, the proxy returns an HTTP 403 Forbidden page with a reason (e.g., 'Device not compliant').
Enterprise Scenario 1: Remote Workforce Access to Internal Web Apps
A large enterprise with 10,000 employees previously used a VPN concentrator (e.g., Cisco ASA) for remote access. Every remote user had to install VPN client software, connect to the corporate network, and then access internal web applications. This model had several pain points: VPN capacity planning (peak concurrent users), poor user experience (slow, drops), and security risks (once on VPN, users had broad network access). The enterprise migrated to Google's IAP (BeyondCorp model). They deployed IAP on their internal web apps (e.g., HR portal, Jira, Confluence) hosted on GCP and on-premises (via hybrid connectivity). Users no longer need VPN; they simply browse to the app URL, authenticate via SSO (with MFA), and their device must be managed (via endpoint management). The result: eliminated VPN infrastructure, reduced helpdesk tickets (no more VPN connectivity issues), and improved security because access is per-app and device health is enforced. Performance consideration: IAP adds ~50–100ms latency per request due to authentication and policy checks, but this is acceptable for web apps. Common misconfiguration: forgetting to set up OAuth consent screen or not rotating client secrets, causing authentication failures.
Enterprise Scenario 2: SSH Access to Compute Instances
A DevOps team needed secure SSH access to thousands of VMs in GCP without using bastion hosts or VPNs. They used IAP TCP forwarding (part of BeyondCorp). The engineer runs: gcloud compute ssh INSTANCE_NAME --tunnel-through-iap. This command establishes a TCP tunnel through IAP: the gcloud CLI authenticates the user, checks device compliance, and then creates a secure WebSocket connection to the IAP proxy, which forwards traffic to the VM's SSH port (22). No public IP is needed on the VM; only IAP's IP range (35.235.240.0/20) must be allowed in the firewall. This eliminates the need for jump boxes and reduces attack surface. At scale, IAP TCP forwarding handles thousands of concurrent tunnels, but each tunnel consumes resources on the proxy; Google recommends using a load balancer for high availability. Common issue: if the user's device does not have the gcloud CLI configured with the correct OAuth2 client, authentication fails. Also, the VM must have the IAP firewall rule enabled; otherwise, the connection times out.
Scenario 3: Third-Party Contractor Access
A company needed to give limited access to external contractors (e.g., for a specific app) without giving them VPN access. They created a separate Cloud Identity directory for contractors, enrolled their devices (BYOD) with minimal management (only require disk encryption and antivirus). They configured IAP with context-aware access: allow only from specific IP ranges (e.g., contractor office), require MFA, and restrict to one app. This ensures contractors cannot pivot to other resources. Misconfiguration risk: if the policy is too broad (e.g., allow all users in a group), contractors could access other apps. Also, if device compliance is not enforced, a contractor's compromised device could access the app.
What GCDL Tests on BeyondCorp (Objective 2.5)
The GCDL exam focuses on conceptual understanding, not implementation details. You need to know:
The core principle: never trust the network, always verify identity and device.
The difference from VPN/perimeter security.
The key components: Access Proxy (IAP), policy engine, device inventory.
The benefits: no VPN, per-application access, device health enforcement.
Common Wrong Answers and Why They Are Wrong
"BeyondCorp is a VPN replacement that still uses network segmentation." – Wrong. BeyondCorp eliminates network-level trust; it does not rely on network segments. Access is based on identity and device, not IP address ranges.
"BeyondCorp requires all applications to be rewritten to support OAuth." – Wrong. The Access Proxy (IAP) works with any HTTP/S application without code changes. The proxy handles authentication and policy enforcement transparently.
"BeyondCorp only works within Google Cloud." – Wrong. BeyondCorp is a model; Google's implementation (IAP) works for both GCP and on-premises apps via hybrid connectivity. The principles can be applied using third-party tools as well.
"BeyondCorp eliminates the need for firewalls." – Wrong. Firewalls are still needed for network-level security (e.g., blocking DDoS, restricting ports). BeyondCorp adds a layer of application-level access control.
Specific Numbers and Terms That Appear on the Exam
"Identity-Aware Proxy (IAP)" – The GCP service that implements BeyondCorp.
"Context-aware access" – The policy engine that evaluates user, device, and request context.
"Default deny" – If no policy matches, access is denied.
"Device inventory" – Must be managed and compliant.
"No VPN required" – Key benefit.
"Per-application access" – Not network-level.
Edge Cases and Exceptions
Non-web applications: IAP TCP forwarding handles SSH/RDP, but for other protocols, you may need a client connector (BeyondCorp Remote Access).
Legacy applications: Some apps may not support HTTP headers for identity; IAP can inject headers, but the app must trust them.
Offline access: If the policy engine is unreachable, cached decisions (5-minute TTL) allow continued access temporarily.
How to Eliminate Wrong Answers
If an answer mentions "network segmentation" or "IP-based access control", it is likely wrong.
If an answer says "requires application changes", it is wrong for IAP.
If an answer says "replaces all security", it is wrong – BeyondCorp is one layer.
Look for keywords: identity, device, context, proxy, per-application.
BeyondCorp is Google's Zero Trust model: never trust the network, always verify identity and device.
The core component is the Access Proxy (IAP), which enforces policy per request.
Access decisions are based on user identity (SSO/MFA), device health (managed and compliant), and context (IP, time).
BeyondCorp eliminates the need for VPN for web applications; IAP TCP forwarding handles SSH/RDP.
Default deny: if no policy matches, access is denied.
Device certificates are used for mutual TLS authentication and are revoked when a device is non-compliant.
Policy decisions are cached for 5 minutes by default; session tokens expire in 1 hour.
BeyondCorp works with existing applications without modification via reverse proxy.
These come up on the exam all the time. Here's how to tell them apart.
BeyondCorp (Zero Trust)
Access based on identity and device context.
No implicit trust for any network location.
Per-application access control.
No VPN gateway required; users connect directly via proxy.
Device health enforced before access.
Traditional VPN (Perimeter Security)
Access based on network location (inside vs. outside).
Once inside the VPN, users have broad network access.
Network-level access (entire subnet).
Requires VPN client software and concentrator.
Device health typically not checked; only user credentials.
Mistake
BeyondCorp is just a VPN alternative that still trusts the internal network.
Correct
BeyondCorp eliminates the concept of internal network trust entirely. Every access request is evaluated based on identity and device, regardless of location. There is no 'inside' that is automatically trusted.
Mistake
BeyondCorp requires all applications to be modified to support OAuth.
Correct
Google's IAP works as a reverse proxy and does not require application changes. It handles authentication and policy enforcement transparently, injecting user identity via HTTP headers that the application can optionally use.
Mistake
BeyondCorp only works for web applications.
Correct
BeyondCorp can be extended to non-web applications using IAP TCP forwarding (for SSH/RDP) or BeyondCorp Remote Access with a client connector. The model is protocol-agnostic.
Mistake
BeyondCorp is only available on Google Cloud.
Correct
The BeyondCorp model can be implemented on any platform using similar principles (e.g., using a reverse proxy with SSO and device management). Google's IAP is a GCP service, but the model itself is vendor-neutral.
Mistake
BeyondCorp eliminates the need for firewalls and network security.
Correct
BeyondCorp adds application-layer access control but does not replace network-layer security like firewalls, DDoS protection, or network segmentation. Both are needed for defense in depth.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
BeyondCorp is a Zero Trust model that grants access based on identity and device health, not network location. A VPN grants network-level access once the user is authenticated, implicitly trusting the user inside the network. BeyondCorp requires verification for every request, while a VPN trusts the user after initial connection.
No, if you use Google's IAP, it acts as a reverse proxy and does not require application changes. The proxy handles authentication and policy enforcement, and can inject user identity via HTTP headers if the application wants to use it. The application sees the proxy's IP, not the user's.
Google's IAP supports TCP forwarding for SSH and RDP. The user runs a command like `gcloud compute ssh INSTANCE --tunnel-through-iap`, which creates a secure tunnel through IAP. The VM does not need a public IP; only IAP's IP range must be allowed in the firewall.
The device inventory service updates the device status. On the next access request, the Access Proxy checks device health. If non-compliant, the policy engine denies access. The device certificate may also be revoked, preventing any new TLS connections. Existing sessions may continue until token expiry (1 hour).
Yes, Google's IAP can be used for on-premises applications via hybrid connectivity (Cloud VPN or Dedicated Interconnect). The on-premises app must be reachable from the IAP proxy, typically via internal load balancers or HTTP(S) endpoints.
The default access token lifetime is 1 hour. The session cookie also expires after 1 hour of inactivity. You can configure shorter or longer timeouts in the IAP settings (15 minutes to 24 hours).
No. BeyondCorp is an application-layer access control model. Firewalls are still needed for network-layer security, such as blocking malicious traffic, DDoS protection, and restricting ports. Both are complementary.
You've just covered BeyondCorp Zero Trust at Google — now see how well it sticks with free GCDL practice questions. Full explanations included, no account needed.
Done with this chapter?