Security
What it actually takes to build a Zero Trust security setup
A lot of organizations say they have Zero Trust security but haven't actually changed how their systems work. Real Zero Trust changes your actual vulnerabilities — not just your audit report. Here's what a genuine implementation requires.
The gap between the framework and the outcome
Zero Trust has become the default answer to enterprise security program questions. Board presentations reference it. RFPs require it. Vendor marketing promises it. The problem is that most enterprise Zero Trust programs produce Zero Trust documentation — not a genuine Zero Trust security setup. The distinction matters because documentation doesn't close real vulnerabilities. Only implemented controls do, and the controls required for genuine Zero Trust security are operationally difficult in ways that vendor marketing doesn't acknowledge.
What Zero Trust actually means architecturally
NIST SP 800-207 defines Zero Trust as a security model where no user, device, workload, or network location is implicitly trusted. Every access request is evaluated at the time of the request using all available context: the identity of the requestor, the state of the device, the sensitivity of the resource, and the behaviour pattern of the principal making the request. This is architecturally meaningful: it implies that access decisions cannot be made at the network perimeter, because the network perimeter has no context about the requestor's identity or the device state. Access decisions must be made by a policy engine that has access to identity data, device posture data, and resource sensitivity classifications — and that decision must be made per-request, not per-session.
The three controls that are almost always missing
In our assessment work across enterprise environments, the controls that distinguish genuine Zero Trust from Zero Trust theater are consistently the same three. First: checking device security at the time of the access request — not just at the time of enrollment. Most enterprises enroll devices and treat enrollment as permanent proof of safety. A device that was compliant at enrollment and has since been compromised or fallen out of date is still treated as trusted. Second: verifying communication between internal systems, not just users. Most enterprise security programs focus on user-to-application access and leave system-to-system communication — which is the path attackers use to spread through a network after breaching one system — checked only by network location. Third: continuous validation, not one-time verification. A session that was valid 4 hours ago should be re-evaluated when context changes — when a user's location changes, when a device goes out of compliance, when unusual behaviour is detected.
The operational constraint that determines feasibility
The reason these controls are missing from most Zero Trust implementations is not ignorance — it's operational feasibility. A device posture check that happens per-request adds latency to every access decision. Per-request policy evaluation at enterprise scale requires infrastructure that can process hundreds of thousands of policy decisions per second with sub-millisecond response times. Service mesh deployments required for service-to-service mTLS break applications that weren't designed to handle certificate rotation. These are real engineering constraints, not excuses — and they're why Zero Trust implementation is a multi-year program, not a configuration change.
The implementation sequence that produces real outcomes
The correct sequence for Zero Trust implementation starts with visibility, not enforcement. You cannot enforce policies on workloads you cannot see. The first phase should deploy comprehensive network flow monitoring, identity telemetry, and workload behaviour baselining — without changing any access policies. This phase typically takes 60–90 days and produces two valuable outputs: a complete picture of what your current access patterns actually are (which is almost always surprising), and a baseline against which anomalies can be detected. Only after this baseline is established should policy enforcement begin, starting with the highest-risk access patterns and working toward least-privilege over a phased 12–24 month program.
Want early access to our thinking?
Subscribe to receive Aethon Core insights as they publish — practical, plain-language content on enterprise technology from people who build it.