Notifications
Clear all
Topic starter
27/08/2026 8:35 am
TL;DR: Zero Trust depends on continuous identity verification, granular least privilege, and context-aware access decisions, but Unixi argues that legacy IAM, SaaS sprawl, and weak visibility still make that hard to operationalise. The practical issue is not the principle itself but whether identity controls can keep pace across cloud, SaaS, and device context.
NHIMG editorial — based on content published by Unixi: Identity and Access Management as a critical component of Zero Trust
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.
Questions worth separating out
Q: How should security teams apply zero trust to SaaS environments?
A: Start with identity and entitlement governance, not network controls.
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.
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.
Practitioner guidance
- Map identity coverage across cloud and SaaS Inventory which applications still rely on separate identity stores, brittle connectors, or manual exception handling.
- 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.
- Treat visibility gaps as security findings Review service accounts, application identities, and SaaS entitlements for missing ownership, stale permissions, and absent audit trails.
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.
👉 Read Unixi's analysis of how IAM enables Zero Trust →
Identity-first zero trust: where IAM teams still hit the wall?
Explore further
27/08/2026 8:35 am
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: Zero trust depends on identity-first IAM, but implementation lags
