Zero Trust Security: The Core Principles

Traditional enterprise security operated on a perimeter model: trust everything inside the network, distrust everything outside. A corporate firewall separated the trusted internal network from the untrusted internet — and once a device or user was inside the perimeter, they typically had broad access to internal resources. You’ll find the complete rundown in our Complete Guide to Online Security and Privacy.

The collapse of this model — driven by cloud computing, remote work, mobile devices, and attacks that routinely breach perimeters — produced the zero trust security model: an architecture that operates on “never trust, always verify” regardless of whether a request originates from inside or outside the traditional network boundary.

Zero trust is not a single product. It’s an architectural philosophy implemented across identity, device, network, application, and data layers. This guide covers what it means, how it compares to the perimeter model, and how small and mid-size organisations can implement it in practice — starting with the changes that have the highest security impact at the lowest implementation cost.

The three core principles

Verify explicitly. Every access request — regardless of where it originates, which network it comes from, or what identity it claims — must be authenticated and authorised before access is granted. A user who authenticated in the morning is re-verified for sensitive operations later in the day. A device that passed security checks last week is re-evaluated against current standards before accessing sensitive resources. Verification uses all available signals: user identity, device health, location, time of access, and behavioural anomalies.

Use least privilege. Users and systems are granted the minimum access necessary for their specific task — not broad access to everything their role might theoretically need. An employee in accounts payable has access to accounting systems but not to HR records, development environments, or network infrastructure — even if all of those resources are “inside” the same organisation.

Assume breach. The architecture assumes that any network, device, or account may already be compromised — and designs to limit the damage when a breach occurs. Network micro-segmentation, application-layer access controls, and comprehensive logging address this principle: the attacker who gains a foothold in one system cannot easily move laterally to others, and the evidence of the breach is captured in logs that enable detection and response.

Traditional perimeter vs zero trust — concrete differences

The cloud compatibility advantage is one of the primary drivers of adoption. Traditional perimeter security became unworkable as applications moved to cloud services (Microsoft 365, Salesforce, AWS), users worked from home, and “inside the network” lost meaning. Zero trust grants access based on verified identity, device health, and request context — not network location — which applies consistently whether the user is in the office, at home, or travelling.

Implementation steps for small and mid-size organisations

Phase 1 — Identity (start here, highest impact):

1. Every user has a unique account — no shared credentials
2. Every account uses multi-factor authentication (preferably phishing-resistant FIDO2 or passkeys)
3. MFA is enforced through conditional access policies rather than being optional

In Microsoft 365, conditional access policies enforce MFA for all sign-ins and can require additional verification for sensitive operations. In Google Workspace, context-aware access applies similar controls. Microsoft’s own data shows MFA enforcement reduces account compromise risk by over 99% compared to password-only authentication. This is why identity is both the first step and the one with the fastest measurable impact — a zero trust model that cannot reliably verify identity cannot reliably grant or deny access based on it.

Phase 2 — Device health verification: The zero trust model requires knowing the security state of the device requesting access, not just the identity of the user. Device compliance policies — enforced through Microsoft Intune, Jamf, or equivalent MDM — define what a healthy device looks like: OS updates current, antivirus active, disk encryption enabled, screen lock configured. Conditional access policies can block non-compliant devices from accessing sensitive resources regardless of the identity presenting the request.

Phase 3 — Least privilege access controls: Review and reduce permissions across all systems. Role-based access control (RBAC) in cloud services assigns users the minimum permissions needed for their role. Privileged Identity Management (PIM) in Microsoft Entra ID implements just-in-time elevation for administrative access — an administrator’s account has standard permissions by default and must explicitly activate elevated privileges for specific tasks, for a defined time window, with justification logged.

Phase 4 — Network micro-segmentation: Devices on the same network can no longer automatically communicate with all other devices. For small organisations, this starts with: guest network isolation (IoT devices on a separate VLAN from workstations), server/NAS isolation (file servers accessible only from authorised workstations, not all devices), and cloud resource isolation through virtual networks and security groups. Each segment boundary requires explicit authorisation to cross.

Phase 5 — Comprehensive logging: The “assume breach” principle requires comprehensive logging to detect anomalies and investigate incidents. Cloud access logs (Microsoft Entra sign-in logs, Google Workspace audit logs), endpoint detection logs, and network flow logs provide the visibility to detect unusual patterns, impossible travel (authentication from two distant locations within minutes), and lateral movement attempts. Centralise these logs and configure alerts for high-priority anomalies.

ZTNA vs traditional VPN

One of the most visible practical applications of zero trust is Zero Trust Network Access (ZTNA) as a replacement for traditional VPN. Traditional VPN grants the authenticated user access to the full internal network — every server, every service becomes reachable. If the VPN account is compromised, the attacker gets the same broad access. ZTNA replaces this with application-specific access: a user is granted access to specific applications (email, CRM, file server) without the underlying network being exposed. The rest of the network is invisible to their session.

Commercial ZTNA solutions: Cloudflare Access, Zscaler Private Access, Palo Alto Prisma Access, and Tailscale (lightweight ZTNA appropriate for smaller organisations). For organisations already using Microsoft Entra ID (Azure AD) and Microsoft 365, Microsoft Entra Private Access provides ZTNA capabilities integrated with existing identity infrastructure. Our guides on secure remote desktop and network security basics cover the specific remote access security decisions that ZTNA addresses.

