Zero Trust Architecture: Not a Product Purchase but a Change of Assumption

Core premise: the traditional model implicitly assumes "dangerous outside, safe inside". Zero trust simply replaces that assumption — no location is assumed safe. Angle: architectural principles and tradeoffs. No operational detail.

Why the "perimeter" no longer holds

The traditional model draws a circle: outside is the dangerous internet, inside is a trusted network. Defence means defending the circle.

That model has failed for concrete reasons:

• Workloads moved to the cloud → no fixed perimeter;
• Staff work from home → access arrives from anywhere;
• Service-to-service traffic → much of it involves no human at all;
• Supply chain and third parties → your code runs on someone else's systems;
• AI agents → a new identity that cannot be socially engineered, but whose credentials can be stolen.

In one line: the concept of "inside" no longer exists.

Three core principles

Principle one: never trust, always verify

Every access request re-verifies identity and authorisation — regardless of where it originates.

It sounds burdensome, but modern identity systems make it transparent to users (certificates, biometrics, device state).

Principle two: least privilege

Each identity holds the minimum needed for the current task, granted just-in-time and revoked after use.

This converges exactly with Insider Threat and Access Governance — if the permission does not exist, it cannot be abused.

Principle three: assume breach

Design as if the attacker is already inside. The focus shifts from "prevent entry" to:

• How do we limit lateral movement?
• How do we detect anomalies early?
• How do we bound the impact of a single failure?

This is the most counter-intuitive and most important principle. It turns security design from "building walls" to "designing bulkheads" — like a ship that does not sink even when it takes on water.

Four implementation layers

Layer	Core question	Direction
Identity	Who are you, and why trust it?	MFA, certificate-based logon, continuous verification
Device	Is this device trustworthy?	Device health checks feeding authorisation decisions
Network	Should this connection be allowed?	Microsegmentation, encryption, no trust by network location
Data	May this person touch this data?	Classification, encryption, access logs, dynamic authorisation

Key: all four must be done together to mean anything. Network segmentation without identity verification swaps a wall for a hedge.

Five common misconceptions

"Zero trust is a product." It is a set of principles; products are implementation means, and different environments need different combinations.

"Zero trust = MFA everywhere." MFA is an important part; the core is continuous verification and least privilege.

"You cannot have an internal network." You can — you simply do not treat network location as a trust signal.

"It is an IT project." It changes workflows (who may access what, who approves), so it is an organisational matter, not purely technical.

"Do it in one pass." In practice it is staged: start with the highest-value assets (privileged accounts, core data) and expand.

A practical rollout order

1. Inventory: which are the most valuable assets, and who can access them?
2. Strengthen identity: MFA and just-in-time access for privileged accounts first;
3. Segment the network: prevent a single point from sweeping everything;
4. Tier the data: the most sensitive data gets its own access control;
5. Verify continuously: feed device state and behavioural anomalies into authorisation;
6. Review regularly: "does this person still need this permission?"

How this connects to the series

Zero trust is not a standalone topic — it is the shared substrate of several articles here:

Article	Connection
05 Credentials and AD concepts	"Credentials are the pivot" — zero trust removes their lateral value
07 Defense lessons from a red-team postmortem	Attackers stall at credentials → credential governance is zero trust in practice
10 Cloud identity and permissions	The cloud is where zero trust lands most naturally
12 Insider threat and access governance	The concrete governance of "do not assume the inside is safe"

Three one-liners

1. Zero trust is a change of assumption, not a procurement.
2. Assume breach, then design bulkheads. Focus on bounding impact, not on never failing.
3. Start from the highest-value assets. A full rebuild cannot be done in one pass.

Next steps

• For credentials in the attack chain, read credentials and AD concepts
• For cloud permission design, read cloud identity and permissions
• For insider risk types, read insider threat and access governance