User Friction

What User Friction Means in Security Workflows

User friction is the effort required from a person to complete an access or security task, such as signing in, approving a request, resetting a factor, or following a step-up challenge. It is not inherently bad, but it becomes important when the workflow is meant to improve security and instead creates delay, confusion, or repeated manual work.

In practice, friction sits on the boundary between control strength and user experience. A workflow can be technically sound yet still perform poorly if it is slow, inconsistent, or hard to understand. When that happens, people look for shortcuts, rely on workarounds, or ask support to complete steps for them, which can weaken the control’s real-world effect.

Why User Friction Matters

Friction matters because security controls are only effective when people can and will use them correctly. If a process is too burdensome, adoption drops and the organisation may see more exceptions, more help-desk tickets, and more informal bypass behaviour. That makes friction a governance issue as much as a usability issue.

The goal is not to remove all friction, but to apply it where it adds justified protection. Stronger assurance steps are often appropriate for sensitive actions, yet the user journey should remain proportionate to the risk. Poorly designed friction tends to appear as extra clicks, repeated prompts, unclear error states, or policy logic that forces users to restart tasks unnecessarily.

Common Sources of Friction

Friction often comes from mismatched control design rather than from the control concept itself. Common causes include too many authentication steps, poorly timed reauthentication, repeated approvals, unclear ownership of access requests, and policy rules that are correct on paper but awkward in daily use.

It can also arise when security and operations teams optimise different outcomes. A control may be designed to maximise assurance, while users need speed and predictability to do their work. When those goals are not balanced, users may gravitate toward standing access, shared accounts, or informal exceptions, because those paths feel easier than the approved workflow.

How to Read Friction as a Security Signal

User friction is often an early warning signal that a control will fail socially before it fails technically. If users routinely complain, delay completion, or seek help to finish a workflow, the control may be too expensive in time or attention for the value it delivers.

That does not mean the workflow should be simplified blindly. It means the organisation should examine whether the control is proportionate, whether the steps are ordered logically, and whether the experience makes the security decision understandable. Friction becomes a useful signal when it helps identify where controls are too hard to use, too hard to explain, or too hard to sustain at scale.

Risk and Threat Considerations

Excessive friction can turn a good control into a weaker one by encouraging policy bypass, shadow process use, shared access, or repeated support intervention. It also increases the chance that users ignore prompts, accept risky defaults, or request broader access simply to avoid recurring effort.

Failure mechanism: The control remains formally in place, but its day-to-day use degrades because users and support teams work around it, misapply it, or avoid it entirely.

Impact: Security assurance drops, operational load rises, and the organisation may end up with more exceptions and less trustworthy access behaviour than the original control was meant to prevent.

Practitioner Guidance

Why practitioners should care: Friction is a design variable, not just a user complaint. If a security workflow consistently creates avoidable effort, it will usually surface later as support demand, inconsistent adoption, or control bypass.

Common misunderstanding: More steps do not automatically mean better security. The better test is whether each step changes the risk decision in a meaningful way and whether users can complete it without needing informal help.

Practitioner takeaway: Treat friction as something to measure and tune, especially in access and identity workflows where small usability defects can create large governance and adoption problems.

Related resources from NHI Mgmt Group

• How should security teams implement zero trust authentication without adding too much user friction?
• How should security teams reduce phishing risk in MFA without creating more user friction?
• How should security teams implement stronger authentication without creating more user friction?
• Why do withheld password hashes create both user friction and security risk?