Why do zero trust programmes create so much user friction?

Why Zero Trust Feels Hard to Use in Real Organisations

zero trust programmes create friction because they challenge the assumptions that made day-to-day access feel effortless, especially broad session trust, implicit network trust, and long-lived access. That means users encounter more prompts, more policy checks, and more failure points across apps, devices, and workflows. NIST SP 800-207 Zero Trust Architecture describes the model as a continuous verification approach, which is exactly where usability pressure starts to build when the environment is fragmented.

The practical issue is not verification itself, but repetition. When access decisions are spread across multiple tools and inconsistent policies, users experience the programme as interruptions rather than protection. In practice, teams often discover this only after exceptions, shadow workflows, and ticket volume have already risen.

For organisations building out workload and machine trust alongside human access, the operational complexity is even more visible: the same guide that helps teams structure identity governance also notes that properly managing NHIs is essential to successful zero trust, and 90% of IT leaders agree. Ultimate Guide to NHIs — Standards

Where the Friction Actually Comes From

Most zero trust friction comes from how controls are implemented, not from the principle itself. A well-designed programme reduces implicit trust and narrows access, but a poorly designed one turns every task into a fresh proof-of-trust event. That is especially painful when identity state, device posture, application session handling, and authorisation rules do not line up cleanly.

• Short session lifetimes force repeated logins during normal work.
• Inconsistent policy across applications creates different user experiences for the same action.
• Poorly integrated MFA or step-up checks interrupt high-frequency workflows.
• Legacy systems often cannot support fine-grained, low-friction policy decisions.
• Excessive prompts teach users to search for workarounds rather than comply.

The balance is delicate: if controls are too loose, zero trust becomes a label without enforcement; if they are too aggressive, users start bypassing the very controls meant to reduce risk. The technical challenge is to move from repeated interruption to contextual verification, where the system asks for stronger proof only when risk meaningfully changes. That is why NIST SP 800-207 emphasises policy decision and policy enforcement separation, because the user experience depends on how intelligently those decisions are orchestrated. NIST SP 800-207 Zero Trust Architecture

These controls tend to break down when legacy apps, shared sessions, and inconsistent policy engines force every access path to behave differently.

When Friction Becomes a Security Problem Instead of a Cost of Control

Tighter verification often increases user effort, so organisations have to balance assurance against task interruption. The main edge case is when the control is technically sound but operationally brittle, because then users route around it through cached access, shared accounts, unmanaged devices, or informal exceptions.

That trade-off becomes sharper in environments with many applications, many trust domains, or many privilege levels. In those settings, one universal policy usually overfits neither risk nor workflow. More mature programmes use risk-based step-up, device trust, and application-specific policy so that only genuinely sensitive actions trigger added checks. Where the environment involves service identities and API-driven automation, the same principle applies, but the controls must also account for credential lifecycle and revocation discipline. The NHI guidance reports that only 20% of organisations have formal processes for offboarding and revoking API keys, which is a reminder that friction often appears when governance is bolted on after access has already proliferated. Ultimate Guide to NHIs

Practitioners should treat user friction as a design signal: if it is high enough to change behaviour, the control is no longer just inconvenient, it is steering users toward riskier paths.

Practitioner Guidance

What to prioritise: Start with the highest-frequency workflows and remove unnecessary re-authentication from low-risk actions before tightening sensitive ones. If the programme increases prompts uniformly, it is usually overcorrections in policy design, not a user discipline problem.

What to verify: Check whether repeated prompts are caused by short sessions, broken SSO, inconsistent policy engines, or app-specific integrations. The fix is different in each case, and the wrong fix usually moves friction somewhere else rather than reducing it.

Decision rule: If a control interrupts work often enough that users begin requesting exceptions, measure the exception path as a security weakness, not just an adoption issue. That is usually where zero trust programmes drift into shadow access patterns.

Practitioner takeaway: The goal is not zero friction, it is friction that appears only when risk changes enough to justify it, because that is the point at which verification improves security instead of training users to avoid it.

Related resources from NHI Mgmt Group

• How should security teams implement zero trust authentication without adding too much user friction?
• Why do excessive permissions create so much risk in Zero Trust programmes?
• When does zero trust IAM create more friction than risk reduction?
• Why do unmanaged devices create a zero trust gap for IAM programmes?