Topic starter
24/06/2026 6:50 pm
TL;DR: Unosecur finds that Zero Trust programmes stall when teams begin with network controls, leave MFA partial, copy standing privilege into cloud roles, and ignore machine identities. The underlying issue is that Zero Trust fails as an identity programme when continuous verification, entitlement reduction, and machine-account governance are treated as optional.
Editorial analysis by NHI Mgmt Group, based on content published by Unosecur: “5 Mistakes Slowing Zero Trust Rollouts (and Fixes)”.
Key questions
Q: What breaks when Zero Trust is implemented without identity governance?
A: Zero Trust breaks when the policy engine is enforcing stale or incomplete identity data.
Q: Why do partial MFA deployments still leave Zero Trust programs exposed?
A: Because MFA only reduces risk when the highest-value identities are actually covered.
Q: When should organisations replace standing privilege with just-in-time access?
A: Organisations should replace standing privilege with just-in-time access whenever elevated access is not required continuously.
Practitioner guidance
- Build a full identity baseline first Inventory users, groups, service accounts, roles, policies, and effective permissions across cloud and on-prem.
- Eliminate MFA exceptions by cohort Target admins, contractors, finance users, and shared elevated accounts for full MFA or passwordless coverage.
- Convert standing privilege into JIT access Replace persistent cloud elevation with time-bound access workflows.
Bottom line: Zero Trust rollouts stall when teams cannot establish a complete identity baseline across users, groups, service accounts, roles, and effective permissions.
What's in the full article
Unosecur's full blog covers the operational detail this post intentionally leaves for the source:
- Step-by-step guidance for building an identity baseline across cloud, SaaS, and on-prem systems
- Practical examples of how to remove MFA exemptions and reduce friction for high-risk cohorts
- Implementation detail on converting standing privilege into JIT access for production tasks
- Operational handling for service accounts, API keys, and workload identities that need rotation and ownership
👉 Read Unosecur's analysis of why Zero Trust rollouts stall without identity baselines →
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
25/06/2026 3:49 am
Zero Trust fails first as an identity baseline problem, not a perimeter problem. The article shows that programmes stall when teams can describe network controls but cannot yet name every identity, entitlement, and owner in scope. That is a governance failure because the control model starts from incomplete identity truth. Practitioners should treat identity discovery as the prerequisite for any credible Zero Trust operating model.
A few things that frame the scale:
- 90% of IT leaders say properly managing NHIs is essential for a successful zero-trust implementation, according to the Ultimate Guide to NHIs.
A question worth separating out:
Q: How should security teams govern machine identities in zero trust environments?
A: Security teams should govern machine identities with the same discipline used for privileged human access: inventory, ownership, policy-based approval, rotation, monitoring, and revocation. Zero trust only works when every non-human credential has a known purpose and a short, enforceable lifecycle. Without that, machine access becomes a hidden standing privilege layer inside the environment.
👉 Read our full editorial: Zero Trust rollouts stall when identity baselines are incomplete