What Is Zero Trust Security

A Story: The Castle

Imagine you are the ruler of a kingdom. You have built a great castle — high stone walls, a moat, a single heavily guarded drawbridge. Inside the walls, everything is safe. You trust everyone inside. The threat is outside.

For centuries, this model worked. Attackers hit the walls. Guards at the drawbridge kept them out. Inside the castle, people moved freely, because everyone inside was assumed to be trustworthy.

Now imagine the castle is connected to the outside world by hundreds of secret tunnels. Merchants come and go. Messengers travel back and forth. Contractors bring supplies. Remote workers access the castle's resources from the village. Some of the castle's own servants have been compromised by invaders.

The walls are still there, but they no longer mean what they used to mean. An attacker no longer needs to breach the walls. They can come through a tunnel. They can compromise a servant. They can intercept a messenger. The assumption that "inside the walls is safe" is now dangerously wrong.

This is the story of network security.

For decades, organizations built their security around a perimeter — a firewall separating the trusted internal network from the untrusted internet. Everything inside was trusted. Everything outside was not. This was the castle-and-moat model.

Then the world changed. Cloud computing put data outside the castle. Mobile devices let employees work from anywhere. SaaS applications moved critical systems beyond the firewall. Contractors, partners, and remote workers needed access. The perimeter dissolved.

Zero Trust is the answer to this new reality. It is a security model that assumes the network is always compromised. It does not trust any user, device, or request by default — regardless of whether they are "inside" the network or "outside." Every request is verified. Every access is authenticated and authorized. Every action is logged.

What Is Zero Trust?

Zero Trust is a security model that grants no implicit trust to any user, device, or request based solely on network location. Every access request is fully authenticated, authorized, and encrypted before access is granted, and trust is continuously evaluated throughout the session.

The phrase "Zero Trust" was coined by John Kindervag at Forrester Research in 2010. It has since become the dominant security paradigm for modern organizations.

The core idea is simple but profound: never trust, always verify.

In a Zero Trust model, there is no such thing as a trusted network. The corporate network is treated as potentially hostile. A request from a user sitting at their desk in headquarters is evaluated with the same scrutiny as a request from a stranger on the public internet.

The three core principles of Zero Trust:

Verify explicitly. Always authenticate and authorize based on all available data points — user identity, device health, location, data sensitivity, and real-time risk signals.

Use least privilege. Grant users only the access they need, for only as long as they need it. Limit both the scope and the duration of access.

Assume breach. Design your systems as though an attacker is already inside — because one day, one will be. Segment your network so that a compromised server in one corner cannot freely reach servers in another. Monitor user and system behaviour continuously so that unusual activity triggers an alert rather than going unnoticed for months. And think carefully about blast radius: if an attacker does get in, how much damage can they do before you stop them? The goal is to make the answer as small as possible. This mindset also drives practices like purple teaming — where offensive and defensive security staff work together to simulate a real attack — and breach-simulation exercises, where teams deliberately act as a post-breach attacker to discover what an insider threat or compromised account could actually reach inside your environment.

Why Perimeter Security Failed

To understand Zero Trust, you must first understand why the perimeter model collapsed.

The Old Model: Castle-and-Moat

For decades, enterprise security rested on three assumptions: the network was the boundary of control, everything inside the network was safe, and trust could be granted once and never re-evaluated. A firewall separated internal from external, and a VPN allowed remote users to tunnel back inside. Location was identity.

What Broke the Model

Cloud computing moved data and applications outside the corporate network. Customer data lives in AWS. Email lives in Microsoft 365. The CRM lives in Salesforce. The perimeter no longer contains critical assets.

Mobile devices allowed employees to work from anywhere. Laptops, phones, and tablets connect from coffee shops, airports, and homes — often outside any perimeter the organization controls.

SaaS applications enabled employees to subscribe to services without IT approval. Marketing uses HubSpot. Developers use GitHub. These services exist beyond the firewall, and employees access them directly.

Remote work transformed the VPN from a secure gateway into a near-universal backdoor into the network — one that granted broad network-level access to anyone who authenticated, from any device, from any location.

Supply chain attacks demonstrated that trusted partners can be compromised. Attackers breach a vendor, then pivot through that trusted relationship into the target organization. The perimeter model assumed that connections from trusted partners were safe. This assumption proved catastrophic.

Insider threats — both malicious and accidental — proved that threats already exist inside the perimeter. An employee with legitimate credentials can be compromised. A misconfigured internal service can expose data. Trusting everything inside the network was never truly safe, but the perimeter model made internal threats nearly invisible.

