SaaS Two-Factor Authentication & Account Security UX Patterns: Real Screenshots (2026)
Security is the one part of a SaaS product where good UX and good protection have to be the same thing — a two-factor setup nobody finishes protects nobody, and a scary security screen just gets abandoned. This guide covers the decisions that make account security feel trustworthy instead of intimidating: putting security controls where users expect them, walking people through two-factor enrollment without dead ends, always issuing and explaining recovery/backup codes, showing an honest sessions-and-devices list people can actually act on, warning about consequential changes without crying wolf, and confirming every security event so users know their account is being watched over — each shown with real SaaS screenshots from shipped products instead of mockups.
Account security is the one area of a SaaS product where the design and the protection are inseparable. A two-factor prompt that is confusing enough to get skipped protects nobody; a recovery flow nobody can find locks real customers out of their own data; a security settings page so intimidating that people bounce leaves every account weaker than it should be. The security screens — where a user turns on two-factor authentication, sees which devices are signed in, changes a password, or ends a suspicious session — are simultaneously the highest-stakes surface in the product (this is where account takeover is prevented or enabled) and one of the easiest to design badly, because the instinct is to treat security as a compliance checkbox rather than a flow a nervous human has to complete. GitHub, Stripe, Google, Notion, Linear, Vercel, and every serious B2B product invest heavily here, because the security experience is where trust is either earned or quietly lost: a user who can confidently lock down their account believes the product can be trusted with sensitive work, and a user who gives up halfway through 2FA setup — or worse, locks themselves out — remembers the product as the thing that made security feel dangerous. Good security UX is not about adding friction; it is about making the safe path the easy one.
The job of a security surface is to let a user strengthen and manage the protection on their account — add a second factor, review who is signed in, rotate a password, recover access — with enough clarity that they actually finish, and enough honesty that they trust what they are seeing. It is worth scoping precisely: this is not login itself (the sign-in screen a returning user hits), and it is not the permissions-and-roles administration where an admin sets what teammates can do. This is the account-owner's own security control panel — the two-factor enrollment flow, the recovery codes, the active-sessions list, the password change, and the alerts that fire when something security-relevant happens. The decisions below are what separate a security experience that people complete and trust from one they abandon or fear, each shown with real SaaS screenshots so you can see how mature products make protection feel approachable.
Put security controls where users already look for them
People reach for account security in a moment of intent — they just read about a breach, they are setting up a new company account, or a prompt nudged them — and they look in the obvious place: an account or settings menu with a clearly labelled "Security" (or "Password & Security", "Login & Security") section. The strong pattern gives security its own dedicated home rather than scattering a password field on one page, two-factor on another, and sessions somewhere in an admin console; when a user decides to harden their account, everything that does so should be reachable in one place. That section should open by showing the account's current security posture at a glance — is two-factor on or off, when was the password last changed, how many devices are signed in — so the user immediately understands where they stand before touching anything. The mature version also surfaces security proactively at the right moments (a gentle "Protect your account — turn on two-factor" banner for a high-value account that has none), without nagging on every visit. The anti-pattern is security buried three levels deep or split across unrelated screens, so the motivated user who wants to do the right thing cannot find how, and the security posture is invisible until something goes wrong. Make security a real, findable place with an honest at-a-glance status, and more users will actually secure their accounts.
Design a two-factor enrollment flow people actually finish
Two-factor authentication only protects anyone if users complete the setup, and enrollment is exactly where good intentions die — so the flow has to carry a slightly anxious person from "I should turn this on" to "it works" without a single dead end. The pattern that works is an explicit, staged flow: choose a method (authenticator app, passkey, security key, or SMS as a fallback), then a clear step to connect it — a scannable QR code with a manual setup key underneath for people whose scanner fails, or the native passkey/security-key prompt — then a mandatory verification step where the user enters a current code to prove the second factor actually works before it is switched on. That final verify step is the one most often skipped in weak designs, and it is the most important: enabling 2FA without confirming the user can produce a valid code is how you lock people out the moment they sign out. Method choice should guide people toward the strongest option they can use (passkeys and authenticator apps over SMS) while making the trade-offs legible rather than preachy. Progress should be visible so the user knows how many steps remain, and every failure state — wrong code, expired code, mistyped setup — should recover in place with a plain explanation rather than dumping them back to the start. The anti-patterns are turning 2FA on the instant a QR is shown (no verification, guaranteed future lockouts), a single wall of instructions with no staging, and error states that reset the whole flow. Stage it, verify it before enabling, and make every stumble recoverable, and people will actually get through it.
Always issue recovery codes — and make sure people keep them
The predictable disaster of two-factor authentication is the lost phone: the authenticator app is gone, the second factor is unreachable, and without a backdoor the user is permanently locked out of their own account and data. Recovery (backup) codes are that backdoor, and the single most important security-UX decision after enabling 2FA is to generate them automatically and force the user to acknowledge and save them as part of setup — not bury them behind an optional link most people never click. The strong pattern presents a set of one-time recovery codes immediately when 2FA is enabled, explains in one plain sentence what they are for ("If you lose access to your authenticator, use one of these codes to sign in"), offers copy/download/print, and requires an explicit "I've saved these" confirmation before finishing — treating the codes as a mandatory step, not an afterthought. Just as important is legibility afterward: the security page should show how many codes remain unused and offer a clear "regenerate codes" action (which invalidates the old set), so a user who has burned through theirs or suspects they leaked can safely reset. Alternative recovery paths — a backup phone, a second passkey, admin-assisted recovery for team accounts — should be offered where they fit, because a single point of recovery failure is its own risk. The anti-patterns are enabling 2FA with no recovery codes at all, hiding them behind a link users skip, or showing them once with no later way to see how many are left or regenerate. Force the save, explain the purpose, and keep recovery visible — it is the difference between a locked account and a two-second recovery.
Zoho WorkDrive — a real profile screen from the SaaSUI library.
Show an honest active-sessions and devices list users can act on
Once an account matters, the user needs to answer a simple, high-anxiety question — "who is signed into my account right now?" — and the sessions-and-devices list is where a well-designed product answers it truthfully and gives them the power to act. The strong pattern is a clear list of active sessions showing, for each, enough to recognise it: device and browser, approximate location, last-active time, and an unmistakable marker for "this is your current session" so the user does not accidentally kill the one they are using. Every other session should have an obvious individual "sign out" (revoke) control, plus a prominent "sign out of all other sessions" for the moment a user is genuinely worried. The point is agency: a user who suspects something wrong should be able to eject every other device in one deliberate action and then change their password, all from the same place. Honesty matters as much as controls — the list has to reflect reality (stale or phantom sessions that never expire make the whole feature untrustworthy), and location/device data should be presented as approximate rather than falsely precise. The anti-patterns are no visibility into active sessions at all (the user simply cannot tell if they are compromised), a list with no way to revoke individual sessions, and a "log out everywhere" that is hidden or that silently signs the user out of their current session with no warning. Show the truth about who is signed in, mark the current session clearly, and make revoking any or all of them a single confident click.
baremetrics — a real profile screen from the SaaSUI library.
Warn about consequential changes — proportionately, not constantly
Some security actions are genuinely dangerous — disabling two-factor, changing the account email, removing the last recovery method, deleting the account — and the flow has to make the weight of those actions felt without burying every trivial toggle under a confirmation dialog. The pattern that works is proportionate friction: the truly consequential, hard-to-reverse actions get a real speed bump (a confirmation that states the specific consequence in plain language — "Turning off two-factor makes your account easier to compromise" — often paired with re-authentication or a typed confirmation for the most destructive ones), while routine, safe adjustments stay frictionless. Re-authentication is a particularly important tool here: asking the user to re-enter their password or second factor before a sensitive change (email change, 2FA disable, viewing recovery codes) is what stops someone who walked up to an unlocked laptop from quietly taking over the account, and it should be scoped to genuinely sensitive actions so it feels protective rather than obstructive. The legibility principle is that the user should always understand what a security change actually does before committing — what protection they are removing, what becomes possible, whether it can be undone. The anti-patterns are silent security downgrades (2FA turned off with a single unremarkable toggle and no warning), confirmation dialogs on every harmless setting until users click through everything reflexively, and destructive actions with no re-authentication so a momentarily unlocked session is a full compromise. Match the friction to the blast radius: heavy where it protects, invisible where it does not.
Confirm every security event — so users know the account is watched over
Trust in a security surface comes not just from the controls but from the feedback: a user needs to know, reliably, that important things happened to their account — and to be alerted fast when something happened that they did not do. The strong pattern confirms every security-relevant event both in-product and out of band: a clear success state after enabling 2FA or changing a password, and — crucially — an email (or push) notification to the account owner for events like a new-device sign-in, a password change, a 2FA method being removed, or a new email being added. That out-of-band alert is the safety net for account takeover: even if an attacker changes settings, the real owner gets a "your password was just changed — if this wasn't you, secure your account" message with a direct action link, turning a silent compromise into a catchable one. Inside the product, a lightweight security activity log (recent sign-ins, changes, and from where) lets a cautious user audit their own history and spot anything unfamiliar. The tone of these confirmations should be reassuring and specific, not alarmist — they exist to make the user feel watched over, not panicked. The anti-patterns are security changes that happen silently with no confirmation and no notification (the owner has no way to notice a takeover), alerts so noisy or generic that people tune them out, and a notice with no action path so a worried user who reads "new sign-in from an unknown device" has no obvious next step. Confirm it, notify out of band, and always give a route to act — that loop is what makes the whole account feel protected.
The details that separate a trusted security flow from a locked-out user
Each decision above is modest on its own; an account-security experience feels genuinely designed — protecting users instead of intimidating or locking them out — when they are handled together. These are the behaviours mature SaaS products share across their security settings, 2FA enrollment, sessions lists, and alerts.
- Security has one findable home (an account "Security" section) that opens with an at-a-glance posture — 2FA on/off, last password change, devices signed in — not scattered fields across unrelated pages.
- Two-factor enrollment is a staged flow — choose method, connect it (QR with a manual key fallback, or native passkey/security-key prompt), then a mandatory verify-a-code step before it is switched on — with visible progress and in-place recovery from every error.
- Recovery/backup codes are generated automatically on enabling 2FA, explained in a plain sentence, offered as copy/download/print, and gated behind an explicit "I've saved these" — with a later view of how many remain and a regenerate action.
- An honest active-sessions list shows device, approximate location, and last-active for each session, clearly marks the current one, and offers per-session revoke plus a prominent "sign out of all other sessions."
- Consequential changes (disable 2FA, change email, remove last recovery method, delete account) carry proportionate friction — a plain-language consequence and re-authentication — while routine safe settings stay frictionless.
- Every security event is confirmed in-product and notified out of band (email/push for new-device sign-in, password change, 2FA removal), each alert stating what happened and giving a direct action to secure the account.
- The surface stays distinct from login itself and from roles-and-permissions administration — it is the account owner's own control panel for protecting and recovering their access.
Common SaaS account-security mistakes
- Burying security controls three levels deep or splitting password, 2FA, and sessions across unrelated screens, so the motivated user who wants to harden their account cannot find how.
- Enabling two-factor the instant a QR code is shown, with no verify-a-code step — guaranteeing lockouts the moment the user next signs out.
- Turning on 2FA with no recovery codes, or hiding them behind an optional link users skip, so a lost phone becomes a permanent lockout with no backdoor.
- No visibility into active sessions at all, or a sessions list with no way to revoke individual devices — the user cannot tell whether they are compromised or do anything about it.
- Silent security downgrades: two-factor turned off (or an email changed) via a single unremarkable toggle, with no warning, no re-authentication, and no notification to the owner.
- Confirmation dialogs on every harmless security setting until users click through reflexively — training them to ignore the warnings that actually matter.
- A "log out everywhere" that is hidden, or that silently signs the user out of their current session with no warning about which sessions it affects.
- Security changes that happen with no confirmation and no out-of-band alert, so an account takeover leaves the real owner with no way to notice or respond.
Frequently asked questions
Where should account security settings live in a SaaS product?
In a dedicated, clearly labelled "Security" (or "Password & Security" / "Login & Security") section inside the account or settings area, with everything that hardens the account — password change, two-factor setup, recovery codes, and active sessions — reachable from that one place. That home should open by showing the account's current posture at a glance: whether two-factor is on, when the password was last changed, and how many devices are signed in, so the user understands where they stand before changing anything. Scattering a password field on one page, two-factor on another, and sessions in an admin console is the common failure — the user who is motivated to secure their account in a moment of concern cannot find how, and the security posture stays invisible until something goes wrong. Surfacing security proactively at the right moment (a gentle prompt to enable 2FA on a valuable account that has none, without nagging every visit) is what turns intent into actual protection.
How do you design a two-factor setup people actually complete?
Stage it and verify before enabling. A flow people finish walks through choosing a method (authenticator app or passkey preferred, SMS as a fallback), connecting it (a scannable QR code with a manual setup key underneath for when scanning fails, or the native passkey/security-key prompt), and — the step weak designs skip — a mandatory verification where the user enters a current code to prove the second factor works before it is switched on. Verifying first is what prevents lockouts: enabling 2FA without confirming the user can produce a valid code is how people get locked out the moment they sign out. Keep progress visible so they know how many steps remain, guide method choice toward the strongest option without lecturing, and make every failure — wrong or expired code, mistyped key — recover in place with a plain explanation rather than resetting the whole flow. And always pair enrollment with recovery codes the user is forced to save, so a lost device is a two-second recovery rather than a permanent lockout.
What is the difference between account security and roles & permissions?
They protect different things and belong on different surfaces. Account security is the individual owner's control panel for their own access — two-factor enrollment, recovery codes, password changes, and the list of devices and sessions signed into their account — and its job is to prevent and recover from account takeover. Roles & permissions administration is the team-level surface where an admin decides what other members are allowed to do inside the account — assigning roles, configuring granular capabilities, and managing who can access what. The practical rule is that security answers "is my account protected and who is signed into it," while permissions answers "what can each teammate do here." Blurring them produces either a security page cluttered with team-management controls the individual user does not need, or a permissions screen that hides the personal security actions (2FA, sessions, recovery) a user urgently wants when they are worried about their own account. Keep the owner's security controls together and distinct from the admin's permissions matrix.
Study real SaaS account-security and 2FA flows in the SaaSUI library
Every decision above is easier to apply when you can see how real products solved it. Browse real security settings pages, two-factor enrollment flows, recovery-code screens, active-sessions and devices lists, re-authentication prompts, and security alerts from shipped SaaS applications like GitHub, Stripe, Google, Notion, Linear, Vercel and other polished products in the SaaSUI.Design library, with real screenshots instead of mockups, to study how mature products give security a findable home, stage 2FA setup so people finish it, force recovery codes, show an honest sessions list, warn proportionately about consequential changes, and confirm every security event so the account feels genuinely watched over.
Interested in sponsoring SaaSUI.Design? Learn about sponsorship options →