figma guide
Designing suspicious login alerts and account recovery UI in Figma: fraud signals, lockouts, and secure reset flows
Design suspicious login alerts and account recovery UI in Figma with fraud banners, step-up verification, lockout screens, and Dev Mode specs for account takeover response flows.
- Published
- Updated
- Jul 09, 2026
- Read time
- 8 min
- Level
- Beginner
Quick answer
Suspicious login alerts and account recovery UI tells users something risky happened—new device sign-in, impossible travel, credential stuffing—and gives a safe path to secure the account before damage spreads. Design email and in-app alerts with device, location, and time; a “This wasn’t me” CTA that revokes sessions and forces password reset; step-up verification (2FA, email OTP, passkey) when risk scores spike; and lockout screens when too many failed attempts occur. This is the response layer—detection events appear in the audit log, live control lives on active sessions, and enrollment happens in security settings. Start from the Figma guides hub.
Who this is for
- Product designers building fraud-aware sign-in, alert emails, and post-breach recovery wizards for SaaS and ecommerce accounts.
- Design system teams separating one-time recovery flows from everyday login and notification inbox patterns.
- Engineers implementing risk scoring, session invalidation, rate limits, and secure reset tokens with short TTL.
Alert surfaces vs recovery flows vs prevention
| Surface | Trigger | User action |
|---|---|---|
| Security alert email | New device / geo anomaly | ”Secure account” deep link |
| In-app banner | Recent suspicious sign-in while logged in | Review activity or dismiss |
| Login challenge | Risk score mid-auth | Complete 2FA or email OTP |
| Account lockout screen | Failed attempts threshold | Wait, reset password, contact support |
| Recovery wizard | User reports compromise | Revoke → reset → re-enroll MFA |
| Audit log row | Event recorded | Read-only; link to recovery |
Verdict: alerts inform; recovery flows remediate. Do not put revoke buttons inside marketing emails without re-auth—deep links should land on a verified step-up screen first.
Suspicious sign-in signal types
| Signal | Example UI copy | Severity |
|---|---|---|
| New device | ”New sign-in on Chrome for Windows” | Warning |
| New location | ”Sign-in from ~ Lagos, NG (first time)“ | Warning |
| Impossible travel | ”Two sign-ins 30 minutes apart in different countries” | Critical |
| Failed attempt burst | ”5 failed sign-in attempts in 10 minutes” | Warning |
| Password spray pattern | ”Multiple accounts targeted from same IP” | Critical (admin) |
| Credential change after anomaly | ”Email changed 2 minutes after new sign-in” | Critical |
Pair impossible-travel alerts with session timeout docs—users confuse idle expiry with fraud lockout.
Email alert anatomy
| Part | Spec | Notes |
|---|---|---|
| Subject | Specific, not scary-generic | ”New sign-in to your account” |
| Was this you? | Binary framing | ”Yes, it was me” vs “No, secure my account” |
| Event summary | Device · browser · approx location · time | Match audit log row format |
| Secure CTA | Primary button | Links to authenticated recovery entry |
| Ignore link | Secondary | ”I recognize this device” (optional feedback to risk engine) |
| Support footer | Static | No reply-to for security; link help center |
| No secrets | Never include passwords or full OTP | Phishing template risk |
Copy example: “Someone signed in to Acme with your email on Jul 9 at 3:14 AM from Chrome on Windows near Toronto, CA. If this wasn’t you, secure your account now.”
Cross-link notification preferences so users can tune alert frequency without disabling critical security emails entirely.
In-app banner and modal patterns
| Pattern | When | Dismissible? |
|---|---|---|
| Top banner | User already signed in; event within 24h | Yes, after acknowledge |
| Blocking modal | Critical: email changed + new geo | No until action |
| Account health card | Dashboard widget summarizing risk | N/A |
| Push notification | Mobile companion | Opens recovery deep link |
SuspiciousSignInBanner
├── Variant: severity=warning | critical
├── Variant: dismissed=true | false
└── Layers:
├── Icon (shield-warning)
├── Headline
├── EventSummary
├── PrimaryCTA ("Review activity")
├── SecondaryCTA ("This was me")
└── DismissButton (warning only)“This was me” should log user confirmation and reduce false-positive alerts—not skip security for future events from that device. Optionally offer Trust this device per active sessions specs.
”This wasn’t me” recovery wizard
Design a linear wizard with progress and irreversible steps called out.
| Step | Screen | Actions |
|---|---|---|
| 1. Verify identity | Re-auth: password + 2FA or email OTP | Gate before revoke |
| 2. Revoke sessions | List all active sessions pre-checked | ”Sign out everywhere” default on |
| 3. Reset password | New password + strength meter | Invalidate reset links on complete |
| 4. Review account | Email, phone, OAuth, payment methods | Flag changes in last 48h |
| 5. Re-enroll MFA | Force 2FA or passkey if previously off | Link security settings |
| 6. Confirmation | Summary + link to activity log | ”Your account is secured” |
Do not ask users to forward suspicious emails to support as step 1—that trains phishing behavior.
Step-up verification at login
When risk engine challenges mid-login (before session minted):
| Challenge type | UI | Fallback |
|---|---|---|
| Email OTP | 6-digit code entry | Resend with cooldown |
| Authenticator TOTP | Same as 2FA login | Backup codes |
| Passkey | Platform prompt | Password + OTP if passkey unavailable |
| CAPTCHA | Bot signal only | Not a substitute for MFA |
Reuse email verification / OTP components—annotate context=step_up_login in Dev Mode so copy differs from signup verify (“Confirm it’s you signing in”).
Account lockout screen
| Element | Spec |
|---|---|
| Headline | ”Too many sign-in attempts” |
| Explanation | Temporary lock; not necessarily compromise |
| Countdown | ”Try again in 14:32” or static “15 minutes” |
| Reset password CTA | Always visible |
| Support link | Last resort |
| No email enumeration | Same copy for unknown vs known account on public lockout |
Differentiate user lockout (their account) from IP rate limit (shared network)—copy should not imply the user’s password was wrong when the café Wi‑Fi triggered IP throttling.
Post-recovery account review checklist
Surface changes attackers commonly make:
| Item | UI treatment |
|---|---|
| Email address | Highlight if changed in last 48h; revert flow |
| Phone number | Same |
| Connected OAuth apps | Link connected accounts |
| API keys | Link API keys with “Review keys” |
| Payment methods | Link payment methods |
| Saved addresses | Link address book |
| Notification prefs | Attacker may disable alerts |
Use warning chips on rows modified recently; do not auto-revert without user confirmation (support may need audit trail).
Enterprise and SSO considerations
| Scenario | UX note |
|---|---|
| SSO-only tenant | Recovery may redirect to IdP admin; no local password reset |
| Forced SSO after incident | Admin banner + member email |
| Shared kiosk | Suppress “trust device” on shared hardware |
| Break-glass admin | Separate flow—not consumer wizard |
Cross-link SSO login when local recovery CTAs do not apply.
Mobile and responsive layout
| Breakpoint | Pattern |
|---|---|
| Mobile email | Single column; 44px min touch targets on CTAs |
| Mobile wizard | Full-screen steps; sticky primary action |
| Desktop | Two-column review step: timeline left, actions right |
| Deep links | Universal links open app to recovery step with token |
Banners on mobile should not cover sticky checkout or cart CTAs on ecommerce—use dedicated account area only.
Handoff checklist
| Item | Dev Mode annotation |
|---|---|
riskEventId | Correlates email, banner, audit row |
| Token TTL | Recovery deep links expire in 15–60 min |
| Single-use tokens | Invalidate after password reset |
| Session revoke scope | All refresh tokens vs current only |
| Rate limit headers | Optional for API clients |
| Email template variants | warning vs critical |
| a11y | Banner role=alert; wizard steps as ordered list |
| Localization | Location strings approximate; avoid false precision |
Document support escalation: when automated recovery fails, show ticket form with pre-filled riskEventId.
Common mistakes
| Mistake | Why it hurts | Fix |
|---|---|---|
| Revoke via unauthenticated email link | Account takeover completes | Step-up before revoke |
| Generic “unusual activity” copy | Users ignore alerts | Specific device + time |
| Same UI for lockout and fraud | Unnecessary panic | Separate copy and severity |
| Permanent dismiss on critical modal | Missed takeover | Re-show until resolved |
| Recovery wizard with 12 steps | Abandonment | Max 5–6 steps |
| No post-recovery review | Attacker changes persist | Checklist screen |
| Marketing email styling on security alerts | Phishing training failure | Distinct security template |
| Showing full IP addresses | Privacy + support noise | City-level approximation |
Recommended workflow
- Map risk events with engineering—align with audit log event types.
- Design email template with was-this-you framing and secure deep link.
- Build in-app banner with warning vs critical variants.
- Prototype recovery wizard from step-up through confirmation.
- Add lockout screen with reset-password escape hatch.
- Wire post-recovery review linking OAuth, keys, and payment surfaces.
- Test deep links on mobile and expired-token error state.
- Align copy with login and 2FA components.
FAQ
Should every new device trigger an email?
Not always. Tune by risk score—trusted device cookie, passkey, or recent same-geo sign-in can suppress alerts. Always log to audit feed.
Show alerts for failed login attempts to the account owner?
Yes, after a threshold (e.g. 5 in 15 minutes)—helps detect credential stuffing without alerting on every typo.
Can users disable suspicious login emails?
Partially. Allow reducing non-critical alerts; keep critical (email changed, 2FA removed) mandatory on regulated products.
Same flow for ecommerce vs B2B SaaS?
Core wizard is shared; B2B adds org admin notification and SSO-specific branches per SSO specs.
How does this relate to password recovery?
Password reset is one step inside recovery; login recovery covers forgot-password entry points—link between them when lockout offers reset.
Next steps
- Design audit log and security activity UI in Figma — event history behind alerts
- Design active sessions and device management UI in Figma — revoke after “wasn’t me”
- Design two-factor authentication and security settings UI in Figma — re-enroll after recovery
- Design email verification and OTP UI in Figma — step-up code entry
- Design API keys and personal access tokens UI in Figma — review keys post-recovery
§ Keep reading