6.2 Secure Connections: VPN, Workload Identity, and Zero Trust
VPNs establish encrypted tunnels. Zero-trust architecture requires explicit access decisions without automatic trust based on a principal's location 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.
Tunnels Protect Traffic Between Endpoints
Site-to-site VPNs connect networks; remote-access VPNs connect devices or users. Specify:
- 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 uses 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.
Static peer keys make timely revocation difficult when they carry the entire lifecycle of temporary staff. A WireGuard peer key has no certificate-style expiry. Short-lived configuration requires an external controller to remove the peer or revoke its rules at expiry and verify enforcement on every node. Device registration, lost-device response, and log correlation are also needed.
Zero Trust Does Not Grant Implicit Trust Based on Location
NIST SP 800-207 calls for explicit decisions for each resource session using the subject, device, resource, and context. It does not mean that nobody can ever be trusted:
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 verifies the certificate and proof of possession of the corresponding private key. Authorization must still decide which methods the workload can call for which tenants. The conditions above express policy intent, not directly executable SPIFFE configuration. Trusted verification results must establish image-signature trust, fresh node health, and deployment approval. Mesh encryption does not grant least privilege automatically.
Test at least three paths: the current production checkout identity can call the authorization endpoint; a similarly named development identity is denied; and revoking permission stops calls over existing connections within the stated window. Similar identity strings and unexpired certificates cannot substitute for policy decisions.
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. High-value access should combine a combination of managed device identity, user phishing-resistant MFA, short-lived authorization, and server-side behavioral signals.
Depending on risk, a non-compliant device may receive read-only access, a repair portal, or a step-up challenge. Stronger user authentication does not repair a compromised endpoint; some resources still require denial.
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 adds detection and response to identify anomalous behavior and limit DDoS impact.