Zero trust architecture: what it means in practice for a growing company

"Zero trust" is one of those terms that sounds like a product category but is actually a security philosophy. I have seen companies spend six months evaluating zero trust vendors without agreeing on what problem they were solving. And I have seen companies significantly improve their security posture in the same timeframe by applying the core principles without buying anything new.

This post is about the principles.

The old model and why it breaks

The traditional network security model is based on perimeter. You have an internal network; everything inside is trusted; everything outside is not. A firewall sits at the boundary. Once you are inside - whether by VPN, office Wi-Fi, or a compromised machine - you can reach things you should not need to reach.

This model made sense when "inside" meant a physical office and "outside" meant the internet. It broke when work became distributed, when services moved to SaaS, when contractors and third-party integrations became normal, and when attackers learned that the most reliable way into a network is through a credential, not a firewall port.

The zero trust principle

Zero trust replaces "are you inside the network?" with "are you who you say you are, do you have a legitimate reason to access this specific resource, and is your device in an acceptable state?"

The key shift: identity and context replace network location as the basis for access decisions. This means:

• Every request is authenticated, not just at login but per-session or per-request, depending on sensitivity.
• Access is least-privilege. A user or service gets exactly the access they need for the task, not broad access to a network segment.
• Device posture is part of the decision. An unpatched laptop or a device without endpoint protection gets different access than a managed, compliant device.
• Lateral movement is limited. Even after an attacker compromises one machine or credential, they cannot easily reach other systems because those systems also require authentication and authorisation.

What this means operationally

In practice, moving toward zero trust usually involves:

Identity consolidation. A single identity provider (Okta, Azure AD, Google Workspace) as the authoritative source for all access. This is often the first and most impactful step.

Application-level access control. Instead of routing all users through a VPN to the company network, each internal application is protected by an access proxy that enforces identity checks. Tools like Cloudflare Access, Tailscale, or BeyondCorp-pattern proxies do this.

Microsegmentation. Internal systems do not have open access to each other by default. Services talk to the services they need; access between others is denied unless explicitly permitted.

Continuous verification. Sessions are not indefinitely valid. Re-authentication is required at certain sensitivity thresholds. Device compliance is checked, not assumed.

How to start without a full rewrite

Zero trust adoption does not require replacing everything at once. A realistic sequence:

1. Get your identity consolidated and enforce MFA everywhere, no exceptions.
2. Audit which systems are reachable from where. Most organisations have significant unintended exposure here.
3. Replace VPN for internal application access with an access proxy for the most sensitive applications first.
4. Work toward least-privilege access - start by removing access that has not been used in 90 days.
5. Add device posture checks to your access policy as you gain visibility into endpoint state.

Each step delivers measurable improvement independently. You do not need to complete all five to be in a significantly better position than you are today.

The management frame

Zero trust is not a product. It is a direction. The question for a technical owner is not "are we zero trust yet?" but "what is the next concrete step that reduces our blast radius if a credential is compromised?" That question has a concrete answer at every stage of maturity.