Zero trust’s hidden cost is identity complexity, not just policy

At a glance

What this is: This is an analysis of why zero trust deployments stall, with the key finding that identity and authentication foundations determine whether continuous verification is workable.

Why it matters: It matters to IAM and security teams because zero trust programmes often fail at the seams between human access, legacy systems, and machine-driven enforcement rather than at the policy layer itself.

By the numbers:

• 92% agree governing AI agents is critical to enterprise security, yet only 44% have implemented any policies to do so.

👉 Read Versasec's analysis of zero trust implementation challenges and MFA

Context

Zero trust is a security model that assumes no implicit trust and requires continuous verification before access is granted or extended. In practice, that model collides with legacy infrastructure, inconsistent identity controls, and user workflows that were never designed for repeated challenge and re-authentication.

For IAM teams, the failure point is rarely the slogan. It is the control plane underneath it: authentication assurance, policy consistency, and lifecycle governance across human identities, service accounts, and access edges. When those controls are uneven, zero trust becomes a collection of exceptions rather than an operating model.

The governance question is whether an organisation can enforce access decisions across old and new systems without creating friction that drives workarounds. That is why zero trust programmes should be judged on identity operability, not just on architectural intent.

Key questions

Q: How should security teams implement zero trust in legacy environments?

A: Start by identifying where legacy systems cannot support consistent continuous verification, then narrow the first rollout to access paths that can actually enforce the policy end to end. The goal is not a perfect design on day one. It is to avoid creating exception-heavy deployments that weaken identity assurance and invite workarounds.

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 a zero trust rollout is failing in practice?

A: Common warning signs include overlapping tools that do not integrate well, inconsistent policy enforcement across environments, weak visibility into asset and transaction flows, and users bypassing controls because processes are too cumbersome. If teams cannot tell who accessed what, when, and why, the program is not delivering the verification and control zero trust is supposed to provide.

Q: Should organisations prioritise phishing-resistant MFA over other identity projects?

A: For most enterprises, yes, when the goal is to reduce the most common account takeover path. It should be prioritised ahead of lower-value convenience changes because authentication weakness often becomes the first step in broader identity compromise and later governance failures.

Technical breakdown

Why zero trust becomes brittle in legacy identity estates

Zero trust depends on continuous verification, but many enterprises still run mixed estates of on-premises applications, cloud services, and older protocols that were never built for that assumption. Each legacy dependency becomes a policy translation problem, because the identity provider, the device state, and the application session may not speak the same language. The result is usually a patchwork of exceptions, custom connectors, and inconsistent enforcement boundaries. That fragmentation weakens the core promise of zero trust: that access decisions are enforced uniformly at runtime.

Practical implication: Map where your current estate cannot support consistent verification and treat those gaps as architecture debt, not isolated exceptions.

How authentication strength shapes zero trust enforcement

Zero trust is only as strong as the identity proof behind each access decision. If authentication is weak, easily replayed, or dependent on frequent prompts that users learn to bypass, then the policy layer becomes a nuisance rather than a control. Phishing-resistant authentication, including hardware-backed approaches, reduces that gap because the identity event itself is harder to fake and easier to validate. In that sense, strong authentication is not a bolt-on feature. It is the base signal that makes continuous authorisation credible.

Practical implication: Prioritise phishing-resistant authentication for the accounts and access paths that anchor your zero trust rollout.

Why user friction can turn policy into shadow IT

When users are challenged too often, they start to optimise around the control instead of through it. They may reuse sessions, share credentials, delay access changes, or route work through unsanctioned tools that feel faster than compliant access paths. That behaviour does not mean the zero trust model is wrong. It means the operating design is misaligned with how people complete work under time pressure. In mature programmes, the control objective is not just blocking risky access. It is preserving secure access in a way people can actually use.

Practical implication: Test authentication and step-up flows with real user journeys before broad rollout, especially for time-sensitive roles and shared applications.

Threat narrative

Attacker objective: The objective is to exploit weak or bypassed identity controls so access can be obtained or retained outside the intended zero trust decision model.

1. Entry occurs when users or operators encounter repeated re-authentication and begin looking for faster access paths around the intended control.
2. Escalation follows when workarounds such as account sharing, unsanctioned access paths, or ignored policy exceptions create inconsistent enforcement.
3. Impact is the erosion of zero trust assurance, because access decisions no longer reflect the identity and context the programme was meant to verify.

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 fails first as an identity-operability problem, not a network design problem. The article correctly shows that the hardest work is mapping access decisions across fragmented estates where policies, sessions, and device context do not line up cleanly. That is why zero trust programmes stall in implementation, not in principle. The practitioner conclusion is that architectural intent must be tested against identity enforcement reality.

