By NHI Mgmt Group Editorial TeamBased on Versasec: “The Uncomfortable Truth About Zero Trust (And How to Fix It)” (September 10, 2026)

TL;DR: Zero trust fails in practice when organisations try to layer continuous verification onto legacy estates, fragmented policies, and poor user experience, according to Versasec. The real constraint is identity design, because zero trust only works when authentication, device trust, and access governance can be enforced consistently across every path.


At a glance

What this is: This is an analysis of why zero trust deployments stall, with the article’s key finding that identity complexity, not policy alone, is what makes continuous verification hard to sustain.

Why it matters: IAM teams need to see zero trust as an identity architecture problem as much as a network or policy problem, because fragmented authentication and governance create rollout failures and workarounds that weaken control.


Context

Zero trust is a security model that assumes no implicit trust and requires verification at each access decision. In practice, the article argues that the hardest part is not the slogan but the identity plumbing needed to enforce it across old and new systems.

For IAM and security teams, the problem is programme-wide: legacy estates, inconsistent policy enforcement, and repeated authentication prompts can turn a clean design into a messy operational compromise. That makes zero trust adoption as much an identity governance challenge as a technical one.

The article’s focus is typical of modern enterprise environments, where the blocker is usually not intent but the inability to apply consistent authentication and authorisation across every application, device, and data path.


Key questions

Q: What breaks when legacy identity systems are ignored in OT zero trust programmes?

A: If legacy identity sources are bypassed, organisations often create shadow processes, manual exceptions, or brittle migrations that weaken governance. OT access paths rarely disappear just because a modern identity platform is introduced. The result is usually fragmented control, unclear accountability, and more operational risk than the original model had.

Q: Why do zero trust programmes create so much user friction?

A: They usually layer repeated verification on top of workflows that were never designed for frequent re-authentication, especially where applications, sessions, and access paths are fragmented. When the control interrupts work too often, users optimise around it. That is why friction must be treated as a security design variable, not just an adoption problem.

Q: What are the signs that identity controls are not supporting zero trust as intended?

A: Common signs include accounts not using MFA, service accounts being reused for user access, identity stores outside admin control, and assets being accessed through paths that bypass ZTNA or PAM policy. Another warning sign is incomplete visibility into user, service, and device accounts. When those signals appear together, identity governance is not enforcing the intended zero trust boundary.

Q: Should organisations prioritise identity governance before micro-segmentation in Zero Trust?

A: In most hybrid and cloud-first environments, yes. Identity governance addresses who gets access and whether that access still makes sense, while segmentation mainly constrains where traffic can go. If the underlying identity model is weak, segmentation often just contains bad access rather than preventing it.


Technical breakdown

Why zero trust becomes an identity integration problem

Zero trust depends on strong identity signals at every decision point, but most enterprises do not operate in a greenfield environment. They must layer continuous verification over on-premises systems, cloud services, and older applications that were never designed for it. That creates policy translation problems, where one control model has to fit many authentication patterns, device trust states, and access flows. The result is not simply complexity. It is inconsistent enforcement, which creates gaps between the policy design and the actual runtime decision.

Practical implication: map which applications cannot enforce the same verification standard before treating zero trust as an estate-wide control.

Why user friction becomes a security failure

Repeated re-authentication is not just an experience issue. It changes user behaviour. When access prompts interrupt time-sensitive work, users look for shortcuts such as shared accounts, unsanctioned tools, or delayed transitions that preserve productivity but weaken governance. In zero trust terms, that means the control can create bypass pressure if the authentication path is too noisy or slow. Security fatigue is therefore a control design signal, not merely a usability complaint. A zero trust programme that users resist will quietly accumulate exceptions and shadow processes.

Practical implication: treat authentication friction as a governance signal and review where users are being forced into workarounds.

Why authentication architecture matters more than policy intent

The article argues that the real enabler is not a slogan but a dependable authentication foundation. Passwordless MFA and centrally managed credentials reduce the dependence on repeated password prompts while preserving strong verification. That shifts zero trust from a policy ambition into an enforceable identity pattern. In legacy environments, the architectural question is whether modern authentication can be extended without replacing every system. If it cannot, the programme becomes partial by design and depends on manual exceptions.

Practical implication: prioritise identity architecture that can extend modern authentication to legacy systems without creating exception-heavy enforcement.


NHI Mgmt Group analysis

Zero trust fails first at the identity layer, not the policy layer. The article shows that continuous verification is only as strong as the authentication and authorisation paths underneath it. When those paths are fragmented across legacy and cloud systems, policy coherence collapses into exception handling. For practitioners, the control problem is consistency, not doctrine.

