Security is part of the experience: signing in, recovering an account, granting access and responding when something goes wrong. This section examines the human side of protection and the design decisions that require collaboration with security specialists.
Sources checked 18 October 2026 · 5 resources
Where UX contributes
Authentication and recovery: examine sign-in, lost-device and account-recovery journeys together. Ask which users are excluded and which checks require technical assurance.
Permissions and delegation: make clear what access is being granted, to whom, for how long and how it can be withdrawn—including access granted to an AI agent.
Warnings and decisions: explain the consequence and the available action. Investigate comprehension and repeated interruptions rather than assuming another warning helps.
Mistakes and support: help people report a concern, understand what happened and find a recovery route without blame or misleading reassurance.
Privacy and security: protecting information against unauthorised access does not, by itself, establish that collecting or using it is appropriate. Examine both questions.
These are editorial investigation prompts. A usable prototype is not proof of a secure system.
Research and official guidance
One background empirical paper, two research-discovery resources and two official guidance pages. Their roles and review depth differ.
NIST abstract reviewed; full text not reviewed here
Stanton and colleagues used semi-structured interviews with 40 participants. Fatigue emerged in participants’ accounts even though it was not an explicit focus of the interview protocol.
Limitations: An exploratory qualitative study, not a population estimate or proof that a particular warning design causes unsafe behaviour. The review here is limited to the abstract.
Consider: What security work does your design repeatedly ask people to perform, and can that burden be reduced without removing necessary protections?
Public programme information · research-area page reviewed
A route into research on people’s interactions with cybersecurity systems, products and processes. Use it to locate original studies rather than treating “the user” as a generic source of error.
Limitations: A research directory is not itself evidence for a design decision. Read the individual study, its date and its methods.
Consider: Which people, settings and security tasks were actually studied?
Open USENIX proceedings · collection listing checked
A specialist starting point for usable privacy and security research. Follow individual papers relevant to authentication, privacy decisions and security behaviour.
Limitations: This links to the proceedings collection; individual papers have not been reviewed for this guide. Inspect each paper’s methods, contribution and limitations.
Consider: Does the paper evaluate realistic user behaviour, a prototype, or a proposed method?
Explains cognitive barriers in authentication and mechanisms such as password-manager support and copying and pasting. Consider the complete authentication and recovery journey.
Limitations: This is an informative explanation of a success criterion, not an empirical study. Meeting one criterion does not establish full WCAG conformance or secure implementation.
Consider: Can someone authenticate and recover access without an unnecessary memory, puzzle or transcription burden?
Connects security-product usability with effectiveness, efficiency, satisfaction, inclusion and accessibility. Useful when defining evaluation requirements with security colleagues.
Limitations: Guidance, not a measured effect size or certification of a particular product. Technical security and usability need appropriate assessment.
Consider: What evidence would show that people can use the protective feature correctly in their actual working context?
Editorial learning activity · fictional prototype · no live accounts or credentials required
Map the journey. A museum volunteer loses access to their usual device before a shift. Sketch the ordinary sign-in, the recovery route and escalation to support. Identify assumptions about memory, dexterity, language and device ownership.
Prototype the difficult moments. Include an expired step, an unclear error and a permission request. Explain what happens next and provide a keyboard-accessible route with meaningful labels and status messages.
Evaluate two different questions. Plan how to assess users’ understanding and recovery effort, and separately record the authentication and abuse risks that a security specialist must assess. Obtain required ethics approval before involving participants.
Portfolio output: an annotated journey, accessible prototype, risk-and-responsibility table and evaluation plan. Report what remains untested; do not describe it as a secure implementation.