Does zero trust require expensive enterprise software?

For the full implementation with ZTNA, SIEM, PAM, and comprehensive micro-segmentation — yes, costs are significant. But the highest-impact components are available at low or no marginal cost within platforms most organisations already use:

• Microsoft 365 Business Premium (~$22/user/month): includes Entra ID P1 with conditional access and Intune for device management — the primary building blocks of the identity and device layers
• Google Workspace (Business Plus and Enterprise): includes context-aware access policies at the identity layer
• Tailscale (free for personal, modest cost for teams): ZTNA-style access control for small organisations without enterprise infrastructure

Organisations already paying for Microsoft 365 Business Premium have most of what they need to implement Phases 1 and 2 without additional platform cost. The investment is in configuration time, not additional licensing. Starting with the included tools and expanding to dedicated ZTNA and micro-segmentation products as the organisation grows and security maturity increases is the pragmatic approach for most small and medium organisations.

Zero trust for employees — why the controls exist

In a zero trust environment, an employee who previously connected to the corporate network through VPN from any device may find that device compliance is now checked before access is granted — an unpatched personal laptop is blocked from accessing corporate resources until it meets the compliance baseline. Understanding that these controls implement least privilege and device verification rather than arbitrary IT restrictions helps employees engage constructively rather than treating them as obstacles to route around.

Security policies that employees understand the rationale for are the ones they follow rather than circumvent. This human element of adoption is as important as the technical configuration — a technically perfect zero trust architecture that employees bypass through workarounds (sharing credentials, using unmanaged devices) fails to deliver its security benefits. The communication of why controls exist is part of the implementation, not an afterthought.

Zero trust is a continuous journey rather than a binary destination. Organisations that implement even the first two phases — MFA enforcement and device compliance — are measurably more secure than those relying on perimeter controls alone, even if the complete architecture takes years to fully realise. The consistent thread across all phases is measurement: each phase should produce observable metrics (reduced account compromise rates, improved device compliance scores, reduced lateral movement capability) that demonstrate the investment is producing its intended security improvements.

Real-world zero trust scenarios — what it looks like in practice

Abstract principles become clearer with concrete examples:

Scenario 1 — Remote employee on an unmanaged device: An employee works from home and tries to access the company’s CRM from a personal laptop that hasn’t had Windows Update run in six months. Under a perimeter model with VPN: they connect, the VPN authenticates them, they have full access. Under zero trust with device compliance: the conditional access policy checks device compliance before granting access, finds the laptop is not enrolled in MDM and has outdated OS, and blocks access or redirects to a limited-access portal. The employee is told which compliance steps are required (enroll in MDM, run updates) before full access is granted.

Scenario 2 — Compromised account credential: An attacker obtains an employee’s username and password through a phishing attack. Under a perimeter model: they connect through VPN, gain full internal network access, and can move laterally to any system the employee had access to plus others on the same network. Under zero trust: the attacker attempts login, MFA is required (they don’t have the second factor), access is blocked. Even if they somehow have the second factor, the device they’re connecting from is unmanaged — conditional access blocks it. If they do gain access to one application, micro-segmentation prevents lateral movement to other systems the employee didn’t have explicit access to.

Scenario 3 — Insider threat: An employee with elevated permissions plans to exfiltrate data before leaving the organisation. Under perimeter model: broad internal access makes this straightforward. Under zero trust: just-in-time privilege elevation means the employee’s account has standard permissions by default; elevated access requires approval, is time-limited, and all access is logged with detailed audit trails. Anomalous access patterns — downloading large volumes of data outside normal hours, accessing systems not relevant to their role — trigger alerts in the SIEM.

Zero trust maturity model — where organisations typically start and end

• Traditional (Level 0): Perimeter-based, VPN for remote access, minimal logging, broad network access once inside
• Initial (Level 1): MFA deployed, some conditional access policies, device management starting
• Advanced (Level 2): MFA enforced universally, device compliance required for access, RBAC implemented, some network segmentation
• Optimal (Level 3): Full ZTNA for remote access, micro-segmentation, just-in-time privilege elevation, comprehensive SIEM logging with automated threat detection, data classification and information protection policies

Most small and medium organisations should target Level 2 as the realistic medium-term goal — it addresses the majority of practical threats without requiring enterprise-level security infrastructure. Level 3 is appropriate for organisations with dedicated security staff or specific compliance requirements (FedRAMP, CMMC, HIPAA). For a detailed framework and maturity assessment tool, CISA’s Zero Trust Maturity Model provides a structured assessment across the five pillars (Identity, Device, Network, Application, Data) that can be used to assess current state and plan the transition for organisations of any size. Related: Software Supply Chain Security.

Zero trust represents a genuine shift in how security is conceptualised — from protecting a perimeter to verifying every interaction within and across that perimeter. The transition isn’t instantaneous, and perfection isn’t required for meaningful improvement. The first step — enforcing MFA universally and revoking the implicit trust that network location previously granted — changes the security calculus more than any perimeter-hardening measure available at similar cost. If this sounds familiar, Secure Password Reset is worth a look.