Zero Trust: Principles to Stop Trusting the Network

Actualizado: 2026-05-03

Zero Trust has become one of the most vendor-sold terms in security. 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. This article covers the real principles behind the name, the difference from classic perimeter security, and typical mistakes in adoption.

Key takeaways

• Classic perimeter security assumes “inside = trusted”; Zero Trust eliminates that assumption and verifies every request regardless of origin.
• The five principles are: verify explicitly, least privilege, assume compromise, validate the device, and continuous visibility.
• Google’s BeyondCorp is the reference implementation — built after the 2009 incident.
• The most repeated mistake is buying a product and declaring Zero Trust. No product gives you Zero Trust.
• An average organisation takes 2-4 years to cover the full roadmap.

The Paradigm Shift

Classic perimeter security assumes three things:

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

This model worked in offices with wired desktops and local datacentres. It fails in the current context for four reasons:

• Employees working from home, cafés, and 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 origin.

The Five Principles

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^[1] is the most documented Zero Trust implementation. Google built it after the 2009 incident (Operation Aurora). Four practical principles from their implementation:

• VPN eliminated for internal employees. Access to internal applications happens over the Internet with strong authentication.
• Device identity checked at every access via x509 certificates installed on every corporate device.
• Conditional access based on device posture, user identity, and 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.

Zero Trust at the service-to-service plane relies on technologies like mTLS between microservices — mutual authentication closes the lateral movement that the perimeter cannot stop.

Common Adoption Mistakes

Six mistakes that repeat in real projects:

1. Buy a product and declare Zero Trust. No product gives you Zero Trust. Implementation involves changes in identity, devices, network, applications, and processes.
2. 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.
3. Forget the human factor. Aggressive MFA and frequent reauthentications can enrage users. Find the balance — friction where it matters, not everywhere.
4. MFA without device verification. MFA on a compromised device remains vulnerable. Adding only MFA isn’t complete Zero Trust.
5. No behaviour telemetry. Without continuous visibility, principles are theoretical. Investment in logging and analysis is fundamental.
6. 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 step-by-step sequence to start:

1. Universal MFA for all employees and all services. The most impactful piece with the most manageable effort.
2. Centralised Single Sign-On (Authentik, Okta, Microsoft Entra) — reduces friction and enables consistent policies.
3. Device identity via MDM and certificates.
4. Eliminate VPN for internal web apps via an identity proxy (Cloudflare Access, Authentik with forward auth).
5. Internal network microsegmentation with explicit policies — start by separating production from development.
6. Service-to-service mTLS via service mesh (Istio, Linkerd) or manual sidecar.
7. 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 the reality of distributed work and cloud. 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.

1. BeyondCorp