Zero trust depends on identity-first IAM, but implementation lags

At a glance

What this is: NHI Mgmt Group's analysis, drawing on Unixi's blog post: Zero trust depends on identity-first IAM, but legacy architecture, SaaS integration gaps, and limited access visibility keep many organisations from enforcing it consistently.

Why it matters: For IAM practitioners, the issue is not whether zero trust is sound, but whether identity controls can deliver continuous verification, least privilege, and context-based authorisation across human, device, and application access.

Context

Zero trust assumes identity can be verified continuously and access can be re-evaluated in context, not just at login. In practice, that means IAM has to govern humans, devices, and software identities as they request access across cloud and SaaS environments.

Unixi’s argument is that this model is straightforward in principle but difficult to operationalise when legacy IAM was built for perimeter security, not dynamic access decisions. The gap is not the zero-trust concept itself, but the control plane that has to enforce it.

For identity teams, the question becomes whether existing IAM, RBAC, and ABAC implementations are mature enough to keep pace with access sprawl, changing privilege, and incomplete visibility.

Key questions

Q: What breaks when zero trust IAM is implemented as a one-time login control?

A: Standing access and durable privilege break the model, because zero trust depends on re-evaluating trust at the point of use. If the original decision never changes, the programme is only authenticating once, not continuously verifying access.

Q: Why do SaaS environments make zero trust harder to govern?

A: SaaS environments spread access across many applications, data stores, and control planes, which makes it difficult to see who has what access and whether that access is still justified. The result is fragmented governance, slower reviews, and weaker enforcement when permissions drift beyond their intended scope.

Q: How should security teams combine RBAC and ABAC in a Zero Trust programme?

A: Use RBAC for broad, routine access and ABAC for sensitive decisions where context changes the risk. That gives you a stable entitlement model for everyday work while adding request-time controls for production changes, data exports, and admin actions. The goal is not replacement. It is to keep the access model simple where possible and precise where it matters.

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.

Technical breakdown

Why identity-first zero trust depends on continuous verification

Zero trust treats identity as the control point for every access request, which is why authentication and authorisation cannot stop after the initial login. In this model, human users, devices, and applications all present identities that must be checked against context such as location, device state, behaviour, and privilege scope. IAM becomes the enforcement layer that translates “never trust, always verify” into access decisions. RBAC provides role-based assignment, while ABAC adds context-sensitive policy evaluation. Without continuous verification, zero trust becomes a policy statement rather than an operational control.

Practical implication: align your IAM design so access decisions are re-evaluated as context changes, not only when credentials are first presented.

Why legacy IAM struggles in cloud and SaaS environments

Legacy IAM tools were commonly designed around perimeter assumptions, where the main task was controlling access inside a known boundary. Cloud and SaaS environments break that assumption because identity data and access paths are distributed across multiple services, many of which maintain separate identity stores. That creates inconsistent authorisation logic, stale entitlements, and gaps in audit visibility. Fine-grained access control becomes harder when the IAM layer cannot see the full request context or maintain timely synchronisation with downstream applications. In zero trust terms, the policy may exist, but the enforcement surface is fragmented.

Practical implication: inventory where identity decisions are being made outside central IAM, because those are the places zero trust becomes inconsistent.

How RBAC and ABAC change the operational model

RBAC and ABAC are the two IAM patterns most relevant here because they move access from manual, user-by-user grants toward scalable policy enforcement. RBAC limits permissions through roles, which reduces administrative drift but can still become coarse when roles multiply. ABAC goes further by using attributes such as device type, location, and time of day to decide whether access should be allowed. That makes it better suited to zero trust, where the same user may be trusted in one context and denied in another. The trade-off is governance complexity, because the policy model has to stay understandable and maintainable.

Practical implication: use RBAC for baseline structure and ABAC for contextual enforcement where zero trust decisions need finer granularity.

Threat narrative

Attacker objective: The attacker objective is to obtain access that should have been denied or narrowed by continuous identity verification and context-aware authorisation.

1. Entry occurs when a user, device, or application requests access from outside the trusted perimeter and the environment has to decide in real time whether to trust it.
2. Credential and context checks can fail if the IAM layer lacks visibility into device posture, location, behaviour, or the state of privileges already assigned elsewhere.
3. Escalation happens when stale rights, separate identity stores, or coarse roles allow a requester to obtain more access than zero trust intended.
4. Impact is unauthorised or over-broad access inside cloud and SaaS environments, with weak auditability making it harder to detect and constrain misuse.

