Architecture

Zero Trust Fundamentals

The core principles of Zero Trust as I apply them in APAC enterprise engagements — beyond the marketing pitch.

Updated 2026-04-15

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:

  1. Never trust, always verify. No request is trusted because of where it came from. Internal traffic is not implicitly safer than external traffic.
  2. 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.
  3. 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

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:

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

← Wiki index