Zero Trust identity is replacing perimeter-based IAM

At a glance

What this is: This is an analysis of Zero Trust identity as the replacement for perimeter-based IAM, with the key finding that identity now functions as the trust boundary.

Why it matters: It matters because IAM, PAM, and identity architecture teams need to move enforcement from network position to continuous identity verification across human and machine access.

By the numbers:

• 96 percent of organisations now prefer Zero Trust to VPN, according to eMudhra.
• 65 percent plan to retire their VPN within twelve months, according to eMudhra.

Context

Zero Trust identity is the application of never trust, always verify to every access decision, regardless of where the request originates. The article argues that the old perimeter-based IAM model is failing because the network is no longer a reliable trust boundary for users, workloads, or service-to-service traffic.

For IAM teams, the issue is not abstract architecture. Once cloud, SaaS, remote work, and machine-to-machine integrations push access outside the perimeter, identity must carry the policy decision at the point of access. That shifts governance from network placement to contextual verification, auditability, and enforcement consistency.

Key questions

Q: How should security teams implement zero trust access management across hybrid environments?

A: Start by centralizing identity, authentication, and policy decisions so access is evaluated consistently across cloud, on-prem, and SaaS resources. Then add context signals such as device posture, location, and session risk to decide whether access should continue, step up, or end. The goal is to make identity the control plane, not the network boundary.

Q: Why do perimeter-based IAM models fail in cloud and SaaS environments?

A: They fail because the assumptions behind them no longer hold. Cloud services, remote users, and service-to-service calls all move trust decisions away from the internal network, so location becomes a weak proxy for actual risk and authorisation context.

Q: What are the signs that a Zero Trust programme is not being enforced consistently?

A: A Zero Trust programme is likely failing when access still depends on trust by location, broad entitlements, or one-time authentication. Other warning signs are unmanaged exceptions, inconsistent policy enforcement across applications and networks, and access that is not clearly tied to identity and context. If teams cannot explain why a request was allowed, the control model is too loose.

Q: What is the difference between zero trust and identity as the perimeter?

A: Zero trust is the broader security model that assumes every request must be continuously verified. Identity as the perimeter is the implementation approach that makes identity, context, and policy the control point for access decisions. In practice, identity becomes the mechanism that enforces zero trust across cloud and hybrid environments, especially when users and workloads move constantly.

Technical breakdown

How Zero Trust identity turns IAM into a policy decision engine

Zero Trust identity separates authentication from trust. A request is not accepted because it comes from an internal network; it is evaluated against policy at the moment of access. In NIST SP 800-207 terms, the policy engine makes the decision, the policy administrator applies it, and the policy enforcement point blocks or permits the request. That architecture only works when identity signals are strong enough to support real-time decisions.

Practical implication: IAM teams need policy enforcement points and contextual inputs that can decide at request time, not just at login.

Why perimeter-based IAM breaks down in cloud and service-to-service access

Perimeter IAM assumed that internal traffic was trustworthy and external traffic was not. Cloud migration, SaaS adoption, remote work, and service mesh patterns broke that assumption by moving users, applications, and workloads beyond the old network edge. The result is that the firewall can still filter traffic, but it no longer defines who should get access. Identity now has to carry the authorisation decision across heterogeneous environments.

Practical implication: security teams should stop treating network location as a meaningful proxy for access trust in cloud and hybrid estates.

What continuous verification requires from human and machine identities

Continuous verification means every access decision is rechecked against current context, not frozen at the point of login. That applies to both people and non-human identities, including service accounts and workload identities. The practical challenge is consistency: human access may include device posture and behaviour, while machine access depends on credentials, scope, and service context. A Zero Trust model that excludes workloads is incomplete by design.

Practical implication: IAM governance must apply the same decision logic to workload access paths that it applies to user sessions.

Threat narrative

Attacker objective: The attacker objective is to move through trusted internal pathways by exploiting access models that still assume the network boundary is a reliable trust signal.

1. Entry occurs when access is granted on the basis of network location rather than current trust context, allowing requests from inside the perimeter to inherit false confidence.
2. Escalation follows when internal trust assumptions let a compromised account, device, or workload move across resources without a fresh identity decision.
3. Impact is broader lateral access across cloud, SaaS, and service-to-service environments because perimeter controls no longer define the security boundary.

Breaches seen in the wild

