Zero Trust Fundamentals
The core principles of Zero Trust as I apply them in APAC enterprise engagements — beyond the marketing pitch.
What Zero Trust actually is
Zero Trust is not a product. It is a set of design principles applied to authentication, authorisation, and network segmentation. The principles are:
- Never trust, always verify. No request is trusted because of where it came from. Internal traffic is not implicitly safer than external traffic.
- Least privilege by default. Every user, service, and device gets the minimum access needed to do its job — and only for as long as needed.
- Assume breach. Architecture decisions assume that some part of the system is already compromised. Lateral movement must be impossible-by-design, not just unlikely.
Anything sold to you as "Zero Trust" that doesn't push back on these three is marketing.
The four control planes
In every Zero Trust engagement I've delivered, the architecture has the same four control planes:
1. Identity
A single source of authority for "who is this?". In APAC enterprises this is almost always Okta or Azure AD. Conditional access policies are enforced here based on user attributes, device posture, location, and risk score.
2. Edge
A gateway that sits in front of every application — internal or external. In our work this is typically Cloudflare Access. It enforces the identity decision before any traffic reaches the application origin.
3. Privilege
Privileged sessions are managed separately from regular access. BeyondTrust, CyberArk, or Delinea handle just-in-time elevation, session recording, and the elimination of standing admin rights.
4. Telemetry
Everything generates structured logs that flow to a central SIEM (typically Splunk in finance, Sentinel in MS-shops). The SIEM computes a per-session risk score that feeds back into the identity layer's policy decisions.
What Zero Trust is not
- It is not VPN replacement. Replacing VPN with Cloudflare Access is a useful step, but it doesn't make you Zero Trust if your application still trusts internal traffic.
- It is not microsegmentation alone. Network segmentation is one tool. Without identity-driven policy enforcement, you've just made a more granular firewall.
- It is not free from latency. Edge enforcement adds 30–80ms to most requests. Most apps tolerate this; some real-time systems (trading floors, voice) need exceptions.
A working Zero Trust architecture
For an APAC enterprise of 1,000–10,000 employees with a typical Microsoft + AWS estate, my reference architecture looks like this:
- IdP: Okta with Workday-driven provisioning and SCIM out to all major SaaS apps
- Device trust: CrowdStrike (or Defender for E5 shops) feeding posture into Okta
- Edge: Cloudflare Access in front of all internal apps; Cloudflare WARP for the egress side
- PAM: BeyondTrust for all admin sessions; just-in-time elevation only
- SIEM: Splunk with a dedicated risk-scoring app that ingests Okta, Cloudflare, BeyondTrust, and CrowdStrike events
This stack is not optimal — it's pragmatic. It has working integrations for every component, it's deployable in 8–12 months, and it's defensible to a regulator.
Reading list
- BeyondCorp (Google's original 2014 paper)
- NIST SP 800-207 — Zero Trust Architecture
- The Cloudflare Zero Trust documentation (vendor docs, but accurate)