Strong authentication is the hinge control for continuous verification. If the identity assertion cannot be trusted, every downstream authorisation step becomes brittle. Passwordless and phishing-resistant methods reduce the chance that the verification layer itself becomes the weakest link. Practitioners should treat authentication assurance as the prerequisite for any durable zero trust decision model.

Identity friction debt: repeated challenge prompts create workarounds that undermine the very controls zero trust depends on. The article’s user-experience warning is operationally important because frustrated users often create shadow access paths that are invisible to policy owners. That is not a UX side effect; it is governance drift. The conclusion for security leaders is to measure friction as a control-risk signal, not a convenience metric.

Zero trust governance must span human identity, workload access, and legacy application exceptions. The model breaks when teams optimise one lane while leaving others unmanaged. A mature programme therefore aligns authentication strength, access review discipline, and exception management across all identity types. Practitioners should govern zero trust as an identity lifecycle programme, not a point solution deployment.

From our research:

• 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, according to The State of Non-Human Identity Security.
• 38% of organisations report no or low visibility into those OAuth-connected vendors, which leaves access governance blind at the third-party boundary.
• That visibility problem is a strong signal to connect zero trust policy design with identity inventory and offboarding discipline, as covered in Top 10 NHI Issues.

What this signals

Identity operability will become the deciding factor in zero trust maturity. As organisations expand policy coverage, the practical limit is no longer concept adoption but enforcement consistency across fragmented systems. Teams that cannot see, classify, and govern every access path will keep adding exceptions, which turns zero trust into a framework of partial controls rather than continuous assurance.

User friction is now a governance metric. If repeated challenge prompts are driving account sharing or shadow IT, the programme is already leaking value from the control plane. Security leaders should watch for that friction in the same way they watch for false positives or policy drift, because the operational signal is telling them where the model is breaking down.

The most durable programmes will anchor zero trust in identity lifecycle controls, not just authentication events. That means pairing access policy with review, exception expiry, and governance for the systems that still sit outside modern verification flows.

For practitioners

• Map identity exceptions across the estate Document every legacy application, protocol gap, and custom bypass that prevents uniform continuous verification so policy owners can see where zero trust is already degraded.
• Prioritise phishing-resistant authentication for high-risk access Move the most sensitive user journeys, administrative workflows, and remote access paths onto hardware-backed or otherwise phishing-resistant methods before widening policy scope.
• Measure user friction as a security signal Track repeated prompts, session resets, and account sharing reports to identify where the control design is pushing users toward unsanctioned workarounds.
• Govern exceptions as lifecycle items Treat each zero trust exception as time-bound and owned, with a review path that covers human accounts, service access, and legacy dependencies.

Key takeaways

• Zero trust fails when identity enforcement cannot keep pace with legacy complexity and user workflows.
• Authentication strength and user friction are central control variables, not secondary implementation details.
• The practical path is to govern zero trust as an identity programme with exceptions, lifecycle ownership, and phishing-resistant access.

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.
• Phishing-Resistant Authentication: Phishing-resistant authentication proves identity without relying on a user to approve a prompt or reveal a reusable secret. It typically binds access to a device, key, or cryptographic proof that an attacker cannot easily reuse or coerce. This approach reduces reliance on human judgment at login time.
• Identity exception: An identity exception is any account, authentication path, or access rule that sits outside the standard control model. Exceptions often exist for operational convenience, but they are also where attackers find the easiest bypasses because the governance review is weakest there.
• Identity Operability: The practical ability of an identity programme to enforce policy consistently across applications, workflows, and user journeys. It is the difference between a design that exists on paper and one that can actually be used without generating bypass behaviour or control drift.

What's in the full article

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

• The article walks through the implementation pain points behind continuous verification in mixed legacy and cloud estates.
• It explains the user-experience trade-offs around repeated re-authentication and how those trade-offs affect adoption.
• It outlines the role of passwordless MFA and on-premise credential management in reducing friction for regulated environments.
• It gives a vendor-specific view of how credential administration fits into a zero trust rollout.

👉 Versasec's full post covers the authentication, legacy integration, and user-friction detail behind the zero trust argument.

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.