Privacy & Security UX

Security that users route around is not security; consent users don't understand is not consent. Read when designing login, sign-up, consent flows, permissions, or any handling of personal data.

Authentication UX

• Passkeys (WebAuthn/FIDO2) are the 2026 default to offer first. Platform support is effectively universal (iOS 16+, Android 9+, Windows Hello, all major browsers); FIDO Alliance's 2026 figures claim ~5 billion passkeys in use and ~75% of consumers holding at least one — but site adoption lags, so keep a fallback path. Passkeys are phishing-resistant (origin-bound) and kill password resets, the #1 auth support cost.
• Passkey UX rules: offer enrollment at a moment of success (post-login, post-checkout), not as a sign-up roadblock; use the word "passkey" plus a one-line benefit ("sign in with your face — nothing to remember"); design the cross-device (QR/hybrid) and lost-all-devices cases before shipping.
• Never fight password managers. Do not block paste, autocomplete, or autofill; NIST SP 800-63B (Rev 4, finalized 2025) requires verifiers to permit paste and autofill specifically to support password managers, and says allow 64+ characters, all printable ASCII + spaces, no forced composition rules, no scheduled expiry. Use correct autocomplete attributes (username, current-password, new-password, one-time-code) and a single visible username field so managers can save credentials.
• 2FA hierarchy (strongest → weakest): passkeys/hardware keys (phishing-resistant) → app push with number matching → TOTP apps → email codes → SMS. NIST 800-63B classifies SMS/PSTN OTP as restricted: vulnerable to SIM-swapping, SS7 interception, and phishing relay. Still better than nothing — offer SMS as floor, not ceiling, and let users upgrade.
• Magic links (emailed sign-in links): good for low-frequency, low-risk products; bad when email is slow, the user's inbox is on another device, corporate scanners pre-click links, or the account is high-value (inherits full email-account risk). Pair with a same-screen code ("or enter code 481-227") to survive the cross-device case.
• Calibrate re-auth friction to risk (step-up authentication): don't time out a news-reading session; do re-prompt before payout or password/email changes, viewing stored cards, or new-device login. Long-lived sessions + step-up on sensitive actions beats blanket short timeouts, which train rote logins and weaker passwords. Show active sessions with remote sign-out.

Consent UX (cookies & tracking)

• GDPR/ePrivacy baseline as enforced: consent must be freely given, specific, informed, unambiguous — so "Reject all" must be as easy and as prominent as "Accept all" on the first layer. The EDPB Cookie Banner Taskforce report (2023) and EDPB Guidelines 03/2022 on deceptive design patterns condemn: no first-layer reject option, link-vs-button asymmetry, deceptive button colors/contrast, pre-ticked boxes (already illegal per CJEU Planet49, 2019), and making withdrawal harder than granting.
• Enforcement is real and escalating: France's CNIL has issued formal notices specifically over cookie-banner dark patterns and large cookie fines (e.g., Google, SHEIN in 2025); the EU Digital Services Act Art. 25 separately bans manipulative interface design. Confirmshaming and nagging re-prompts after refusal are on regulators' named lists.
• Honest consent design: first layer = plain-language purpose summary + equal Accept/Reject buttons + "Manage options"; remember refusal as long as acceptance; keep "withdraw consent" one click away on every page (persistent icon or footer link); avoid consent-walls — EU "consent or pay" models are under active EDPB scrutiny.
• US landscape (brief): no federal comprehensive law; ~20 states have comprehensive privacy laws in effect as of 2026 (California, Virginia, Colorado, Texas, et al. — IAPP tracker is the live source). Practical UX consequences: honor Global Privacy Control signals where required (California, Colorado), provide "Do Not Sell/Share" links, and note several state laws explicitly ban dark patterns in consent.

Permission requests

• Ask in context, with purpose: request camera access when the user taps "Scan document," never in an onboarding wall. Both iOS and Android reject or penalize apps requesting permissions without evident need.
• Use pre-permission explainer screens ("priming") only when the value isn't self-evident; the OS dialog is a one-shot resource. Always design the denied state: degrade gracefully and show how to re-enable in Settings. Platform specifics: see Mobile App Design.

Data transparency patterns

• Privacy "nutrition labels" are mandatory in both app stores: Apple's App Privacy details (required since December 2020) declare data used to track you, data linked to you, and data not linked to you; Google Play's Data Safety section (required since July 2022) declares collection, sharing, security practices, and deletability. Definitions differ (Google counts data as "collected" when transmitted off-device; Apple requires transmission and retention) — audit against each. Inaccurate labels are an enforcement hook (store removal, FTC deception claims).
• In-product transparency: just-in-time notices at the point of collection beat privacy-policy links; make held data viewable, exportable, and deletable (also a GDPR/CCPA rights requirement).

Security communication

• Breach notices: plain language — what happened, what data, what you did, what the user should do now, one obvious action. Legal deadlines apply (GDPR: 72h to regulator; every US state has a breach statute). Skip the "we take your security seriously" boilerplate — it reads as evasion.
• Phishing-resistant patterns: consistent sender domains; never ask users to click a link to "verify your account" in ways indistinguishable from phishing; in-app message centers as the canonical channel; show last-login info; number matching instead of blind "Approve" push (blind push enables MFA-fatigue attacks — Microsoft added number matching for this reason). Train users by behaving predictably.
• Avoid security theater: password-strength meters that reward P@ssw0rd1, forced 90-day rotation, security images ("SiteKey"-style — shown ineffective in usability studies, e.g., Schechter et al. 2007), and scary interstitials for routine actions all add friction without risk reduction and cause warning fatigue that blunts real warnings.

Privacy by design (defaults)

• Cavoukian's Privacy by Design framework (7 foundational principles, 2009; codified in spirit as GDPR Art. 25 "data protection by design and by default"): proactive not reactive; privacy as the default setting; privacy embedded into design; full functionality; end-to-end security; visibility and transparency; respect for user privacy.
• Data minimization is a UX principle: every field you don't ask for is form friction removed AND breach surface removed. Don't collect birthdate to verify 18+; don't require an account to check out; make the private option the default and the sharing option the choice.

Sources

• FIDO Alliance — passkey adoption reports (fidoalliance.org, 2025–26); W3C WebAuthn spec.
• NIST SP 800-63B (Rev 4, 2025) — Digital Identity Guidelines: password/paste/autofill rules, restricted status of SMS OTP.
• EDPB — Cookie Banner Taskforce report (2023); Guidelines 03/2022 on deceptive design patterns; CNIL cookie guidance and enforcement (cnil.fr); CJEU Planet49 C-673/17 (2019); EU DSA Art. 25 (2022).
• IAPP — US State Privacy Legislation Tracker (iapp.org; ~20 states, 2026).
• Apple — App Privacy Details (developer.apple.com); Google Play — Data safety section requirements.
• Cavoukian, A. (2009). Privacy by Design: The 7 Foundational Principles. IPC Ontario; GDPR Art. 25.
• Schechter, S. et al. (2007). "The Emperor's New Security Indicators." IEEE S&P — security-image ineffectiveness.