Identity complexity is the hidden cost centre of zero trust. Organisations often budget for tooling and monitoring, but the real drain is the work of mapping users, devices, and flows across environments that were never designed to share one control model. That is a governance problem because every workaround becomes an implicit exception to the architecture. Practitioners need to view exception growth as a programme-risk indicator.

Passwordless MFA is not a convenience layer but an architectural stabiliser. The article’s point is that stronger authentication can reduce both friction and support overhead while making verification more consistent. In zero trust terms, the value is less about the factor itself and more about removing failure-prone interaction loops. Practitioners should see authentication design as the mechanism that decides whether zero trust scales.

Identity verification debt: Legacy estates accumulate deferred authentication choices that later surface as zero trust complexity, user resistance, and policy inconsistency. The more systems rely on divergent access paths, the more costly it becomes to impose one verification model. The implication for practitioners is to treat identity standardisation as a prerequisite for enforceable zero trust, not a later cleanup task.

From our research library:

What this signals

Identity standardisation is the gating factor for zero trust adoption. Organisations that try to impose continuous verification on fragmented estates usually discover that the architecture, not the policy, determines whether the control can be sustained. The practical lesson is that enforcement consistency matters more than the branding of the programme.

Zero trust introduces a new form of identity debt. Every exception needed to accommodate legacy applications, poor device signals, or unusable user flows becomes a future governance burden. Practitioners should treat exception volume as a leading indicator that the programme is drifting away from its design assumptions.


For practitioners

  • Map identity enforcement gaps across the estate Inventory where continuous verification cannot be applied consistently across on-premises, cloud, and legacy applications. Document every exception path so the programme reflects actual enforcement, not intended architecture.
  • Reduce re-authentication churn Review where repeated prompts are causing users to delay work, share accounts, or adopt unsanctioned alternatives. Remove unnecessary prompts and align step-up checks to risk rather than routine workflow.
  • Standardise on stronger authentication for high-friction paths Use passwordless MFA or equivalent phishing-resistant authentication where repeated credential entry is creating support load and user resistance. Keep the identity flow consistent across the most common access routes.
  • Track exception growth as a governance metric Measure how many applications, teams, or workflows rely on special handling to fit zero trust policy. Rising exception counts usually indicate the architecture is being forced past its design limit.

Key takeaways

  • Zero trust often fails because identity and authentication paths are inconsistent across the estate, not because the concept is flawed.
  • Legacy systems and repeated prompts create workarounds that weaken policy enforcement and reduce trust in the control model.
  • Practitioners should focus on identity standardisation and exception reduction before expanding zero trust coverage.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

NIST SP 800-63, NIST Zero Trust (SP 800-207), NIST CSF 2.0, NIST SP 800-53 Rev 5 and CIS Controls v8 set the governance and control requirements practitioners need to meet.

FrameworkControl / ReferenceRelevance
NIST SP 800-63SP 800-63B — AuthenticationThe article centres on authentication strength and friction in continuous verification.
Recommendation — Apply SP 800-63B to strengthen authentication paths that support continuous verification without excessive friction.
NIST Zero Trust (SP 800-207)Zero Trust ArchitectureThe whole article is about the practical limits of zero trust enforcement across mixed estates.
Recommendation — Use Zero Trust Architecture principles to align policy enforcement with real identity and device trust signals.
NIST CSF 2.0PR.AA-05 — Access Permissions, Entitlements and AuthorizationsThe article focuses on how access decisions and entitlement enforcement break across fragmented systems.
Recommendation — Review PR.AA-05 implementations to ensure permissions and authorisations are enforced consistently.
NIST SP 800-53 Rev 5IA-5 — Authenticator ManagementPasswordless MFA and credential handling are central to the proposed solution path.
Recommendation — Use IA-5 to standardise authenticator management and reduce repeated password-based access steps.
CIS Controls v8CIS-5 — Account ManagementThe article highlights account handling problems created by identity sprawl and workarounds.
Recommendation — Apply CIS-5 to remove ad hoc account handling and reduce exceptions in zero trust workflows.

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.
  • 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.
  • Passwordless MFA: An authentication approach that replaces passwords and code-based second factors with device-bound cryptography and local user verification. The user proves possession of a trusted device and then unlocks it with a biometric or similar control, reducing reliance on reusable secrets and delivery channels that can be intercepted.

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 responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.
NHIMG Editorial Note
Published by the NHIMG editorial team on September 14, 2026.
Updated on October 11, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org