Identity Verification

Overview

We wanted an additional identity check for higher-risk sign-ins without making every login more cumbersome. The product question was when to ask for verification and how to help someone complete it without leaving them stuck.

We answered that with adaptive verification: when sign-in context crossed the target threshold, the flow required a step-up before opening the session.

A teammate shaped the initial design, and I implemented the critical path across detection, verification, and UX for the first release. Two identity teammates helped harden tests and edge cases. Together, we shipped that first targeted release in under two weeks.

What I built

The detection path evaluated sign-in context to decide when verification was required. From there, the flow had to manage the challenge, get it to the user, enforce guardrails, and account for recovery. The UX explained why the extra check was being requested so it did not appear as an unexplained interruption.

I partnered with a PM to keep the first release focused on that path. We deferred non-critical polish while keeping detection, verification, and recovery in scope, then returned to some of the deferred work in later iterations.

Collaboration

Product helped keep launch scope tied to the targeted risk path, and the security team supplied the data that shaped the rollout order.

Outcome

• The first targeted adaptive-verification release shipped in under two weeks.
• The rollout added adaptive verification to the targeted higher-risk sign-in path.
• The first version established the decisioning, verification, guardrail, and recovery pieces later identity-verification work could build from.

The first version made a deliberate tradeoff: ship the targeted path quickly, then reserve follow-up time for known cleanup. The habit I kept was to name that work at launch, while the reasons for deferring it were still clear, instead of letting it disappear into the backlog.