Zero Trust Architecture

For years, many organizations’ security relied on a simple idea: inside the corporate network we trust; outside we don’t. Firewall at the perimeter, VPN to get “inside”, and once inside, relatively broad access to internal services. That model has become fragile: remote users, personal devices, cloud, and attacks that once inside the perimeter move laterally with little resistance. Zero Trust is a different approach: no one is trusted by default, neither for being “inside” the network nor “outside”. Every access is verified, authorized, and limited according to identity, device, and context.

In this article I explain what Zero Trust is, why it makes sense for internal networks, and how to apply it in practice without redoing everything at once.

The traditional model: trusting the network

In the classic model:

Perimeter: A firewall (or several) separates “internet” from “internal network”. What’s inside is considered safer.
VPN: Remote users connect via VPN and “enter” the internal network; from there they access services as if they were in the office.
Implicit trust: Once inside (physically or via VPN), the user or device is assumed legitimate and given broad access to internal resources.

Problems with this model:

Single point of compromise: If an attacker gets in (phishing, stolen credentials, infected device), they’re “inside” and can move laterally (from server to server, user to user) with little additional verification.
Internal network = trust zone: Any service that only listens on the internal network assumes the caller is trusted. There’s no per-request identity verification.
Heterogeneous devices and networks: Today the “internal network” extends to homes, cafés, and clouds. The perimeter is no longer clear; trusting “being inside” stops making sense.

What Zero Trust is

Zero Trust isn’t a product but a principle: never trust, always verify. That means:

Don’t trust the network: A request coming “from the internal network” isn’t enough to grant access. The network isn’t the trust boundary.
Verify every access: Every request (to an API, a service, a file) must be tied to a verified identity (user, service, device) and context (role, location, device state, etc.).
Least privilege: Grant only the access strictly needed for that identity and context, and for the time needed.
Assume breach: Design as if the attacker is already inside. Segment, limit lateral movement, and require continuous verification.

In practice, Zero Trust implies:

Identity as the axis: strong authentication (MFA), device and service identity, not just “internal IP”.
Per-request authorization: Each access to a resource is authorized by policy (who they are, what role they have, from where, with what device).
Segmentation: The network and services are divided into segments; access between segments is also verified and limited.
Visibility and monitoring: Logs, metrics, and alerts to detect anomalous behavior (unusual access, lateral movement).

How to apply it in practice

You don’t have to “implement Zero Trust” in one shot. You can do it in phases:

Identity and MFA: Ensure all access to critical systems goes through verified identity (SSO, MFA). Without MFA, an attacker with stolen credentials has the same capabilities as the legitimate user.
Access to applications, not the network: Instead of giving “network” access via VPN and letting the user browse everything internal, expose specific applications (e.g. via a proxy or app-by-app access) and require authentication and authorization per application.
Access policies: Define who can access what (by role, group, context). Review and reduce broad permissions (“everyone on the internal network”).
Segmentation: Separate environments (dev, staging, prod) and critical services; have access between segments go through controls (application firewall, API gateway, service identity).
Devices and state: Where possible, consider device state (patched, no known malware, policy compliant) as part of the authorization context.
Logging and monitoring: Log access and authorization decisions; alert on anomalous patterns (access from new location, many auth failures, unusual access to sensitive resources).

Tools and services often seen in Zero Trust designs: identity providers (Okta, Auth0, Azure AD), access proxies (Zscaler, Cloudflare Access), network segmentation (micro-segmentation), device management (MDM). But the core is the principle: don’t trust the network, verify identity and context, and grant minimum necessary access.

My personal perspective

Zero Trust isn’t “buying a Zero Trust product”; it’s changing the mental model: stop assuming that “being on the network” is enough to trust. In internal networks, that means every service and every access is thought through as “who is asking for this and why should they have permission?”, not “it’s from the internal IP”.

Applying it gradually (identity and MFA first, then per-application policies, then segmentation) is usually more realistic than a big bang. The goal is that even if an attacker gets credentials or is “inside” the network, the damage is limited: they can’t move freely because each hop requires verification and they only have the access that policies allow for that identity and context.

In short: no one is trusted by default. Trust is earned on every request, with identity, context, and least privilege. That’s Zero Trust in essence.