Breaches seen in the wild

• Microsoft Midnight Blizzard breach: Midnight Blizzard (APT29) exploited legacy test account without MFA to breach Microsoft.

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-first zero trust is only as strong as the IAM control plane behind it. The framework’s promise depends on continuous verification, least privilege, and contextual authorisation being enforceable across every request path. When IAM is fragmented across cloud and SaaS, zero trust degrades into policy intent without operational reach. Practitioners should treat identity enforcement coverage as the real zero-trust maturity test.

Legacy IAM was designed for perimeter control, not distributed identity decisions. That assumption fails in cloud and SaaS estates where identities, entitlements, and resource owners are spread across multiple administrative planes. The result is not just integration friction, but a structural mismatch between how access is granted and how zero trust expects access to be evaluated. Identity teams need to recognise this as an architecture problem, not a tuning issue.

Granular access control becomes a governance problem before it becomes a technology problem. RBAC and ABAC only help if privilege models are maintained tightly enough to reflect real access needs and context. Once roles become bloated or attributes are inconsistent, the control starts to drift away from least privilege. The practical conclusion is that access design, not authentication alone, determines whether zero trust is actually being enforced.

Identity visibility gap: The hardest zero-trust failure is often not the absence of a control, but the absence of complete identity telemetry across systems that make their own access decisions. If IAM cannot see who accessed what, when, and under which context, continuous verification cannot be audited or improved. That makes visibility a governance dependency, not just a reporting feature. Practitioners should measure whether their identity data is complete enough to support policy enforcement decisions.

Continuous verification must cover machines and applications, not only human users. The article correctly includes devices and software applications in the zero-trust identity model, which is where many programmes still weaken in practice. Once machine access is governed separately from human access, policy exceptions start to accumulate. Identity architecture should therefore be assessed across all requester types, not just employees.

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.
• Read next: IAM and IGA Basics

What this signals

Identity-first zero trust only works when policy decisions remain observable across the full access chain. As cloud estates expand, the programme risk shifts from lack of intent to lack of enforceable telemetry. Security teams should be checking whether identity data, device posture, and authorisation outcomes can still be correlated cleanly across systems, because zero trust without that evidence becomes difficult to govern.

The most practical near-term test is whether access decisions can be explained after the fact. If your IAM layer cannot show why a request was allowed, which attributes were used, and where privilege was granted, then continuous verification is not truly operating as designed.

For practitioners

• Map zero-trust decision points Identify where authentication, authorisation, and device validation are actually happening across cloud and SaaS applications, then mark the places where IAM does not control the decision path.
• Reduce privilege drift in role design Review RBAC structures for over-broad roles and stale permissions, then narrow access so each role reflects a current task set rather than historical accumulation.
• Add contextual policy signals Use ABAC attributes such as device state, location, and time of day where zero trust decisions need more precision than role membership can provide.
• Close identity visibility gaps Validate that access logs, entitlement data, and identity events are centrally observable so policy enforcement can be audited across distributed environments.

Key takeaways

• Zero trust depends on identity controls that can evaluate requests continuously across human, device, and application identities.
• Legacy IAM, separate identity stores, and weak cross-system visibility are the main reasons zero trust stalls in cloud and SaaS environments.
• RBAC and ABAC are useful only when they are governed as part of a coherent access decision model, not as isolated technical features.

Key terms

• Identity-first Zero Trust: An access model that treats identity as the primary enforcement point instead of network location. Every request is evaluated using context, entitlements, and risk signals so trust is continuously earned rather than assumed.
• Context-Aware Authorization: Context-aware authorization evaluates signals such as device posture, time, resource sensitivity, and request type before allowing access. It moves IAM away from static permission checks and toward decisions that reflect current risk, which is essential in cloud-native environments with frequent identity changes.
• Role-Based Access Control: A model that grants permissions by assigning identities to predefined roles. It works well when jobs are stable and access patterns are predictable, but it becomes brittle when exceptions pile up. In practice, role design must stay small enough to audit and broad enough to avoid endless custom variants.
• Attribute-Based Access Control: Attribute-Based Access Control is a policy model that grants or denies access using attributes such as user role, device state, location, and application context. It replaces purely static role assignment with a decision process that can adapt to current conditions, provided the underlying attributes are trustworthy and well-governed.

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.