Zero trust security replaces the traditional perimeter-based model (“trust everything inside the network”) with “never trust, always verify.” Every access request — from any user, device, or service — must be authenticated and authorized regardless of network location. This model became essential as cloud computing, remote work, and microservices dissolved the traditional network boundary.
Core Principles
Never trust, always verify: authenticate every request regardless of source network. Assume breach: operate as if the network is compromised; limit blast radius through segmentation. Least privilege: users and services access only the resources they need. Verify explicitly: use all available signals (user identity, device health, location, request context) to make access decisions. These principles shift from “where is the request coming from?” to “who is making the request, with what device, for what purpose?”
BeyondCorp Model
Google BeyondCorp (the origin of modern zero trust) moved access control from network-level VPNs to device and user identity. Employees access internal resources over the public internet; there is no privileged internal network. Access decisions are made by an Access Proxy that evaluates: device inventory (is this a company-managed device with current patches?), user identity (authenticated via SSO), and resource policy (is this user authorized for this resource?). This removed the network location as a trust signal entirely.
Identity-Aware Proxy
An Identity-Aware Proxy (IAP) sits in front of internal applications. Every request is intercepted; the IAP validates the user's identity token (OAuth 2.0/OIDC), checks group membership and resource policies, and only proxies authorized requests. If unauthenticated, the IAP redirects to the identity provider login. This allows exposing internal applications over HTTPS without a VPN, while maintaining fine-grained access control. Google Cloud IAP, Cloudflare Access, and Pomerium are IAP implementations.
Device Trust
Access decisions incorporate device health signals: is the device enrolled in MDM (Mobile Device Management), does it have up-to-date OS patches, is disk encryption enabled, is the endpoint agent running, does the device have known vulnerabilities? Device certificates (issued by the company CA to managed devices) prove device enrollment. Device trust level determines access tier: unmanaged personal device → limited access; managed patched device → full access. Continuous device posture checking revokes access if device health degrades mid-session.
Service-to-Service Authentication
Mutual TLS (mTLS) authenticates both sides of every service-to-service connection. Each service receives a short-lived X.509 certificate encoding its identity (SPIFFE SVID format: spiffe://trust-domain/ns/default/sa/payment-service). The certificate is issued by a workload identity provider (SPIRE) and rotated automatically. Authorization policies specify which service identities can call which other services on which ports. A service mesh (Istio, Linkerd) implements mTLS transparently via sidecar proxies.
Microsegmentation
Microsegmentation applies zero trust within the network: instead of allowing all east-west traffic between services in the same VLAN, enforce explicit allow-lists. Only payment-service can call fraud-service on port 8080; no other service may initiate connections to fraud-service. Implemented via: service mesh authorization policies, Kubernetes NetworkPolicies, cloud provider security groups, or a dedicated microsegmentation product. This limits lateral movement if one service is compromised.
Continuous Verification
Traditional authentication gates entry; zero trust applies continuous verification throughout the session. Short-lived access tokens (15 minutes) require frequent re-authorization. Re-evaluate access on each request (stateless) or periodically (every N minutes for long-lived connections). Risk signals that trigger re-authentication: device posture change (patch update failed), unusual location (new country), anomalous behavior (accessing unusually large volumes of data). Continuous verification detects account compromise that would not be caught by a once-per-login authentication check.