6.2 Secure Connections: VPN, Workload Identity, and Zero Trust
VPNs establish encrypted tunnels, while zero trust architecture shifts access decisions, no automatic trust based on whether a principal is inside the corporate network. The two can be combined, but purchasing a VPN or labeling a solution as ZTNA does not automatically enable fine-grained authorization.
Tunnel Endpoint Transmission Protection
Site-to-site VPN connections, remote-access VPN devices, or users require clear design decisions around:
- Who authenticates tunnel endpoints and how keys are issued and revoked;
- Which routes are forwarded into the tunnel, and whether split tunneling is enabled;
- Where DNS resolution occurs, and whether IPv6 is similarly controlled;
- Whether resource-level authentication and authorization continue to operate within the tunnel;
- How much access an endpoint retains after compromise.
IPsec, WireGuard, and TLS-based VPNs each have distinct protocol designs and operational models. WireGuard leverages a minimal protocol surface and modern, fixed primitives, establishing only a peer public key-to-allowed address tunnel relationship. However, user lifecycle management, multi-factor authentication (MFA), device health, DNS configuration, and application-level authorization remain outside the scope of the tunnel itself and are managed by external systems.
Long-term static peer keys are unsuitable for directly provisioning large numbers of temporary employees. The system must support device registration, short-lived configurations, revocation, response to lost or compromised devices, and audit logging for traceability.
Zero Trust Does Not Grant Implicit Trust Based on Location
The core principle of NIST SP 800-207 is not "never trust, always verify"; it's about making explicit, context-aware decisions for every resource session based on the subject, device, resource, and context:
subject identity + device posture + resource sensitivity + context
→ policy decision
→ narrowly scoped session
→ continuous telemetry and reevaluationThe control plane typically includes a policy engine, policy administrator, and data sources, while the data plane is executed by gateways, agents, or proxies. The behavior during failure scenarios (such as a compromised identity provider, expired device compliance, or a policy engine outage) must be pre-defined and resilient.
"Continuous verification" does not mean enforcing MFA on every packet. Instead, access is continuously re-evaluated during a session based on credential validity, device compliance, risk signals, and changes to the resource. This dynamic assessment allows for adaptive access control, including session shortening or revocation when necessary.
Application and Service Identity Are Just as Important
After a user logs into the gateway, backend microservices must not continue relying on source IP addresses for trust, attackers could then move laterally within the network. A workload identity platform can issue short-lived certificates or tokens that bind a service name, environment, and namespace to a verified runtime environment.
Example policy:
principal = spiffe://example/prod/checkout
action = call
resource = payments/authorize
conditions = signed workload + healthy node + current deploymentmTLS authentication verifies the peer's certificate, but the authorization layer must still determine which methods a workload is permitted to call and which tenant it belongs to. Network mesh encryption does not equate to automatic least privilege.
Device Status Is a Signal, Not Absolute Truth
Patch versions, disk encryption, EDR status, and device certificates can influence access decisions, but endpoint agent reports may be outdated, bypassed, or unavailable due to privacy policies. For high-value access, access should be based on a combination of managed device identity, user phishing-resistant MFA, short-lived authorization, and server-side behavioral signals.
When a device is non-compliant, it should be degraded to read-only access, isolated via a repair portal, or require step-up authentication, rather than being limited to full allow or full deny outcomes.
Migration Begins with Resources and Paths
Zero-trust transformation should not start with purchasing a platform and then searching for use cases:
- Inventory high-value resources, entities, and existing access paths;
- Eliminate shared accounts, long-term credentials, and overly permissive network rules;
- Establish reliable identities, device inventories, and log correlation;
- Deploy narrow policies and parallel observation for a single resource;
- Validate failure scenarios, revocation workflows, and break-glass operations;
- Then progressively shrink the traditional network trust boundary.
The next lesson introduces detection and response: even with controls in place, they can be circumvented, so it's essential to detect anomalous network behavior and limit the impact radius of DDoS attacks.