Account Recovery UX: Your Lockout Flow Is the Real Security Test

Every regulated product spends months on its login screen and about a week on what happens when login fails. That ratio is backwards. Login is the path for people who already succeeded. Recovery is the path for people who are stressed, on a new phone, traveling, or locked out of their own money. It is where trust is either earned or quietly burned.

Read any fintech subreddit for ten minutes and the pattern is obvious. People describe new phones that trigger a fresh identity check, selfie videos that get rejected with no reason, one-time codes that never arrive, support agents who confirm the video looks fine but "the system keeps rejecting it," and lockout timers that reset every time they try something new. The stories end the same way. The customer gets back in eventually, then moves their money somewhere else.

Our position is simple: account recovery UX is a product surface, not a security setting. If your recovery flow can trap a legitimate customer for two weeks, it is not secure. It is just broken in a direction your fraud dashboard does not measure.

Why recovery breaks in regulated products

Recovery fails for structural reasons, not because a designer forgot an error message.

It is owned by nobody. Login belongs to the auth team. Identity verification belongs to compliance and a vendor. Device binding belongs to mobile. Support owns the phone queue. Recovery crosses all four, so each team optimizes its own step and nobody walks the whole path end to end.

It is tested only on the happy path. Teams test "forgot password" with a working inbox and a phone that receives SMS. They rarely test a factory reset phone, a changed number, a VOIP number, a user abroad, an iPhone saving photos in a format the vendor rejects, or a camera switch that drops a video call. Those are not edge cases. For recovery, those are the cases.

Security rules stack without a ceiling. One rule adds a cooldown after a phone number change. Another adds a lockout after failed verifications. A third forces reverification on a new device. Each rule is reasonable alone. Together they can create a loop where every attempt restarts the clock and the customer has no legal way forward.

The system cannot explain itself. Most identity vendors return a pass or fail with limited reason codes, and product teams pass that opacity straight to the user. "We couldn't verify you" with a retry button is not a flow. It is a slot machine.

What a good recovery flow does

We judge recovery on four questions. If your product cannot answer all four clearly, that is where the work is.

1. Does the user always know what state they are in?

A locked-out customer needs three facts on one screen: what happened, what they can do right now, and when the next option opens. "Your account is temporarily restricted" fails all three. "We paused sign in after a phone number change. You can verify with a photo ID now, or wait until Nov 4 and sign in with your new number" passes. Timers should be absolute dates, not vague "try again later" copy, and they should never silently reset.

2. Is there more than one path, and is the next path visible?

Every primary method needs a named fallback that the user can see before the primary fails, not after the fourth failure. SMS code, then email link, then document plus selfie, then live video review, then assisted review with a human. The product should step down automatically after a defined number of failures instead of letting someone retry the same broken method thirty times. If customers are discovering on Reddit that asking for video review is the secret door, your door is in the wrong place.

3. Does a failure come with a reason a human can act on?

You do not have to reveal fraud signals to give useful guidance. "The photo was too dark," "the file format was not supported," "the name does not match the one on your account," and "the camera connection dropped" are all safe to say and all fixable. Map your vendor's reason codes to plain language once, and route the codes you cannot explain to human review instead of to another retry.

4. Can support actually help, and can the user see that they are in a queue?

The worst recovery experiences share one detail: support agents who can see the problem but cannot act on it. Give support a scoped, logged override path with a second approver. Show the customer a case status they can check without logging in, with a case number, the step they are on, and the expected response window. A visible queue reduces repeat contacts and repeat contacts are where support costs and anger both compound.

The distinctions most teams blur

Recovery is not password reset. Password reset assumes the user still controls their email and device. Recovery is for when they control neither. Design them as separate flows with separate entry points.

Friction is not the same as security. A step that a fraudster can pass with a stolen phone but a real customer fails on a new phone is friction pointed at the wrong person. Measure each recovery step on both sides: what fraud it stops and what legitimate users it blocks.

Lockout is not a terminal state. Treat a locked account as a state machine with exits, not a wall. Every lock should have a documented unlock path, an owner, and a maximum time before a human looks at it.

Vendor UI is still your UI. If your identity provider's SDK drops video calls or rejects common photo formats, your customer does not blame the vendor. They blame you. Wrap vendor steps with your own pre-checks, format handling, and fallback copy.

What we reject

When we review recovery in a fintech, insurance, health, or B2B SaaS product, these patterns get flagged immediately:

• "Try again later" with no date or time.
• Cooldown timers that restart on every attempt.
• A forgot password link that disappears behind mandatory two factor with no alternate.
• Notifications that deep link a locked-out user back into the same failing check.
• Unlimited retries on a method that is clearly not working for this person.
• Support scripts that tell the customer to reinstall the app as the only escalation.
• Identity checks that reject photos for file format reasons instead of converting them.
• Recovery that only works on the device the user just lost.
• A "resolved" email sent before the customer has actually signed in.
• No way to check case status without being signed in.

How we fix it

We do not start with screens. We start by mapping every recovery trigger the product actually has: new device, number change, failed two factor, failed identity check, fraud hold, dormant account. For each trigger we trace the real path in working software, on a wiped phone, a changed number, and an expired session, and we record where the user gets stuck and for how long.

Then we fix in this order: state clarity first, because it is mostly copy and cheap to ship. Visible fallbacks second. Reason code mapping third. Support tooling and case status last, because it touches compliance and needs sign off. Senior people make the judgment calls on where to hold friction and where to cut it. AI helps us move fast on the rest: generating the trigger inventory from code and logs, drafting reason code copy, and building the prototype flows in real code instead of static mockups, so compliance and engineering can click through the actual path before anything ships.

The test we use at the end is blunt. Take a legitimate customer on a brand new phone with a new number, abroad, at 11pm. Can they get back in, or at least know exactly when and how they will, without calling anyone? If the answer is no, the recovery flow is still the weakest part of your security story, and the part your customers will remember.

Talk to us

If your support queue is full of lockout tickets, or your reviews keep mentioning verification loops, recovery is likely costing you more than any fraud it prevents. Book a discovery call or email ash@uxsignalstudio.com and we will walk the path with you on a wiped phone.