Build security interfaces that earn user trust through clarity, not intimidation. The goal is to make users feel safe and in control, not punished for security requirements.
Consult the authentication and account recovery reference for sign-in, MFA, session expiry, password UX, and recovery-stack guidance.
Consult the permissions and roles UX reference for role editors, request-access flows, access-denied recovery, and risky permission changes.
Consult the interface honesty reference for assertive UX language, honest progress and consent copy, and trust-preserving product behavior.
Consult the error recovery reference for what happens after security-related failures.
MANDATORY PREPARATION
Users start this workflow with /security-ux. Once this skill is active, load $frontend-design — it contains design principles, anti-patterns, and the Context Gathering Protocol. Follow that protocol before proceeding — if no design context exists yet, you MUST load $setup first. Additionally gather: what threat model the product faces, what security features are already implemented, and where users currently feel confused or anxious about security.
Assess Security UX Needs
Identify where security and user experience intersect:
- Authentication flow: How do users sign in? Is MFA required or optional? How painful is the current flow?
- Password experience: Are requirements reasonable? Is there guidance on creating strong passwords?
- Trust signals: Does the interface communicate security clearly (HTTPS indicators, verified badges, encryption notes)?
- Recovery paths: What happens when users lose access? Is recovery secure but not impossible?
- Breach and anomaly response: How does the product notify users of suspicious activity or data breaches?
- Permission and consent: Are users making informed decisions about what they share?
Security UX Dimensions
Authentication
Sign-in flow:
- Keep the sign-in form minimal: email and password, or social auth options
- Show/hide password toggle so users can verify their input
- Do not clear the email field on failed attempts
- Distinguish "email not found" from "wrong password" only if it does not aid account enumeration attacks
- Rate-limit failed attempts and show a clear cooldown message
Multi-factor authentication (MFA):
- Offer multiple MFA methods (TOTP app, SMS, hardware key, backup codes)
- Default to the most secure method the user has set up
- Provide clear setup instructions with visual guides
- Allow naming devices so users know what they are approving
- Show recovery codes during setup and prompt users to save them
- Do not make MFA feel like a punishment; frame it as protection
Session management:
- Show active sessions in settings with device and location info
- Allow users to revoke individual sessions
- Notify users of new sign-ins from unfamiliar devices or locations
- Use "Remember this device" sparingly and explain what it means
Password UX
Requirements that don't frustrate:
- Minimum length (12+ characters) matters more than complexity rules
- Explain why: "Longer passwords are harder to guess"
- Show a strength meter as the user types, not just on blur
- Allow passphrases ("correct horse battery staple")
- Do not require arbitrary character mixing (one uppercase, one symbol) if length is sufficient
- Never expire passwords arbitrarily; it encourages weak patterns
Password creation guidance:
- Suggest a generated password or passphrase
- Show requirements before the user starts typing, not after they fail
- Use inline validation for length, not a popup on submit
Trust Indicators
Visual signals:
- Show lock icons near sensitive fields (payment, passwords)
- Display security badges or certifications where relevant (PCI DSS, SOC 2)
- Use HTTPS and show the secure connection indicator in the browser
- Explain encryption in plain language ("Your data is encrypted") not jargon
Transparency:
- Explain what data is collected and why before asking for it
- Show privacy policy links near consent checkboxes
- Use plain language for security settings, not enterprise terminology
- Allow users to review and export their data
Account Recovery
Secure but reachable:
- Offer multiple recovery methods (email, phone, backup codes, trusted contacts)
- Verify identity before allowing recovery; do not skip steps for convenience
- Send notifications to existing contact methods when recovery is initiated
- Time-limit recovery links and codes
- Require re-authentication before sensitive actions after recovery
Recovery UX:
- Guide users step-by-step through recovery
- Explain what will happen at each step
- Provide clear alternatives if one recovery method fails
- Do not trap users in loops where recovery requires the very thing they lost
Breach and Anomaly Notifications
Breach notifications:
- Notify users promptly when their account may be compromised
- Be specific about what happened and what data was affected
- Provide clear, immediate actions: change password, review sessions, enable MFA
- Do not bury breach notices in marketing emails
Anomaly alerts:
- Notify users of unusual sign-in attempts with device and location
- Allow users to approve or block the attempt directly from the notification
- Provide a "This was me" / "This was not me" choice, not just an informational alert
- Do not cry wolf; too many false positives train users to ignore alerts
Consent and Permissions
Informed consent:
- Explain what the user is agreeing to in plain language, not legal jargon
- Use progressive disclosure: show the summary first, allow expanding for details
- Separate consent for different purposes (marketing vs. functionality)
- Allow users to revoke consent as easily as they gave it
- Do not pre-check consent boxes
Accessibility
- Ensure MFA code inputs are large and easy to type on mobile
- Provide time remaining for TOTP codes visually and for screen readers
- Use
aria-live for security alerts and notifications
- Ensure trust indicators are perceivable without color alone
- Make recovery flows fully keyboard-navigable
Anti-Patterns
- Security theater: Visual lock icons on non-sensitive pages that do not actually protect anything
- Arbitrary password complexity: Requiring symbols and numbers but allowing short passwords
- Blaming users for breaches: "You should have enabled MFA" instead of "We are helping you secure your account"
- Hiding security settings: MFA and recovery options buried in menus users never find
- False urgency: "Your account will be deleted in 24 hours" for routine verification
- No recovery path: Account permanently locked because the user lost their phone
- Jargon-heavy security copy: "Enable 2FA via TOTP" instead of "Add an authenticator app for extra security"
- Silent breaches: Not notifying users when their data is compromised
- Pre-checked consent boxes: Violates trust and often regulations
- Inconsistent security posture: Strong MFA but weak password recovery bypasses it
Verify Security UX Quality
Before shipping:
1---
2name: security-ux
3description: Design security-conscious interfaces that protect users without frustrating them. Use when the user asks about MFA, password UX, breach notifications, trust indicators, secure forms, account recovery, or making security feel safe rather than scary.
4metadata:
5 argument-hint: "[security flow or surface]"
6---
7
8Build security interfaces that earn user trust through clarity, not intimidation. The goal is to make users feel safe and in control, not punished for security requirements.
9
10Consult the [authentication and account recovery](../frontend-design/reference/authentication-and-account-recovery.md) reference for sign-in, MFA, session expiry, password UX, and recovery-stack guidance.
11Consult the [permissions and roles UX](../frontend-design/reference/permissions-and-roles-ux.md) reference for role editors, request-access flows, access-denied recovery, and risky permission changes.
12Consult the [interface honesty](../frontend-design/reference/interface-honesty.md) reference for assertive UX language, honest progress and consent copy, and trust-preserving product behavior.
13Consult the [error recovery](../frontend-design/reference/error-recovery.md) reference for what happens after security-related failures.
14
15## MANDATORY PREPARATION
16
17Users start this workflow with `/security-ux`. Once this skill is active, load $frontend-design — it contains design principles, anti-patterns, and the **Context Gathering Protocol**. Follow that protocol before proceeding — if no design context exists yet, you MUST load $setup first. Additionally gather: what threat model the product faces, what security features are already implemented, and where users currently feel confused or anxious about security.
18
19## Assess Security UX Needs
20
21Identify where security and user experience intersect:
22
231. **Authentication flow**: How do users sign in? Is MFA required or optional? How painful is the current flow?
242. **Password experience**: Are requirements reasonable? Is there guidance on creating strong passwords?
253. **Trust signals**: Does the interface communicate security clearly (HTTPS indicators, verified badges, encryption notes)?
264. **Recovery paths**: What happens when users lose access? Is recovery secure but not impossible?
275. **Breach and anomaly response**: How does the product notify users of suspicious activity or data breaches?
286. **Permission and consent**: Are users making informed decisions about what they share?
29
30## Security UX Dimensions
31
32### Authentication
33
34**Sign-in flow**:
35- Keep the sign-in form minimal: email and password, or social auth options
36- Show/hide password toggle so users can verify their input
37- Do not clear the email field on failed attempts
38- Distinguish "email not found" from "wrong password" only if it does not aid account enumeration attacks
39- Rate-limit failed attempts and show a clear cooldown message
40
41**Multi-factor authentication (MFA)**:
42- Offer multiple MFA methods (TOTP app, SMS, hardware key, backup codes)
43- Default to the most secure method the user has set up
44- Provide clear setup instructions with visual guides
45- Allow naming devices so users know what they are approving
46- Show recovery codes during setup and prompt users to save them
47- Do not make MFA feel like a punishment; frame it as protection
48
49**Session management**:
50- Show active sessions in settings with device and location info
51- Allow users to revoke individual sessions
52- Notify users of new sign-ins from unfamiliar devices or locations
53- Use "Remember this device" sparingly and explain what it means
54
55### Password UX
56
57**Requirements that don't frustrate**:
58- Minimum length (12+ characters) matters more than complexity rules
59- Explain why: "Longer passwords are harder to guess"
60- Show a strength meter as the user types, not just on blur
61- Allow passphrases ("correct horse battery staple")
62- Do not require arbitrary character mixing (one uppercase, one symbol) if length is sufficient
63- Never expire passwords arbitrarily; it encourages weak patterns
64
65**Password creation guidance**:
66- Suggest a generated password or passphrase
67- Show requirements before the user starts typing, not after they fail
68- Use inline validation for length, not a popup on submit
69
70### Trust Indicators
71
72**Visual signals**:
73- Show lock icons near sensitive fields (payment, passwords)
74- Display security badges or certifications where relevant (PCI DSS, SOC 2)
75- Use HTTPS and show the secure connection indicator in the browser
76- Explain encryption in plain language ("Your data is encrypted") not jargon
77
78**Transparency**:
79- Explain what data is collected and why before asking for it
80- Show privacy policy links near consent checkboxes
81- Use plain language for security settings, not enterprise terminology
82- Allow users to review and export their data
83
84### Account Recovery
85
86**Secure but reachable**:
87- Offer multiple recovery methods (email, phone, backup codes, trusted contacts)
88- Verify identity before allowing recovery; do not skip steps for convenience
89- Send notifications to existing contact methods when recovery is initiated
90- Time-limit recovery links and codes
91- Require re-authentication before sensitive actions after recovery
92
93**Recovery UX**:
94- Guide users step-by-step through recovery
95- Explain what will happen at each step
96- Provide clear alternatives if one recovery method fails
97- Do not trap users in loops where recovery requires the very thing they lost
98
99### Breach and Anomaly Notifications
100
101**Breach notifications**:
102- Notify users promptly when their account may be compromised
103- Be specific about what happened and what data was affected
104- Provide clear, immediate actions: change password, review sessions, enable MFA
105- Do not bury breach notices in marketing emails
106
107**Anomaly alerts**:
108- Notify users of unusual sign-in attempts with device and location
109- Allow users to approve or block the attempt directly from the notification
110- Provide a "This was me" / "This was not me" choice, not just an informational alert
111- Do not cry wolf; too many false positives train users to ignore alerts
112
113### Consent and Permissions
114
115**Informed consent**:
116- Explain what the user is agreeing to in plain language, not legal jargon
117- Use progressive disclosure: show the summary first, allow expanding for details
118- Separate consent for different purposes (marketing vs. functionality)
119- Allow users to revoke consent as easily as they gave it
120- Do not pre-check consent boxes
121
122## Accessibility
123
124- Ensure MFA code inputs are large and easy to type on mobile
125- Provide time remaining for TOTP codes visually and for screen readers
126- Use `aria-live` for security alerts and notifications
127- Ensure trust indicators are perceivable without color alone
128- Make recovery flows fully keyboard-navigable
129
130## Anti-Patterns
131
132- **Security theater**: Visual lock icons on non-sensitive pages that do not actually protect anything
133- **Arbitrary password complexity**: Requiring symbols and numbers but allowing short passwords
134- **Blaming users for breaches**: "You should have enabled MFA" instead of "We are helping you secure your account"
135- **Hiding security settings**: MFA and recovery options buried in menus users never find
136- **False urgency**: "Your account will be deleted in 24 hours" for routine verification
137- **No recovery path**: Account permanently locked because the user lost their phone
138- **Jargon-heavy security copy**: "Enable 2FA via TOTP" instead of "Add an authenticator app for extra security"
139- **Silent breaches**: Not notifying users when their data is compromised
140- **Pre-checked consent boxes**: Violates trust and often regulations
141- **Inconsistent security posture**: Strong MFA but weak password recovery bypasses it
142
143## Verify Security UX Quality
144
145Before shipping:
146
147- [ ] Sign-in flow is minimal and forgiving
148- [ ] MFA setup is clear and offers multiple methods
149- [ ] Password requirements prioritize length over arbitrary complexity
150- [ ] Trust indicators are honest and specific
151- [ ] Recovery paths are secure but reachable
152- [ ] Breach and anomaly notifications are prompt and actionable
153- [ ] Consent is informed, granular, and easily revocable
154- [ ] Security copy uses plain language, not jargon
155- [ ] Alerts are specific enough to act on but not so frequent they become noise
156- [ ] The interface makes users feel safe and in control, not punished