The result: the perimeter no longer contains your data, your users, or your applications. The castle walls are riddled with holes. Zero Trust was built for this reality.

The Five Pillars of Zero Trust

Zero Trust is not a single product or technology. It is an architectural approach built on five foundational pillars.

Pillar 1: Identity

Identity is the new perimeter. In a Zero Trust model, who you are matters far more than where you are.

Strong authentication is mandatory. Passwords alone are insufficient — MFA is required for all users, with phishing-resistant hardware keys (WebAuthn/FIDO2) providing the strongest protection. SMS and push notifications, by contrast, are vulnerable to interception and fatigue attacks and should be avoided for high-risk access.

Continuous authentication evaluates risk throughout the session. If a user's risk profile changes — an unusual location, an atypical access pattern — the system may challenge them to re-authenticate or block access entirely. Authentication is not a one-time event.

Identity governance ensures that users have only the access they need. Regular access reviews remove unnecessary privileges. Automated provisioning and deprovisioning tie access directly to employment status.

What this looks like: A user authenticates with password and MFA in the morning. Throughout the day, the system monitors their behavior. When they suddenly attempt to access a sensitive financial dataset from an unfamiliar country, they are challenged to re-authenticate — or their access is blocked entirely.

Pillar 2: Devices

Compromised devices can be used to steal data or move laterally across an environment. Zero Trust treats every device as untrusted until proven otherwise.

Device health is assessed before access is granted: Is the device managed by the organization? Is the OS fully patched? Is endpoint protection running and up to date? Devices that fail these checks are blocked or confined to limited access.

A complete device inventory tracks everything that connects to corporate resources. Unknown devices receive no trust by default.

What this looks like: Before allowing access to corporate data, the system verifies that the device is enrolled in management, carries the latest security patches, and has no active malware alerts. An unmanaged personal device is allowed access only to low-sensitivity, public-facing resources.

Pillar 3: Network

In a Zero Trust model, the network is treated as hostile regardless of whether a connection originates inside or outside the corporate boundary.

Micro-segmentation divides the network into small, isolated zones. Traffic between zones is controlled by strict firewall rules, and workloads communicate only with the specific services they need. All traffic is encrypted — there is no assumption that internal traffic is inherently safe. This is especially important for east-west (lateral, server-to-server) traffic, which traditional perimeter controls largely ignore.

Zero Trust network access (ZTNA) tools replace VPN by granting users access to specific applications, not to the network itself. Even if a device is fully compromised, an attacker gains access only to the applications explicitly authorized for that user — not the ability to scan and pivot across internal infrastructure.

What this looks like: A remote employee connects through a ZTNA gateway. The gateway verifies their identity, device health, and context. They are granted access to the three applications their role requires. They cannot discover other servers, scan subnets, or move laterally if their device is later found to be compromised.

Pillar 4: Applications and Workloads

Applications themselves must enforce access controls independent of network location. Access decisions combine identity, device health, and request context — not just "is this request coming from inside the network?"

Application segmentation isolates workloads from each other so a compromise in one application does not spread. Just-in-time access grants temporary, scoped permissions for specific tasks and revokes them automatically when the task is complete.

What this looks like: A developer needs temporary access to a production database to investigate an incident. They request access through a privileged access management system. They are granted two hours of logged, monitored access. After two hours, access is automatically revoked with no action required.

Pillar 5: Data

Data is the ultimate asset being protected. Zero Trust focuses on protecting data at rest, in transit, and in use.

Data classification labels information according to sensitivity — public, internal, confidential, restricted — and those labels drive access controls. Encryption protects data wherever it lives. Data at rest means data sitting in storage — a database, a hard drive, a cloud bucket — and encrypting it means that even if an attacker steals the storage, they cannot read what is inside without the encryption key. Data in transit means data moving across a network — from your browser to a server, or between two internal services — and encrypting it means an attacker who intercepts that traffic sees only scrambled bytes, not the actual content. Together, these two layers ensure that a breach of storage or a compromised network connection does not automatically hand an attacker readable data. Data loss prevention (DLP) monitors data movement in real time, blocking or flagging unusual transfers.

What this looks like: A user attempts to bulk-download thousands of confidential customer records. The DLP system flags the transfer as anomalous, blocks the download, and sends an alert to the security team for investigation.

The Zero Trust Architecture

The National Institute of Standards and Technology (NIST SP 800-207) defines a standard for how Zero Trust should be built. At its core, every access request passes through three stages: it is intercepted, evaluated, and enforced.

