Usable Security and Human Factors Guide: Designing Controls People Can Actually Follow

Security controls that people cannot use, or that cost too much effort against their real work, get bypassed, and the bypass is usually invisible to the security team. Usable security is the discipline of designing controls, policies, warnings and tools around human tasks, capabilities and workloads, so that the secure path is the one people take by default. It is an established field: the CyBOK Human Factors Knowledge Area, NIST's security fatigue research and the NCSC's password and phishing guidance all reach the same conclusion that blaming users does not work and redesign does. This guide turns that research into practice: how to measure the burden of a control, design warnings that are heeded, write policies people can follow, and spot shadow security before it becomes an incident. It is for security architects, policy owners, IAM and product teams, and awareness leads who want to go beyond the Security Awareness and Human Risk Management Guide.

Key takeaways

• People have a compliance budget: security is an enabling task competing with the work people are paid to do, and each extra demand spends a limited budget of effort that, once exhausted, leads to workarounds.
• Fatigue is a design failure, not a character flaw: NIST found that users overloaded with security decisions avoid them, pick the easiest option or act impulsively; the fix is fewer, simpler, consistent decisions.
• Warnings must be rare and right: CyBOK's NEAT test (Necessary, Explained, Actionable, Tested) and a false alarm rate of about 10% or less stop people learning to click through.
• Never issue a policy that cannot be followed: unfollowable rules erode trust in every other rule and push people into shadow security.
• Remove decisions with technology: passkeys, password managers, phishing-resistant MFA, safe defaults and automatic updates remove whole classes of human error rather than training around them.

Why controls fail people

The principle is old. Kerckhoffs listed ease of use among his requirements for a cipher system, and Saltzer and Schroeder named psychological acceptability as a design principle. The CyBOK Human Factors Knowledge Area (version 1.0.1, author M. Angela Sasse) builds on that with a simple model: people have production tasks, the work they are paid for, and enabling tasks such as security and compliance. When an enabling task gets in the way of the production task, the production task wins.

NIST's study by Stanton, Theofanos, Prettyman and Furman, published in IEEE IT Professional in 2016, described security fatigue: users felt resigned and lost control, and many believed they were not valuable enough to be targeted. NIST's three recommendations remain the best short brief for any control owner: limit the decisions users must make, make the secure choice the easiest one, and design for consistent decisions.

Measuring the cost of a control

Most organisations measure whether a control exists, not what it costs the people who use it. CyBOK describes a workload audit: comparing the effort of a security task with the primary task it interrupts. A practical version:

1. Pick a control and a population: for example MFA prompts for finance staff, or the data classification step in the document workflow.
2. Measure frequency and time: how many times per day the control appears and how long it takes, from logs where possible (authentication events, DLP prompts, ticket volumes).
3. Measure failure and friction: lockouts, help desk tickets, abandoned tasks, overrides and exception requests.
4. Ask the users: short interviews or diary studies reveal workarounds that logs miss. Use the non-confrontational approach CyBOK calls security hygiene: the aim is to find out why, not who.
5. Redesign and re-measure: change one variable (remember device for 12 hours, auto-classify by location, remove a prompt) and compare.

Usability itself has a standard definition: ISO 9241-11 assesses it through effectiveness, efficiency and satisfaction. Those three are a reasonable frame for security reviews.

Designing security warnings

CyBOK describes alarm fatigue: when people learn that warnings are usually false, they stop reading them. Every unnecessary warning trains users to ignore the necessary ones. CyBOK's NEAT checklist (from Reeder) is a good gate for any new warning:

• Necessary: can the system make the decision itself? If the answer is always "block" or always "allow", do not ask.
• Explained: say what the risk is, in the user's terms, and what will happen next.
• Actionable: give a clear safe option, and make it the default and the most prominent button.
• Tested: test with real users before release and measure behaviour afterwards.

Practical rules that follow from it: keep warnings rare enough that they are noticed; make high-risk warnings visually distinct from routine ones; avoid "OK or Cancel" choices where neither label says what happens; do not let a warning be dismissed by the same keystroke that dismisses routine dialogs; and record overrides so you can see which warnings are ignored. External email banners are a common example: if every message carries one, nobody reads it, while a banner only on first-time senders or lookalike domains still carries meaning.

Policies people can follow

CyBOK names the MacArthur principle: never issue a security policy that cannot be followed. When a rule conflicts with getting work done, people develop shadow security (Kirlappos and colleagues), their own workable practices outside policy, such as sharing files through personal cloud accounts when the approved route is too slow. Shadow security is a signal, not just a violation: it shows where official controls do not fit.

• Write rules against real tasks: test each policy statement with the people who must follow it, and remove rules nobody can comply with.
• Provide the secure tool first: do not ban personal file sharing before approved sharing works as well. The same applies to AI tools.
• Retire counterproductive rules: the NCSC advises against forced regular password expiry and complexity requirements, and NIST SP 800-63B-4 says verifiers shall not impose composition rules or periodic changes, shall allow password managers and should allow paste.
• Use delegation, not sharing: the NCSC recommends delegation features instead of shared accounts; where sharing is unavoidable, keep the group small and change the password when someone leaves.
• Prefer throttling to lockout: lockout punishes legitimate users and enables denial of service; if you use it, the NCSC suggests allowing 5 to 10 failed attempts.

