Zero Trust: Principles to Stop Trusting the Network

Zero Trust has become one of the most vendor-sold terms in security in recent years. Every product presents itself as “the definitive Zero Trust solution”. Reality is that Zero Trust isn’t a product, it’s an architecture implemented with many pieces. We cover the real principles behind the name, the difference from perimeter security, and typical mistakes in adoption.

The Paradigm Shift

Classic perimeter security assumes:

There’s a “trusted internal network” behind the firewall.
A “dangerous external network” outside.
If you’re inside, you’re trusted; if outside, you authenticate to enter.

This model has been around for decades. Worked in offices with wired desktops and local datacenter. But fails in 2023:

Employees working from home, cafés, travel — the “perimeter” disappears.
SaaS and cloud — critical resources live outside the firewall.
Attackers who compromise a single endpoint inside the perimeter and move laterally with implicit trust.
Insider leaks — the “inside = trusted” model doesn’t protect against legitimate abuse of valid credentials.

Zero Trust eliminates the assumption of trust by location. Every request is verified as if it came from an untrusted network, regardless of where it originates.

The Five Principles

Different sources formulate Zero Trust slightly differently. A clear synthesis:

1. Verify Explicitly

Every access requires strong authentication and authorisation. There are no implicit “trust tickets”. Combine user identity, device identity, context (time, location, behaviour), and assessed risk.

In practice: MFA always, not just at initial login; short-lived tokens; reauthentication for sensitive actions.

2. Least Privilege

Each identity receives the minimum permissions necessary for its current function, no more. And it receives them just-in-time — granted when needed, removed after.

In practice: granular roles, temporary permissions for administrative tasks, periodic review of accumulated permissions.

3. Assume Compromise

Design thinking there’s already an attacker inside the network. The question isn’t “how do I prevent them entering?” but “what can an attacker who’s already in do before I detect them?”.

In practice: microsegmentation, lateral-movement monitoring, behavioural-anomaly detection.

4. Validate the Device

It’s not enough that the user is legitimate — the device they access from must also be in known, compliant state. Without critical patch, without antivirus, without disk encryption: restricted or denied access.

In practice: MDM/EDR reporting device posture; access policies conditioned on that posture.

5. Continuous Visibility and Analytics

Without rich telemetry and continuous analysis, the previous principles are aspirations. Centralised logs, normal-behaviour metrics, alerts on deviations.

In practice: SIEM, UEBA (User and Entity Behavior Analytics), automated response to clear indicators.

Google’s BeyondCorp Case

BeyondCorp is the most documented and referenced Zero Trust implementation. Google built it after the 2009 incident (Operation Aurora). Practical principles:

Eliminated VPN for internal employees. Access to internal applications happens over the Internet with strong authentication.
Device identity checked at every access (x509 certificates installed on every corporate device).
Conditional access based on device posture, user identity, context.
No “trusted network”. The internal corporate network gets the same treatment as the public Internet.

For Google it worked because they had scale to build the infrastructure. For smaller companies, products like Cloudflare Access, Tailscale, ZScaler, or Microsoft Entra Conditional Access offer similar layers without building from scratch.

Common Adoption Mistakes

After several projects, the mistakes most repeated:

Buy a product and declare Zero Trust. No product gives you Zero Trust. Implementation involves changes in identity, devices, network, applications, and processes.
Start with everything at once. Covering every application with Zero Trust policies from day one collapses the team. Start with one critical application or a user group.
Forget the human factor. Aggressive MFA and frequent reauthentications can be legitimate but also enrage users. Find the balance — friction where it matters, not everywhere.
MFA without device verification. MFA on a compromised device remains vulnerable. If you only add MFA, you’re not doing complete Zero Trust.
No behaviour telemetry. Without continuous visibility, principles are theoretical. Investment in logging and analysis is fundamental.
Not protecting services from each other. Microservices that trust each other because “they’re in the same VPC” reproduce the perimeter model at internal scale. Service-to-service also needs mutual authentication (mTLS) and authorisation.

Pragmatic Roadmap

A reasonable sequence to start:

Universal MFA for all employees, all services. The most impactful piece with the most manageable effort.
Centralised Single Sign-On (Authentik, Okta, Microsoft Entra) — reduces friction and enables consistent policies.
Device identity via MDM and certificates.
Eliminate VPN for internal web apps via an identity proxy (Cloudflare Access, Authentik with forward auth).
Internal-network microsegmentation with explicit policies — start by separating production from development.
Service-to-service mTLS via service mesh (Istio, Linkerd) or manual sidecar.
SIEM and continuous detection over all of the above.

Each step is a project in itself. An average organisation takes 2-4 years to cover the full roadmap.

Conclusion

Zero Trust is a cultural and architectural change, not a purchase. Well implemented, it drastically reduces the blast radius of incidents and adapts better to distributed-work and cloud reality. Poorly implemented — buying a product and declaring victory — it just adds friction without improving protection. Start with the principle most impactful in your context, measure, and advance incrementally.