Identity Verification

Overview

The risk model was account takeover on higher-risk sign-in paths. The product problem was narrow: add protection where the risk model said another check mattered, without adding friction to every login.

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, which mattered because we were shipping inside a two-week window.

What I built

Decisioning evaluated contextual sign-in signals and determined when to require verification. The verification path handled the challenge lifecycle, delivery path, guardrails, and recovery cases. The UX kept the step-up reason visible so the extra check had context.

I partnered with a PM to keep the first release limited to the path we needed to protect. We cut non-critical polish outside the decisioning, verification, and recovery loop. Some of that came back in later iterations, but the first release showed that the targeted protection window mattered more than finishing secondary polish.

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. I still think that was the right call for the risk window, and the habit I kept is to name the debt at launch instead of letting it disappear into the backlog.