Zero Trust Architecture: A Practical Guide

Zero Trust is the most discussed and most misunderstood security concept of recent years. It is not a product, nor a single project, but a design principle: never trust by default, always verify. This article is about turning that principle into concrete, schedulable steps.

What it replaces, and why

The traditional security model was built on the perimeter: there was an "outside" and an "inside", with the firewall between them. Anyone who reached the network was more or less trusted.

That model collapsed for three reasons:

There is no clear perimeter any more. Cloud services, remote work, mobile devices, supplier access, both resources and users sit outside the network.

Attackers operate from inside the perimeter. The typical incident starts with phishing or a stolen password. At that point the attacker is by definition "inside", and perimeter defence counts for nothing.

Lateral movement is cheap. On a flat internal network, a single compromised workstation reaches the entire organisation.

The Zero Trust answer: every access request must be evaluated individually, in context, regardless of where it originates.

The five pillars

Based on NIST SP 800-207 and industry practice, Zero Trust breaks down into five areas. You do not need all of them at once, but each must eventually be addressed.

1. Identity. Every access is tied to a strong, verified identity. This is the most important pillar: if identity is weak, nothing else matters.

2. Device. Access is conditional on device posture: is it managed, is it up to date, is protection running.

3. Network. Micro-segmentation, the network is not one large trusted zone but many small ones with controlled transit.

4. Application and data. Applications do not grant access based on network location; data is classified and encrypted.

5. Visibility and analytics. Every access decision is logged, and log analysis feeds back into policy.

Where to start: identity and MFA

If you do only one thing, make it this. Credential theft is the most common initial intrusion vector, and multi-factor authentication stops the great majority of it.

Some practical points:

• Not all MFA is equal. SMS codes are weakest (SIM swap, interception). Push notification is better but vulnerable to MFA fatigue attacks, worth pairing with number matching. Strongest is a FIDO2/WebAuthn hardware key, which is phishing-resistant.
• Start with high-risk accounts: administrators, finance, executives, remote access.
• Eliminate exceptions. A single legacy protocol without MFA (older mail authentication, for instance) is enough to bypass the whole thing.
• Consolidate. The more applications sit behind one identity provider (SSO), the fewer blind spots.

Least privilege

The second highest-yield step. In most organisations privileges accumulate over time: someone moves to another department, but their old access remains.

Worth doing:

• Access reviews, at least half-yearly, involving line managers.
• Just-in-time administrative access: elevated privilege should not be standing, but requested, time-bound and justified.
• Separate administrative accounts. An admin should not read email and browse the web with the account used for daily work.
• Clean up service accounts, these often run with excessive rights and passwords that have never been rotated.

Micro-segmentation, realistically

This is the pillar that intimidates most organisations, because it looks large. Taken incrementally, it is manageable.

First round: isolate critical systems. Domain controllers, backup infrastructure and financial systems should sit in their own segments with tightly defined permitted traffic. This alone makes lateral movement considerably harder.

Second round: separate user and server networks. A workstation has no business reaching another workstation's administrative ports, client isolation is cheap and effective.

Third round: application-level segmentation. Each application communicates only with what it must.

Device posture as a condition

The access decision must factor in the device. A sign-in from an unmanaged machine of unknown state deserves different treatment from one on a corporate, up-to-date device.

Practical levels:

1. Is the device known? Registered in device management.
2. Is it compliant? Encrypted disk, active endpoint protection, current operating system.
3. Is it healthy right now? Any active alerts on it.

Conditional access policies build on these: from a non-compliant device, only limited functionality, or browser-only access without download.

Do not forget OT

In industrial environments Zero Trust principles hold, but implementation differs. Agents cannot be installed on control devices, and continuous authentication is not meaningful for a PLC.

What does transfer:

• Zone-and-conduit model (IEC 62443), essentially micro-segmentation in industrial language.
• Strong identity and MFA for remote access, particularly for supplier maintenance channels.
• Least privilege on engineering workstations.
• Continuous passive monitoring as the visibility pillar.

Our article on ICS/SCADA security covers this in detail.

A realistic timeline

A Zero Trust programme typically runs 18–36 months and is never fully "finished". A workable sequence:

Months 0–6. MFA for all users, SSO consolidation, separation of administrative accounts, asset inventory, isolation of backup infrastructure.

Months 6–12. Conditional access on device posture, access review process, just-in-time admin, segmentation of critical systems.

Months 12–24. User/server network separation, application-level access (replacing VPN), data classification.

Ongoing. Logging and analytics, policy tuning, regular testing, this is where a penetration test measures whether segmentation actually holds.

The most common mistakes

Treating it as a product. No vendor sells "a Zero Trust solution". Much can be achieved with tools you already own.

Ignoring user experience. If security introduces too much friction, users route around it. Risk-based authentication, where low-risk access from a familiar context is frictionless, is not a weakness but a precondition for successful adoption.

Leaving legacy systems out. Those are precisely the risk. If they cannot be modernised, wrap them in compensating controls: strict segmentation, jump servers, enhanced monitoring.

Doing everything at once. Incremental, measurable steps work. After each round, measure how much the attack surface has shrunk.

If you want to assess where you stand, the architecture review within our IT security services addresses exactly this question.