Failure Pattern: TLS Certificates
TLS certificates encrypt traffic but do not verify the true identity of the system presenting them. Attackers use stolen or cloned certificates to masquerade as trusted workloads.
What We See in the Field
A compromised workload uses shared TLS certificates to establish encrypted sessions that appear legitimate. Monitoring sees normal TLS patterns. Traffic is trusted even when the actor is malicious.
Underlying Causes
Certificates copied between workloads
No binding to hardware or VM identity
Certificate management complexity
Overreliance on TLS for authenticity
Cloud cloning workflows duplicating certificates
Trust-Native Network Resolution
DTL replaces certificate-based identity with hardware-anchored TrustKeys. Sessions cannot be established using cloned or stolen credentials because identity is cryptographically bound to the workload.
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.