When you try to access a resource, a gatekeeper sits in the middle and stops the request before it reaches its destination. That gatekeeper asks a decision-maker: should this be allowed? The decision-maker pulls together everything it knows — who the user is, whether their device is healthy, what they are trying to access, where they are connecting from, and whether anything looks suspicious. It returns one of three answers: allow, deny, or ask for more verification. The gatekeeper then acts on that answer and logs what happened.

In NIST's terminology, the gatekeeper is called the Policy Enforcement Point, the decision-maker is the Policy Engine, and the component that coordinates between them is the Policy Administrator. The names matter less than the concept: no request reaches its destination without being stopped, questioned, and explicitly approved.

The practical implication is that access decisions are made in real time, using the full context of the moment — not based on a login that happened eight hours ago.

Identity and Privileged Access

Because identity is the new perimeter, Zero Trust demands robust controls for the users with the most power.

Privileged users — administrators, executives, service accounts — have access to the most sensitive systems and represent the highest-risk targets. Applying standard controls to privileged accounts is not enough.

Zero Trust for privileged access includes just-in-time privilege elevation: instead of holding permanent admin rights, users request temporary elevation for a specific task and have that elevation revoked automatically. All privileged sessions are recorded for audit and forensic purposes. Separation of duties ensures critical actions require approval from more than one person. And privileged access workstations provide dedicated, hardened environments for sensitive operations — preventing administrators from browsing the web or reading email on the same machine they use to manage production infrastructure.

Service accounts deserve special attention here. Automation accounts are frequently over-privileged, rarely rotate credentials, and almost never covered by MFA or behavioral monitoring. They are an attacker's preferred path. Apply Zero Trust principles consistently: short-lived credentials, just-in-time access, and active monitoring.

Micro-Segmentation

Micro-segmentation is the Zero Trust approach to containing damage. Instead of a single perimeter, the network is divided into many small, isolated segments — each with its own enforced access rules.

In a traditional flat network, a compromised laptop can scan for other devices, probe servers, and spread laterally with little resistance. Attackers have exploited this reality in nearly every major breach of the past decade.

In a micro-segmented network, each workload is isolated. A web server can communicate with its application database — and nothing else. The database accepts connections only from that web server. A developer's laptop cannot reach the database directly; it must route through a bastion host with full session logging. Even if one workload is compromised, the attacker hits a wall at the segment boundary.

Micro-segmentation can be implemented at several layers — network (firewalls, virtual networks, security groups), hypervisor (software-defined networking), operating system (host-based firewalls), and application (service meshes like Istio enforce policy between microservices). Which layer is appropriate depends on what you are protecting, but the goal is always the same: a compromised workload should be unable to reach anything it has no legitimate business communicating with.

Continuous Verification

In traditional security, authentication happens once at login. The user is trusted for the duration of the session — which might span hours or an entire workday.

In Zero Trust, trust degrades over time unless it is actively re-established. Every request is an opportunity to re-evaluate. The system continuously monitors:

1. User behavior: Are they accessing resources they normally access? Downloading an unusual volume of data? Logging in from an unfamiliar location?
2. Device posture: Has the device fallen out of compliance? Is a patch missing? Has malware been detected since login?
3. Risk signals: Has threat intelligence flagged this user or device? Is the behavioral pattern consistent with known attack techniques?
4. Environmental changes: Did the user's location change mid-session? Did they switch from corporate Wi-Fi to a public hotspot?

When a significant change is detected, the system responds proportionally. A minor anomaly might trigger step-up authentication — requiring the user to confirm with MFA before proceeding. A high-confidence threat signal might terminate the session outright. A moderate signal might reduce the user's access to lower-risk resources while the situation is investigated.

This is where dedicated security tooling becomes essential. One category of tool — called a SIEM, short for Security Information and Event Management — acts as a central nervous system for your environment. It pulls in signals from everywhere: login events, device health checks, network traffic, application logs. It correlates them, looking for patterns that no single signal would reveal on its own. A login from London followed thirty seconds later by a login from Singapore is not suspicious in isolation — each event looks normal. Together, they are a clear sign of compromise.

A second category — called a SOAR, short for Security Orchestration, Automation and Response — acts on what the SIEM finds. Rather than waiting for a human analyst to notice an alert, investigate it, and manually revoke a session, a SOAR platform does that automatically, in seconds. By the time a person looks at the alert, the threat has already been contained.

