Failure Pattern
VPNs authenticate user identity but not workload or device identity. Attackers compromise endpoints and gain access to flat trust zones.
What We See in the Field
A compromised laptop connects through VPN with valid credentials. The VPN grants full network access, enabling lateral movement across cloud workloads.
Underlying Causes
Tunnel-based trust
No workload identity
Flat internal networks
Overprivileged access paths
Blind encryption without verification
Trust-Native Network Resolution
DTL replaces VPN tunnels with per-session, per-device trust. No flat network exists. Only workloads with valid TrustKeys establish sessions.
Broken Trust Assumption
This failure pattern has played out repeatedly in real security incidents—not because of missing tools, but because of how trust is assigned.
In breaches such as SolarWinds, Capital One, Okta, and MOVEit, attackers did not bypass security controls. They operated through them, using valid identities, trusted credentials, signed code, and encrypted sessions. Security systems accepted these signals as proof of legitimacy, allowing malicious behavior to proceed.
The common thread across these incidents is structural: identity was assumed based on trust signals, not proven at the moment of execution.