See the Password Policy Guide (NIST-aligned) for the technical side.

Authentication: where usability and security converge

Authentication is the clearest case where better usability is also better security. Passwords demand memory, and one-time codes can be phished; passkeys bound to the origin cannot be phished and need no transcription.

The Uber breach in 2022 shows the push failure mode: an attacker with a contractor's purchased password repeatedly triggered approval requests until one was accepted. See the Uber breach, the MFA Fatigue and Bypass Guide and the Passwordless and Passkeys Guide.

Account recovery and the help desk

Recovery is where usable and secure design most often collide. If self-service recovery is hard, users call the help desk, and a help desk measured on speed will accept weak verification. Design recovery as a first-class flow: let users register more than one passkey or security key, offer recovery codes with clear storage advice, and give help desk staff a verification process that is quick for genuine callers and does not rely on facts an attacker can find, such as date of birth or employee number. Measure recovery volumes and the share handled without a human; a rising share of manual resets is an early sign that the primary method is failing people. See the Secure Password Reset Flow Guide.

Awareness, training and behaviour change

CyBOK separates awareness (knowing a risk exists), education (understanding it) and training (practising a response). Behaviour change needs all three, and the Fogg Behaviour Model adds that motivation, ability and a trigger must all be present at the same moment. Annual compliance modules provide none of these at the moment of decision.

• Measure reporting, not just clicking: the NCSC recommends tracking how many people reported a phish as well as how many clicked, and warns that punishing staff for simulated phish can resemble entrapment and erode trust.
• Design for the miss: the NCSC's position is that some phishing will always get through, so layered technical controls must limit the damage. Its case study describes 1,800 malicious emails, of which filtering stopped 1,750 and user reports and patched devices stopped most of the rest.
• Use positive framing: CyBOK argues for dropping "weakest link" language and fear-based messaging, which create resignation, in favour of framing security as enabling work.
• Engage people as designers: creative engagement and staff-written phishing exercises surface real problems faster than top-down campaigns.

See the Phishing Simulation Programme Guide and the Security Culture Measurement Guide.

Developers, administrators and non-human identities

Usable security applies to technical staff too. CyBOK cites research showing developers often treat security as secondary, and that developers given official documentation wrote more secure code than those using Stack Overflow. For engineering teams that means secure defaults in frameworks, clear official examples and APIs that are hard to misuse.

• Secrets handling: if getting a secret from the vault takes ten minutes and pasting it into code takes ten seconds, secrets end up in code. Make the vault path faster: CLI tools, IDE plugins, workload identity that removes the secret entirely. See the Secrets Management Guide.
• Privileged access: just-in-time elevation that takes minutes is used; one that takes a day of approvals is bypassed with standing admin rights.
• Alert design for SOC analysts: alarm fatigue applies to analysts as much as to end users; noisy detections get muted.

Decision guidance by organisation size

• Small organisations: remove decisions first: password manager for everyone, passkeys or phishing-resistant MFA, automatic updates, managed browsers. Skip elaborate simulation programmes until reporting is easy.
• Mid-sized organisations: run a workload audit on the three most complained-about controls each year, and publish what changed.
• Large organisations: include usability acceptance criteria in security architecture reviews, give product and IAM teams a user research budget, and treat exception and override data as a standing input to control design.

Common failure patterns

• Training as the primary control: asking people to spot every phish or check every link instead of deploying phishing-resistant authentication and filtering.
• Warning inflation: banners and prompts on everything, so the important one is ignored.
• Approve-only MFA prompts: push approval without a typed code or rate limits, as the Uber breach showed.
• Policies written for auditors, not users: rules that cannot be followed create shadow security and undermine trust in all policy.
• Punitive simulations: naming or disciplining people who click reduces reporting, the behaviour that matters most.
• Help desk processes that reward pressure: social engineers succeed where the verification process is slower than the caller's patience; see the Help Desk Social Engineering Incident Playbook.

Framework mapping

Practitioner checklist

• Run a workload audit on your most-used controls: frequency, time, failures and workarounds.
• Apply the NEAT test to every user-facing warning and retire warnings that fail it.
• Track warning false positive rates and keep them at about 10% or less.
• Remove password expiry and composition rules; deploy password managers and blocklists.
• Replace approve-only push MFA with code entry or passkeys, and rate-limit prompts.
• Review policies with the people who must follow them and remove unfollowable rules.
• Measure phishing reports and time to report, not only click rates.
• Treat exceptions, overrides and shadow IT as design input, investigated without blame.
• Give developers secure defaults and official examples that are faster than the insecure path.

Standards and references

• CyBOK: Human Factors Knowledge Area
• NIST: Security Fatigue Can Cause Computer Users to Feel Hopeless and Act Recklessly
• NIST: SP 800-63B-4 Authentication and Authenticator Management
• NCSC: Password Administration for System Owners
• NCSC: Phishing Attacks, Defending Your Organisation
• NIST: Cybersecurity Framework 2.0

Related NHI Mgmt Group resources: Security Awareness and Human Risk Management Guide · MFA Fatigue and Bypass Guide · Phishing Simulation Programme Guide · Security Culture Measurement Guide