This article is the third part of the Three Pillars of Enterprise IT Infrastructure series and addresses the architectural expression of the security pillar.

For decades, enterprise security architecture rested on a single assumption: the inside of the network is safe, the outside is dangerous. The firewall was the boundary separating those two zones, and whoever got inside was treated as trustworthy. That assumption no longer holds. Remote work, cloud applications, supplier access and mobile devices have rendered the notion of "inside the network" meaningless. Zero Trust architecture is built precisely on abandoning that assumption.

This article covers the principles Zero Trust rests on, the components of the architecture, the common misconceptions surrounding it, and how organizations can move to this model in phases.

Why Perimeter Defence Fell Short

The weakness of the classic model is not theoretical but entirely practical. When an attacker compromises a single user account through phishing, they are already inside the area the perimeter was defending. From that point on, they typically meet very little resistance: if the network is flat, a single endpoint gives access to database servers, file shares and management interfaces alike.

In the majority of serious data breaches, the decisive factor is not how the attacker entered the network, but how freely they were able to move once inside. Limiting that lateral movement is exactly the problem Zero Trust sets out to solve.

The Three Core Principles of Zero Trust

1. Verify Explicitly

Every access request is verified independently of its origin. A user being inside the network, connecting over VPN, or having been verified earlier is not sufficient. Verification weighs multiple signals together: identity, device posture, location, the sensitivity of the resource being accessed, and a behavioural risk score.

2. Least Privilege

Every user and service should hold the minimum privilege needed to do their work — no more, and nothing retained "in case it is needed later". This principle works particularly against the problem of privilege accumulation: when an employee moves between departments over the years and new privileges are layered on top of old ones, the result is a significant risk that goes unnoticed in most organizations. Just-in-time access and regular privilege reviews are the practical expression of this principle.

3. Assume Breach

The architecture is designed on the assumption that an attacker is already inside. This perspective changes the question: instead of "how do we keep them out?", the question becomes "if they are in, how far can they get?". Microsegmentation, end-to-end encryption and comprehensive logging follow naturally from that assumption.

Components of the Architecture

Zero Trust operates across five layers that feed one another:

• Identity: The centre of the architecture. Zero Trust cannot be established without strong authentication, centralized identity management, and privileged accounts governed as a separate discipline.
• Device: Whether the requesting device appears in the corporate inventory, its patch level and the state of its security software all enter the decision. A verified user connecting from an unmanaged device represents a different level of risk.
• Network: Microsegmentation divides the network at workload level and constrains lateral movement. Where a single breach exposes an entire flat network, a segmented network keeps the blast radius contained.
• Application and data: Access is granted at application level rather than network level. Classifying data is a precondition for deciding which data should be accessible under which conditions.
• Visibility and analytics: Without continuous monitoring, Zero Trust is merely a configuration list. Logging access decisions and supporting them with behavioural analysis is the layer that makes the architecture work.

We addressed the behavioural-analysis side of these layers in the previous article in this series, AI-Driven Cyber Security.

Common Misconceptions

• "Zero Trust is a product." It is not. There is no single Zero Trust solution to purchase; it is an architectural approach that requires existing components to be arranged around a different logic.
• "Everything has to be rebuilt from scratch." It does not. Most organizations already own a substantial share of the components required; what is usually missing is coherence and policy consistency between them.
• "Zero Trust degrades the user experience." Designed correctly, the opposite is true. Risk-based verification leaves users undisturbed during low-risk access and requests additional verification only when risk signals rise.
• "We have a VPN, so we are effectively doing Zero Trust." A VPN places the user inside the network and typically grants broad access — the very opposite of Zero Trust. Models that grant access at application level close that gap.

Phased Adoption: Where to Begin

Zero Trust is not adopted in a single move; the transition is a maturation that spans years. A sound sequence looks like this:

• Phase one — Inventory and visibility: No policy can be written until you know which users access which applications from which devices. This phase is not technical; it is discovery.
• Phase two — Strengthening identity: Rolling out multi-factor authentication and separating privileged accounts. This is generally the step that delivers the highest return at the lowest cost.
• Phase three — Segmenting critical assets: Rather than dividing the entire network at once, drawing tight boundaries around the most valuable systems. Keeping the scope narrow makes the riskiest part of the transition manageable.
• Phase four — Moving access to application level: Replacing broad network-based access with application-specific, conditional access.
• Phase five — Continuous verification: Re-evaluating access decisions as risk signals change, rather than once at the start of a session.

The most common mistake in this sequence is skipping phase one and moving straight to product selection. In an organization with an incomplete inventory, the access policy that gets written will inevitably either break business processes or remain so broad that it defeats its own purpose.

Which Maturity Level Is Your Organization At?

• Initial: Security rests on perimeter defence; access inside the network carries no additional verification and the network is largely flat.
• Developing: Multi-factor authentication is live on critical systems, privileged accounts are separated, and the inventory is largely current.
• Defined: Critical assets are segmented, access policies are documented and differentiated by resource sensitivity, and access decisions are centrally logged.
• Mature: Access is granted at application level, device posture enters the decision, and evaluation continues throughout the session.

Most organizations sit in the first two levels, and that is not a mark of failure. What matters is knowing which level you are at and choosing the next step deliberately.

The ORBISIS Approach: Architecture First, Products Second

At ORBISIS we begin Zero Trust projects not with product selection but with an analysis of the existing access structure. Across the projects we have delivered for public and private sector clients since 2013, we evaluate the identity, network and application layers together, and break the transition into phases that do not disrupt business operations. In multi-stakeholder public sector projects in particular, aligning architectural decisions with operational reality is decisive.

This article completes the security pillar of the series. In the period ahead we will address the continuity and governance pillars in articles of their own.

To review your organization's access architecture against Zero Trust principles together, explore our Cyber Security Solutions and System Design Services pages, or get in touch with our expert team.