Over 25 years in engineering, I’ve watched the way we think about security change dramatically. There was a time when security was easy to visualise: a clear boundary, an internal network, an external network, and a firewall separating the two. The underlying assumption was simple: if something was inside the corporate network, it was probably trusted.
That model served us well for years. Today, it’s one of our biggest security risks.
The perimeter hasn’t just become harder to defend. In many organisations, it no longer exists in any meaningful way. Cloud platforms, SaaS applications, remote work, mobile devices, third-party partners, and now AI agents have spread users, workloads, and data across environments that no single network boundary can protect.
What remains constant in every access request (whether it comes from a person, a workload, an API, or an AI agent) is identity. That’s why identity has become the foundation of modern security. As traditional network boundaries have faded, Zero Trust has evolved from an interesting security concept into the operating model many organisations now rely on.
From Network Perimeters to “Never Trust, Always Verify”
Zero Trust isn’t a new concept. John Kindervag introduced the idea at Forrester around 2009, challenging one long-standing assumption in enterprise security:
Trust is not a security control. It’s a vulnerability.
Instead of assuming users or systems inside the corporate network are trustworthy, Zero Trust starts from the opposite premise: every request should be verified, regardless of where it originates.
That idea has since evolved from philosophy to practical framework:
- 2020: NIST published SP 800-207, establishing foundational Zero Trust Architecture guidance
- 2023: CISA released Version 2.0 of its Zero Trust Maturity Model, giving organisations a roadmap to measure progress
- June 2025: NIST published SP 1800-35, a hands-on implementation guide developed with 24 technology vendors across 19 reference architectures
The discussion has largely moved beyond whether organisations should adopt Zero Trust. The real challenge is how to implement it effectively without disrupting the business.
Identity Has Become the Universal Control Plane
CISA’s Zero Trust Maturity Model is built around five core pillars:
- Identity
- Devices
- Networks
- Applications & Workloads
- Data
These are supported by three cross-cutting capabilities: Visibility & Analytics, Automation & Orchestration, and Governance.
Identity is listed first, and that’s not by accident. Every access decision starts with establishing who, or what, is requesting access. Before a policy can evaluate device health, network location, or data sensitivity, it needs to know the identity behind the request. That identity could belong to an employee, a contractor, an application, a workload, an API, or (increasingly) an AI agent.
Attackers understand this shift just as well as defenders do. Instead of trying to break through a network perimeter, they’re far more likely to target identities: stealing credentials, hijacking sessions, or abusing tokens. In a world where users, workloads, and applications are spread across on-premises infrastructure, multiple clouds, and SaaS platforms, the network is no longer the one constant. Identity is.
Authentication Is an Event. Trust Is a State.
Traditional security often treats authentication as a one-time event. A user signs in, completes MFA, and is considered trusted for the rest of the session. Zero Trust takes a different approach.
Logging in is just the starting point, not the finish line.
Once access is granted, trust isn’t assumed indefinitely. Every session is continuously evaluated using signals such as:
- Identity assurance
- Device health and compliance
- User behaviour
- Location
- Workload identity
- Resource sensitivity
- Real-time risk indicators
If any of those signals change in a way that increases risk, the level of access should change as well. This continuous evaluation helps reduce the impact of session hijacking, stolen OAuth tokens, cookie theft, credential replay, and insider compromise.
The mindset is fundamentally different from traditional security. Instead of asking “Was this user successfully authenticated earlier today?”, Zero Trust keeps asking: “Based on everything we know right now, should this identity still have access?”
Conditional Access: Decisions Made in Context
Continuous verification only works when backed by intelligent policy. Rather than making a one-time decision at sign-in, Conditional Access evaluates multiple signals before granting access and continues to monitor them throughout the session.
The question is no longer simply “Can this user sign in?” Instead, it’s: “Should this identity be allowed to access this resource, from this device, at this location, under these conditions, right now?”
A mature Zero Trust implementation typically combines:
Phishing-resistant MFA: Passkeys, FIDO2 security keys, and hardware authenticators offer much stronger protection than SMS or one-time codes.
Device posture: Access decisions account for whether the device is managed, encrypted, fully patched, compliant with security policies, and in a healthy state.
Risk-based authentication: If unusual behaviour or elevated risk is detected, the system can require additional verification, limit access, or terminate the session.
Least privilege: Users should only have the permissions they need for their current tasks. Limiting access reduces the potential impact if an account is compromised.
Just-in-time access: Administrative privileges shouldn’t be permanent. Granting elevated access only when needed, and only for as long as needed, significantly reduces the attack surface.
When these controls work together, the experience is usually seamless for legitimate users. For attackers, every additional signal they can’t satisfy becomes another obstacle, making it much harder to turn stolen credentials into a successful compromise.
Building Zero Trust Without Breaking the Business
This is where many Zero Trust initiatives run into trouble. The challenge usually isn’t understanding the principles; it’s putting them into practice across complex environments filled with legacy systems, diverse applications, and competing business priorities.
The organisations that make the most progress rarely try to transform everything at once. They take an incremental approach, learning and adjusting as they go.
Start with a single protect surface. Rather than securing the entire enterprise on day one, focus on one critical application, workload, or business process. Prove the approach, refine it, and expand from there.
Strengthen identity first. Improvements such as stronger authentication, better identity governance, and tighter access controls can deliver immediate security benefits without requiring major infrastructure changes.
Observe before you enforce. Before introducing restrictive policies, build visibility into how users and applications actually access resources. The best policies are based on real usage patterns, not assumptions.
Automate your response. When risk levels change, security controls should respond automatically (revoking sessions, disabling accounts, rotating credentials, or requiring additional authentication) without waiting for manual intervention.
Continuously refine policies. Zero Trust isn’t a “set it and forget it” model. User behaviour changes, applications evolve, and new threats emerge.
That’s why I think of Zero Trust as an operating model rather than a project. You don’t deploy it once and declare victory. You build it over time, measure what’s working, adjust where needed, and keep improving.
Common Misconceptions
“We bought a Zero Trust product.” Zero Trust isn’t something you can buy off the shelf. It’s a security strategy that combines identity, devices, networks, applications, data, and policy into a cohesive approach. Technology enables Zero Trust, but no single product delivers it.
“We’ve enabled MFA, so we’re done.” MFA is an essential first step, but only one piece of the puzzle. Zero Trust also relies on continuous verification, adaptive access policies, behavioural analysis, least privilege, and automated response.
“We’ll transform everything at once.” Trying to implement Zero Trust across the entire organisation in one go often leads to unnecessary complexity and user frustration. Start with a well-defined scope, demonstrate value, then expand incrementally.
“Legacy exceptions won’t matter.” Every permanent exception creates a potential weak spot. Over time, these accumulate into the forgotten pathways attackers often exploit.
The Next Frontier: AI Agents and Machine Identities
One of the biggest changes since Zero Trust was first introduced is that people are no longer the only (or even the primary) identities operating in many enterprise environments.
Today, organisations manage service accounts, workload identities, APIs, certificates, containers, and AI agents. In many cases, these non-human identities already outnumber human users by a significant margin.
What’s different now is the emergence of AI agents. Unlike traditional automation that follows predefined scripts, AI agents can reason through problems, plan a series of actions, interact with multiple systems, operate continuously, and make decisions with minimal human intervention. In many ways, they’re beginning to resemble digital coworkers.
If AI agents are going to access applications, retrieve sensitive data, execute workflows, and make decisions on behalf of users, they need to be governed with the same discipline we apply to human identities. That means:
- Discover and inventory every machine identity
- Assign clear ownership and accountability
- Enforce least privilege by removing unnecessary permissions
- Replace long-lived secrets with short-lived, managed credentials
- Continuously monitor behaviour to detect anomalies or compromise
Every AI agent should be treated as a first-class identity: authenticated, authorised, monitored, and governed throughout its lifecycle.
Identity Is the New Perimeter
If I had to summarise Zero Trust in a single sentence:
Never trust. Always verify. And keep verifying.
Instead of relying on a single control to keep attackers out, Zero Trust layers multiple controls so that if one fails, others are still there to reduce risk. If credentials are stolen, continuous risk evaluation can detect suspicious activity. If a session is hijacked, adaptive access policies can restrict or terminate it before an attacker moves further. If an AI agent or workload is compromised, least privilege helps contain the impact.
Every employee. Every contractor. Every workload. Every API. Every service account. Every AI agent: each of these identities needs to be authenticated, authorised, continuously monitored, and governed according to the level of risk it presents.
In a cloud-first, AI-driven world, trust is no longer something that’s granted once and forgotten. It has to be earned continuously, with every request and every interaction.
This is Issue 3 of the Cloud, AI & Security Insights newsletter.
References: NIST SP 800-207, Zero Trust Architecture (2020) · NIST SP 1800-35, Implementing a Zero Trust Architecture (2025) · CISA, Zero Trust Maturity Model v2.0 (2023) · Cisco Talos, 2025 Year in Review · Verizon DBIR · Cloud Security Alliance, Agentic Trust Framework (2026)