What are the signs that security controls are creating too much user friction?

Watch for unusual drops in conversion, rising bounce rate, longer time on page, and changes in login or enrollment behavior. Those patterns can indicate that users are struggling with security steps, but they can also signal malicious activity. Teams should compare the signals against normal baselines before changing controls.

When security controls start losing users, the signal is usually operational before it is technical

Excessive friction shows up when a control changes behaviour enough that people avoid it, work around it, or abandon a task. For security teams, that matters because a control that users bypass may reduce real protection even if it looks strong on paper. In a web, SaaS, or identity-heavy flow, the first warning is often not a formal complaint; it is a measurable shift in completion, engagement, and support demand. NIST’s Security and Privacy Controls is useful here because it frames controls as something that must be effective in context, not merely present in policy. In practice, teams usually discover friction only after users have already developed avoidance habits, not while the control is still being piloted.

How to read the pattern without confusing friction for normal security noise

The key question is whether the control is failing because it is hard to use, or whether it is correctly resisting abnormal behaviour. A small increase in retries, prompts, or abandonment is not automatically bad. What matters is whether the change is concentrated in a specific journey, device class, user group, or access step, and whether it persists after normal seasonal or campaign effects are removed. Good analysis compares the control path with adjacent journeys that should behave similarly, such as similar logins, similar onboarding steps, or similar approval flows.

Useful indicators usually appear together. A control may be too aggressive if:

users repeatedly restart the same flow after hitting the control, rather than completing it on the first attempt;
support tickets cluster around one security step, especially where the request is about access rather than a product defect;
users move from supported paths to informal workarounds, such as alternate channels or shared accounts;
risk owners lower standards informally because the control blocks routine work too often.

The strongest reading comes from combining behaviour with context. A sharp increase in failed logins may be a sign of bot activity, password spraying, or simple user confusion, depending on where it occurs and what else changes at the same time. That is why friction analysis must include baselines, segmentation, and a look at adjacent controls, not just one headline metric. Where identity or access controls are involved, an increase in reauthentication, step-up challenges, or enrollment drop-off can reveal that the control is protecting the environment but degrading the user journey more than the business can absorb. This is especially important when the control sits on a high-frequency path, because small annoyances compound quickly across the workforce or customer base. The guidance breaks down when the organisation has no stable baseline, because then it cannot separate normal control resistance from genuine user friction.

Where the edge cases are, and why “secure” can still be the wrong answer

Tighter controls often increase assurance but also increase effort, so organisations have to balance the reduction in misuse against the cost of interruption. That tradeoff is not always consensus-driven. For low-frequency, high-value actions, more friction may be acceptable. For everyday access, even a well-designed control can become harmful if it forces repeated exceptions, adds unnecessary steps, or slows people down enough that they seek a bypass.

One common edge case is deliberate friction that is only visible during specific risk conditions. A step-up prompt that appears rarely can be an effective control, while the same prompt on every session can become a usability problem. Another is environment mismatch: a control that works well for employees may be too heavy for customers, contractors, or mobile users. A third is shadow adaptation, where the control looks acceptable in logs but people quietly route around it through messaging apps, delegated access, or unapproved tools.

Practitioners should also be careful not to treat all extra effort as bad. Some friction is evidence that a control is doing its job, especially when it interrupts suspicious behaviour or protects sensitive actions. The real test is whether the control is proportionate to the task and whether the organisation can prove that the extra cost is buying measurable risk reduction. When that proof is missing, the control may be creating inconvenience without improving security.

Standards & Framework Alignment

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

NIST CSF 2.0 and CIS Controls v8 set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
NIST CSF 2.0	PR.AA — Identity Management, Authentication, and Access Control	User friction often appears in authentication and access workflows.
	DE.CM — Security Continuous Monitoring	Behavioural shifts help distinguish friction from malicious activity.
	GV.RM — Risk Management Strategy	Friction should be judged against business risk and control value.
Recommendation — Measure completion and exception rates to tune access controls that block legitimate users. Monitor baseline drift to separate user friction from suspicious access patterns. Weigh user abandonment against the risk reduction the control actually delivers.
CIS Controls v8	5 — Account Management	Over-friction often shows up in account and login workflows.
Recommendation — Review account workflows for unnecessary steps that drive users toward bypasses.

Practitioner Guidance

What to prioritise: Start with the highest-volume journey that the control affects, not the loudest complaint. If a small control change affects authentication, enrollment, or approval at scale, it can create more operational damage than a visible but rare failure elsewhere.

What to verify: Check whether the same friction pattern appears across user segments, devices, and locations. A problem that is isolated to one cohort may be a configuration issue; a problem that cuts across cohorts usually means the control design itself is too heavy.

Decision rule: If users are abandoning the flow, asking for exceptions, or adopting workarounds more often than they are completing the intended action, treat the control as a business risk, not just a UX issue. If the control is blocking suspicious activity at a comparable rate, keep it and tune the trigger conditions instead of removing it outright.

What practitioners underestimate: The most damaging friction often emerges gradually, because users adapt before managers notice. By the time support volume rises, the organisation may already have normalised a weaker path around the control.

Practitioner takeaway: The best friction test is not whether a control feels strict, but whether it still lets legitimate users complete important work without creating a habit of avoidance.