What continuous verification catches: A user logs in from their home office. An hour later, the same session shows activity originating from a different country. The system detects the location jump, terminates the session immediately, and requires full re-authentication. The user's credentials had been stolen. Continuous verification contained the breach before any data left.

Zero Trust in Practice

Remote Access

Traditional VPN grants employees network-level access to the entire corporate environment. An attacker with stolen VPN credentials has access to everything that employee could reach.

Zero Trust replaces VPN with ZTNA(zero trust network access). The employee is granted access to the specific applications their role requires — nothing more. Lateral movement is structurally impossible, because the employee was never placed on the network in the first place.

Cloud Infrastructure

Rather than giving developers broad access to cloud consoles, Zero Trust policies scope access by role and environment. Production access requires MFA, approval, and a time-limited session. All actions are logged. Infrastructure-as-code ensures that every change is tracked and reviewable.

A compromised developer credential becomes dramatically less dangerous: the attacker has access only to what that specific role was permitted, only for the duration of the session, and every action is logged.

Third-Party Access

Contractors and partners authenticate through their own identity providers. They are granted access only to the specific applications their engagement requires. Access is time-bound and expires automatically when the contract ends. Their activity is logged separately from employee activity, making audit straightforward.

When a vendor is compromised — as supply chain attacks have repeatedly demonstrated is possible — the attacker has access only to the narrow slice of resources explicitly granted to that vendor. The blast radius is contained by design.

Securing AI and LLM Workloads

Emerging AI systems introduce new Zero Trust challenges. LLM-based applications often have broad access to internal data sources, code repositories, and APIs. They may also accept inputs from external users. Applying Zero Trust principles here means scoping AI workloads to least-privilege data access, auditing what data enters and leaves model contexts, and treating AI agents with the same skepticism as any other non-human identity — not granting them elevated trust simply because they are internal systems.

Dealing with Legacy Systems

Legacy systems are one of the most common obstacles in Zero Trust adoption. Many cannot be modified to support modern authentication, encryption, or segmentation. The answer is not to exclude them — it is to control access to them through modern means.

Isolation places legacy systems in a separate network segment. All access routes through a gateway that enforces Zero Trust policies — verifying identity, checking device health, and proxying the connection. The legacy system itself need not change.

Wrappers place a modern authentication layer in front of the legacy system. The wrapper handles authentication and authorization, then forwards the authenticated request. The user and the policy engine interact with the wrapper; the legacy system never sees unauthenticated traffic.

Air gaps are appropriate for the most critical legacy systems that cannot be secured in any other way. No network connectivity means no remote attack surface. Access requires physical presence.

Replacement is the long-term answer. Where it is feasible, replacing legacy systems with modern alternatives that natively support Zero Trust architectures eliminates the problem rather than containing it.

Zero Trust and Compliance

Zero Trust is not a compliance framework, but if you implement it well, compliance becomes significantly easier.

Most compliance standards — GDPR, HIPAA, PCI-DSS, SOC 2 — are asking for the same things at their core: know who has access to what, limit that access to only what is necessary, and keep a record of what happened. That is exactly what Zero Trust enforces. You are not doing two separate things. You are doing one thing that satisfies both.

For example, GDPR requires you to protect personal data and limit who can access it. Zero Trust's data classification and access controls do that directly. PCI-DSS requires you to isolate payment card data from the rest of your environment. Zero Trust's network segmentation does that directly. HIPAA requires strong controls over who can access patient records. Zero Trust's identity controls and continuous monitoring do that directly.

The work is not wasted. Every Zero Trust control you implement is likely covering a requirement you would have had to address through compliance anyway.

Zero Trust in the Real World

Implementing Zero Trust is a journey measured in years, not quarters. But here is something practically useful to understand: when you join a new organisation, the state of their Zero Trust implementation will tell you a lot about their security culture and maturity.

A early-stage startup will likely have almost none of this. Shared passwords, no MFA, everyone has admin access to everything, and no one has audited permissions since the company was founded. This is normal for a company moving fast, but it is also a significant risk that grows with every new employee and every new system.

A mid-sized company — a traditional business that has been operating for years — will typically have some of these controls in place. MFA probably exists, but only for some systems. There may be a VPN. Device management might cover company laptops but not phones. Network segmentation is partial. Monitoring exists but alerts are reviewed manually and infrequently. This organisation knows it has gaps but has not had the time or budget to close them all.

