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

At a glance

What this is: This is an analysis of how IAM enables Zero Trust and why legacy integrations, SaaS sprawl, and limited visibility still block fine-grained access control.

Why it matters: It matters because IAM teams must make Zero Trust work across human, machine, and application identities without relying on static privilege or brittle perimeter-era assumptions.

By the numbers:

• Only 5.7% of organisations have full visibility into their service accounts.
• 80% of identity breaches involved compromised non-human identities such as service accounts and API keys.
• 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools.

👉 Read Unixi's analysis of how IAM enables Zero Trust

Context

Zero Trust depends on identity, not network location. In practice that means IAM must continuously authenticate users, devices, and software identities, then decide access from context rather than from a one-time login.

Unixi’s argument is that the principle is clear while the operating model is messy. Legacy IAM, SaaS sprawl, and changing entitlements make it difficult to maintain least privilege and continuous verification at the pace Zero Trust expects.

For IAM teams, the real question is how to enforce dynamic access across cloud and SaaS without inheriting perimeter-era blind spots. That is why Zero Trust discussions quickly become questions about governance, visibility, and access lifecycle.

Key questions

Q: How should security teams apply zero trust to SaaS environments?

A: Start with identity and entitlement governance, not network controls. Map every user, service account, token, workflow, and integration that can touch SaaS data, then enforce least privilege, continuous review, and revocation when the business purpose ends. Zero trust fails in SaaS when access is treated as static instead of lifecycle-managed.

Q: Why do legacy IAM systems struggle in Zero Trust environments?

A: They were built for perimeter-centric access patterns, not distributed identity stores, SaaS integrations, and continuous policy evaluation. That creates blind spots in visibility, entitlement hygiene, and monitoring. When access decisions are fragmented across systems, the organisation cannot reliably prove least privilege or respond quickly when context changes.

Q: When should organisations use ABAC instead of relying on roles alone?

A: Use ABAC when the access decision depends on context such as device posture, location, time, or risk score. Roles remain useful for organising permissions, but they do not describe runtime conditions well. If a role grant would be too broad without contextual checks, ABAC should carry the decision.

Q: Who is accountable when identity-based access fails in a Zero Trust programme?

A: Accountability sits with the identity, security, and platform owners who control entitlement design, lifecycle governance, and response automation. If service accounts, tokens, or human credentials are outside a clear ownership model, the programme cannot enforce revocation or prove that least privilege is being maintained.

Technical breakdown

How IAM operationalises continuous verification in zero trust

Zero Trust treats identity as the control plane for access. IAM makes that practical by authenticating the subject, validating the device and context, and then authorising only the minimum permissions needed for the request. That decision is not a one-time event. It must be re-evaluated as context changes, which is why modern IAM increasingly depends on conditional access, continuous monitoring, and policy-driven enforcement rather than static allow lists.

Practical implication: Practitioners should design access policies that can be re-evaluated after initial authentication, not just at login.

Why RBAC and ABAC matter more than static entitlements

RBAC reduces administrative sprawl by mapping permissions to roles instead of individual users. ABAC goes further by adding attributes such as device type, location, time, and risk context so that access can change with the request. In Zero Trust environments, that distinction matters because privilege cannot be safely inferred from membership alone. The more distributed the environment, the more RBAC and ABAC need to work together.

Practical implication: Teams should map where role design is sufficient and where attribute-based policy is needed to avoid over-granting access.

Where legacy IAM breaks under cloud and SaaS complexity

Legacy IAM platforms were often built for perimeter environments, where access paths were simpler and more centralised. Cloud and SaaS change that model by introducing multiple identity stores, external integrations, and disconnected audit trails. The result is reduced visibility into who can access what, when, and from where. That gap makes it harder to prove least privilege and harder still to sustain it across fast-changing applications.

Practical implication: Identity programmes should inventory SaaS and cloud integration gaps first, because weak integration is usually the limiting control.

Threat narrative

Attacker objective: The objective is to obtain access that looks authorised at login but exceeds the intended scope once the environment and context are taken into account.

1. Entry begins when access is requested from a user, device, or application identity that has not been fully verified in context. Escalation follows when static entitlements or weak integration let that identity retain broader access than intended. Impact occurs when the organisation cannot reliably prove or enforce least privilege across cloud and SaaS resources.

Breaches seen in the wild

• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.
• Meta AI Instagram Account Takeover — 20,225 Instagram accounts hijacked via compromised Meta AI support chatbot with overprivileged access.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Zero Trust collapses into weak policy enforcement when IAM remains perimeter-era at the core. The article correctly frames identity as the foundation of Zero Trust, but the harder issue is whether the IAM stack can continuously evaluate access across cloud, SaaS, and device context. If the identity layer cannot keep pace, Zero Trust becomes a declaration rather than an operating model. Practitioners should treat identity governance as the enforcement layer, not the administrative back office.

Static entitlement thinking is the wrong mental model for distributed access. RBAC still matters, but ABAC and contextual policy are what make Zero Trust workable across modern environments. Roles describe organisational structure, while attributes describe session reality. The practical implication is that teams must stop assuming role assignment alone can carry risk-sensitive decisions across SaaS, remote access, and machine-to-machine workflows.

Visibility into identities is now a prerequisite control, not a reporting feature. The industry cannot govern what it cannot see, and cloud plus SaaS fragmentation routinely breaks that visibility. Identity blast radius: this is the gap between access granted and access understood, and it widens when separate identity stores and unmanaged entitlements accumulate. IAM teams should treat visibility defects as exposure, not inconvenience.

Zero Trust succeeds only when authentication, authorisation, and monitoring are joined as one control loop. The article’s emphasis on continuous verification is directionally right, but the field often implements those pieces separately. That split weakens policy decisions, slows detection, and makes remediation reactive. Practitioners should align governance, policy, and monitoring around the same identity records and decision points.

From our research:

• Only 5.7% of organisations have full visibility into their service accounts, according to Ultimate Guide to NHIs.
• 79% of organisations have experienced secrets leaks, with 77% of these incidents resulting in tangible damage.
• The Ultimate Guide to NHIs , Lifecycle Processes for Managing NHIs shows where provisioning, rotation, and offboarding controls fail most often.

What this signals

Zero Trust programmes now fail or succeed on the quality of identity governance, not on the elegance of the policy language. When cloud and SaaS estates fragment visibility, teams need a better hold on service accounts, application identities, and privileged paths than most legacy IAM stacks were built to provide.

Identity blast radius: the practical measure of Zero Trust maturity is how much access remains unexplained when the audit trail is incomplete. With only 5.7% of organisations claiming full visibility into service accounts, the governance problem is already structural, not marginal.

Teams should expect access review, conditional access, and monitoring functions to converge operationally. If those controls live in separate workflows, Zero Trust becomes harder to sustain because no single team can see the whole identity decision chain.

For practitioners

• Map identity coverage across cloud and SaaS Inventory which applications still rely on separate identity stores, brittle connectors, or manual exception handling. Prioritise the systems where access decisions cannot be continuously verified or audited.
• Replace user-by-user access with governed roles and attributes Use RBAC where roles are stable, then add ABAC for device, location, time, and risk context where static roles over-grant access. Keep policy ownership in IAM, not in application-specific workarounds.
• Treat visibility gaps as security findings Review service accounts, application identities, and SaaS entitlements for missing ownership, stale permissions, and absent audit trails. If you cannot explain who can access what, you do not have enforceable least privilege.

Key takeaways

• Zero Trust depends on identity controls that can continuously verify access across cloud, SaaS, and device context.
• Legacy IAM and fragmented identity stores make least privilege difficult to prove, not just difficult to configure.
• IAM teams should treat visibility, contextual policy, and auditability as the operational test of Zero Trust maturity.

Key terms

• Zero Trust: A security model that assumes no identity — human or non-human — should be trusted by default, even inside a network perimeter. Every access request must be verified, authorised, and continuously validated.
• 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.
• 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.
• Identity Visibility: Identity visibility is the ability to see which identities exist, what they can access, and how those access paths relate across systems. In NHI programmes, it means correlating service accounts, tokens, certificates, and agents into one operational view so governance decisions are based on evidence, not assumptions.

What's in the full article

Unixi's full article covers the operational detail this post intentionally leaves for the source:

• How RBAC and ABAC are applied in specific Zero Trust access decisions across cloud and SaaS.
• The practical challenges of integrating legacy IAM with modern identity stores and access flows.
• Contextual verification details, including device checks, location signals, and continuous authentication.
• The limitations of current IAM tooling when organisations need fine-grained, dynamic enforcement.

👉 Unixi's full article covers the identity controls, integration issues, and access-model trade-offs in more detail.

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 identity security programme, it is worth exploring.