Case study 01 — Anlytic
A second factor for a passwordless login
Adding a real second factor to an email-code login, without making the first one decorative.
2
factors, still no password
Policy
enforced per workspace
Reversible
admin recovery path
The problem
The product already logged people in without passwords: request a code, receive it, you are in. Convenient, and only one factor. Adding a second one meant changing the most dangerous path in the application, where a mistake in one direction makes the new factor meaningless and a mistake in the other locks people out of their own account.
How it fits together
What I did
Stop short of a session
A successful first factor no longer hands over a working session. It produces something narrower, which can only be spent on completing the second step.
Two ways through
An authenticator app, or a single-use backup code for the day the phone is gone. Secrets are encrypted at rest and backup codes are consumed on use.
Recoverable by design
Administrators can reset the factor through a path that destroys the old secret before disabling anything, so a reset can never leave something live behind.
The hard part
The intermediate step is the entire design. Handing over real credentials after the first factor and then politely asking for the second looks identical in the interface and is worth nothing, because the credentials are already out.
Stack
Written at the level the reasoning survives. Internal specifics are left out on purpose.