O3.18.1Security workaroundsdesignresearch

Security friction pushes users toward workarounds

Aliases: security circumvention · friction backlash · compliance avoidance

What it is

Security friction — memory burden, waiting, extra steps — never disappears; it gets displaced. Users find alternate routes: sticky notes, shared passwords, instant-accepting warnings, deferred updates. These security workarounds are not user failure but the product of friction; organizations that treat them as a user-quality problem re-harden and get bypassed in cycles.

Why it happens

The user's goal is completing the task; security is a constraint on it. Friction raises completion cost, and the workaround is the cheapest path — users do not weigh security consequences because security benefits were never in their objective function. Workaround forms are patterned: repetitive burden (many passwords) produces reuse and writing down; interruptive burden (two-factor waits) produces downgrade and switch-off; ambiguity burden (unreadable warnings) produces accept-always. The critical evidence is that workarounds are not ignorance — security-literate people circumvent too, with better-reasoned justifications. Workarounds are rational adaptation, not incompetence. Friction is therefore part of security design: every unnecessary unit of it gets exchanged, in real use, for a detour — and detours usually end somewhere less secure than the original path.

Studying it

The classic paradigm is field research: interviews plus observation reconstructing real workflows and locating where security requirements collide with task flow; password-reuse studies quantify reuse rates and structure by matching against breach corpora; warning-processing studies use logs and eye tracking to measure the "instant accept" rate. Typical independent variables are friction type (memory/interruption/comprehension) and frequency; dependent variables are workaround incidence and degradation of security state. Methodological caution: self-report questionnaires systematically undercount workarounds — admitting one means admitting a violation — so conclusions must rest on behavioural and trace data.

Where it stops holding

Not all workarounds should be eliminated: in organizations some are legitimate feedback against over-rigid policy and double as an improvement signal. Friction reduction has floors — authentication strength and audit requirements carry compliance minimums, so not all friction is removable. Personal and organizational workarounds differ in form: individuals answer for themselves and exchange workarounds for personal risk; organizational users act in groups, where workarounds are contagious — one sticky note becomes a department's habit.

Applying it

  • Budget friction before designing: list every step of the security flow (recall, entry, waiting, comprehension), ask what breaks if the step is removed, and cut any step whose removal has no concrete harm.
  • Distribute friction by frequency: minimize daily-login friction, concentrate it on rare high-stakes actions (password change, new-device authorization).
  • Treat workaround signals as dashboard readings: reset rates, 2FA opt-out rates, warning click latencies — a rising reading means friction is too high, not that users got worse.
  • Verification: compare security state before and after friction reduction — opt-out rates fall while authentication failure rates hold steady, or the cut damaged the line.

Related

  • Same group: O3.18.2 Usable security · O3.18.3 Risk-proportionate security · O3.18.4 Threat model first
  • Nearby: O3.05 Warning fatigue · O3.09 Usability cost of password policy · O3.10 Usability of multi-factor authentication
  • Search terms: security workarounds · password reuse · security friction

Cards in the same group

Quick Actions

Share

Share this page

ios_share

https://hci.top/en/handbook/O3.18.1