A large financial institution, a major hospital network, or a government agency will often have the full picture: phishing-resistant hardware keys for all users, continuous device compliance checking, micro-segmented networks, automated threat response, and regular access reviews. Security is not a feature here — it is a regulated requirement, and the organisation has invested accordingly.

As a developer, understanding where your organisation sits on this spectrum helps you ask the right questions, make appropriate decisions, and push for improvements where the gaps are most dangerous. The phases below represent the path from nothing to mature — most organisations are somewhere in the middle.

Phase 1: Foundational. Start with identity. Implement MFA for all users, prioritising privileged accounts first. Transition toward phishing-resistant MFA — hardware keys — for administrators and anyone with access to sensitive systems. Audit existing access and remove permissions that are unused or excessive. Build a complete inventory of users, devices, and applications. You cannot protect what you cannot see.

Phase 2: Control. Add device compliance checks. Non-compliant devices should be blocked from sensitive resources or confined to a restricted access tier. Begin micro-segmenting the network, starting with your most valuable assets. Implement a policy engine for access decisions, beginning with external access before expanding inward.

Phase 3: Continuous. Implement real-time monitoring of user behaviour, device posture, and environmental risk signals. Automate your responses — session termination, step-up authentication, and security alerts should not wait for a human to notice. Establish a regular cycle of access review and policy refinement, and expand Zero Trust coverage to legacy systems and AI workloads over time.

Common Zero Trust Mistakes

Treating Zero Trust as a product. No single product delivers Zero Trust. Organizations that buy a "Zero Trust solution" and consider the work done have purchased a component, not an architecture. Zero Trust requires coordinated changes across identity, devices, network, applications, and data.

Focusing only on the network. Micro-segmentation is valuable, but it is not sufficient on its own. If users still authenticate with passwords and no MFA, an attacker who steals credentials can bypass network controls entirely. Identity comes first.

Trusting the VPN. VPN grants network-level access. It does not enforce application-level controls, does not evaluate device health continuously, and provides no protection against lateral movement once a session is established. ZTNA replaces VPN — it does not extend it.

Ignoring legacy systems. Legacy systems left outside the Zero Trust architecture become the weakest point in the environment. Attackers will find them. Use isolation, wrappers, or air gaps to bring legacy systems under policy control, even if they cannot be modified directly.

Authenticating once and never re-evaluating. A stolen session token from an authenticated user is invisible to perimeter controls. Continuous verification detects the anomalies — location changes, behavioral deviations, device posture changes — that reveal a session has been hijacked.

Over-privileged service accounts. Service accounts are frequently an attacker's preferred lateral movement path: broad permissions, no MFA, infrequent credential rotation, and almost no behavioral monitoring. Apply Zero Trust to service accounts with the same rigor as human accounts.

What You Should Take Away

Zero Trust is a security model that abandons the assumption of trust based on network location. It assumes the network is compromised and verifies every request against the full context of that moment.

After reading this article, you should be able to explain why perimeter security failed — cloud, mobile, remote work, supply chain attacks, and insider threats each eroded a different assumption the castle-and-moat model depended on. You should be able to articulate the three core principles — verify explicitly, use least privilege, assume breach — and describe how they translate into the five pillars of identity, devices, network, applications, and data. You should understand the NIST Zero Trust architecture, recognize the critical role of continuous verification, and know how to apply Zero Trust thinking to remote access, cloud infrastructure, third-party access, and legacy systems.

Most importantly: Zero Trust is not a destination. You do not arrive at a Zero Trust environment on a Tuesday and declare it done. You implement it incrementally, starting with identity, expanding to devices and network segmentation, and maturing into continuous monitoring and automated response. Each phase makes the environment measurably harder to attack, even before the next phase begins.

Closing: Beyond the Castle Walls

Let us return to the castle.

The walls are still there. They are not useless. But they are no longer the boundary of trust. The castle has changed.

There are now checkpoints at every door. Every person is verified before entering any room. The kitchen cannot access the armory. The treasury cannot access the dungeon. Every movement is logged. When a servant leaves, their keys stop working immediately. When a guard's behavior becomes suspicious, they are challenged again.

The castle is more secure than ever — not because the walls are higher, but because the assumption of trust has been abandoned.

Zero Trust is the same. It is not about building higher walls. It is about recognizing that walls are no longer enough. It is about verifying every request, limiting every permission, and continuously checking that trust is still warranted.

The perimeter is gone. The castle walls have crumbled. But security has not disappeared. It has moved to where it always should have been — to the identity of the user, the health of the device, the sensitivity of the data, and the context of the request.

Never trust. Always verify.