• CitrixBleed 2 2025: CitrixBleed 2 leaked NetScaler session tokens from memory, letting attackers hijack VPN sessions and skip MFA at 100+ organisations.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Identity becomes the enforcement boundary when the network stops being trustworthy: Perimeter-based IAM was built for a world in which internal traffic could be treated differently from external traffic. That assumption no longer survives cloud, SaaS, remote work, or machine-to-machine access patterns. The implication is that IAM architecture must be designed around policy decisions at the point of access, not around where the request originates.

Continuous verification is the real control shift, not just stronger login checks: Zero Trust identity only works when authentication and authorisation are re-evaluated against current context for every request. That moves the control plane from one-time admission to ongoing decisioning, which is a different governance model from legacy VPN-centric access. Practitioners should treat this as a redesign of enforcement, not a cosmetic update to authentication.

Unified policy for human and non-human identities is now a baseline expectation: The article is right to connect Zero Trust identity with machine access because service-to-service traffic now runs through the same trust problem as user access. A control model that governs people but leaves workloads on a separate path leaves a structural gap. The practitioner conclusion is simple: access policy must be unified across identity types if the perimeter is gone.

Zero Trust identity exposes a governance gap in auditability as much as in access control: The article’s emphasis on audit-ready evidence matters because regulators and internal reviewers need to understand why each decision was made. If policy decisions cannot be reconstructed, Zero Trust becomes hard to govern even when it is technically enforced. Identity programmes should therefore treat decision evidence as part of the control, not as a reporting afterthought.

From our research library:

• 90% of IT leaders say properly managing NHIs is essential for a successful zero-trust implementation, according to the Ultimate Guide to NHIs.
• By 2029, 40% of enterprises that successfully implement zero trust within cloud service provider environments will rely on the advanced visibility and control capabilities offered by CNAPP solutions.
• Read next: Zero Trust Identity Guide

What this signals

Zero Trust identity pushes governance from the network edge to the request itself: IAM teams should expect more policy dependency, not less, as perimeter signals keep losing reliability. The programme shift is toward access decisions that can be explained, logged, and enforced in real time across human and non-human identities.

Identity policy has to cover workloads if the perimeter is truly gone: Service accounts, APIs, and machine identities now sit inside the same trust model as users. If those pathways are not brought into the same policy plane, Zero Trust remains partial and adversaries will route around the controls.

Continuous verification changes the operating rhythm of IAM: Static approval models are too slow when access risk can change between requests. Practitioners should expect tighter coupling between authentication, contextual signals, and evidence generation as Zero Trust becomes the default architecture.

For practitioners

• Replace perimeter assumptions with contextual policy Map every access path that still relies on network location, then require a policy decision based on identity, device, and resource context before granting access.
• Apply the same enforcement model to workloads and users Review service accounts, API-driven access, and workload identities alongside human access so that machine-to-machine traffic is not exempt from Zero Trust policy.
• Demand audit-ready decision evidence Ensure access decisions are logged with enough context to explain why access was granted or denied, especially where policy is dynamic and risk-based.
• Prioritise phishing-resistant authentication Use passkeys, FIDO2, or certificate-based device authentication where the authentication factor itself is part of the trust decision and not just a gate at sign-in.

Key takeaways

• Perimeter-based IAM no longer matches how cloud, SaaS, remote work, and service access actually operate.
• Zero Trust identity shifts trust decisions to the point of request, which changes both enforcement and audit expectations.
• The practical test is whether human and non-human access are governed by the same contextual policy plane.

Key terms

• Zero Trust Identity Administration: Zero trust identity administration applies continuous verification and least privilege to access decisions rather than relying on a trusted network or static approval state. For non-human access, it requires tighter linkage between identity state, purpose, and actual use.
• Policy Enforcement Point: A policy enforcement point is the control that applies an authorization decision at the place where an action occurs. In distributed systems, it may sit inside an API gateway, application, or workflow engine, and it depends on a consistent decision format to avoid bespoke integrations.
• Continuous Verification: A Zero Trust practice that re-evaluates trust during the session instead of relying on a single successful login. The control is stronger when context signals are available in real time and when the identity programme can act on those signals without creating excessive exceptions.
• Machine Identity: The digital identity of a machine, device, or workload, such as a server, container, or VM, used to authenticate it within a network. Sometimes used interchangeably with NHI, though NHI is the broader category.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.