Use case
Secure OTP delivery for account recovery
Restore access without turning the recovery path into the easiest way around the account’s normal security controls.
What the flow must protect
What the OTP shows
- Someone currently controls a destination previously registered on the account.
- The otpId your application stored on that recovery request was validated once.
- The recovery event, its attempts and its outcome are recorded for later review.
What it does not show
- That the requester is the account holder. Recovery destinations go stale, get ported and get compromised.
- That the account was not taken over. SIM swap and mailbox compromise both defeat a possession check.
- That recovery is complete. Credentials still need resetting and existing sessions still need revoking.
Where the flow breaks
Stale phone and email data
Recovery reaches a number the user gave up years ago, or a work mailbox they no longer have, and the flow dead-ends into support.
SIM swap and compromised mailboxes
An attacker who controls the destination passes the check cleanly. Without additional signals, recovery becomes the weakest path into the account.
Unprotected destination changes
If a phone or email can be changed and immediately used for recovery, the possession check proves nothing about the original owner.
Unlimited retries and support workarounds
Uncapped attempts and helpful agents who bypass the flow undo every control that sits in front of it.
Destination-change and cooling-period decision flow
The riskiest moment in recovery is changing where recovery codes go. This decision flow keeps a destination change from becoming an instant account takeover.
Verify the existing destination first
Before anything else, confirm control of a destination already on file.
Decision: no destination change request proceeds without this.
Require the current factor
Ask for the account's normal sign-in factor in addition to the recovery request itself, where the account state allows it.
Decision: if the current factor cannot be produced, treat this as a higher-risk recovery, not a routine one.
Apply a cooling period before the new destination is usable
Record the new destination, but do not allow it to authenticate the account immediately.
Decision: the cooling period length is a risk decision your policy sets — Flow2FA delivers and verifies codes, it does not set this window.
Notify the old destination
Tell the previous destination that a change was requested, giving a legitimate owner a chance to intervene.
Decision: if the old destination reports the change as unauthorised, halt the cooling period and lock the request.
Re-verify before recovery through the new destination
Once the cooling period ends, require a fresh possession check against the new destination before it can be used for recovery.
Decision: a stale or unconfirmed new destination is not promoted to a recovery channel automatically.
Record the outcome
Log the request, the cooling period applied, notifications sent and the final result against the account's security history.
Decision: this record is what a later takeover dispute is reconstructed from.
A production flow
A recovery request is received
The user asks to reset a password or regain access to a locked account.
Account and risk checks run
Your systems evaluate the account state, device, location and recent activity before any code is issued.
Existing channels are notified where appropriate
Telling the account holder that recovery was started gives a legitimate owner a chance to intervene.
A bound one-time challenge is generated
The code is tied to the recovery request, with a short lifetime and a strict attempt limit.
Delivery goes through an approved route
Only channels your recovery policy allows are used, with fallback that you have explicitly permitted.
The code is verified
Verification is checked against the specific recovery request, then the code is consumed.
A cooling period or extra review is applied where needed
Higher-risk recoveries can wait, escalate to manual review, or require a second proof.
Credentials are reset and sessions revoked
Reset the password, revoke active sessions and tokens, and notify the account holder that recovery completed.
The event is recorded
Store the request, channel, attempts and outcome so a later dispute can be reconstructed.
How Flow2FA fits
Recovery traffic kept separate
Route recovery messages under their own, stricter policy so they are not mixed with lower-risk traffic.
Restricted channel choice
Permit only the channels your recovery policy accepts, and disallow fallback where it would weaken the check.
Controls to define, and what to measure
Controls to define
These are your decisions. Flow2FA carries and verifies the code; the policy stays yours.
- Protection and cooldown on phone and email changes before they can be used for recovery
- Rate limits and cooldowns per account, destination and device
- Which channels are approved for recovery, and whether fallback is permitted
- Risk and device signals your systems supply with the request
- Step-up requirements or manual review thresholds
- Post-recovery notification to all previously known destinations
- Session, token and API-key revocation on completion
- Stronger or multiple proofs for privileged, administrative and high-value accounts
- Retention of recovery evidence for investigation periods
What to measure
Measure completed verification, not accepted API calls. Acceptance and delivery receipts are progress indicators, not outcomes.
- Recovery completion rate against recovery requests started
- Median and p95 time to completed recovery
- Failed verification attempts per recovery request
- Share of recoveries that required support assistance
- Destination-change incidents preceding a recovery
- Resend and fallback rate on recovery traffic
Integration options
Recovery usually lives in the same service as sign-in, so it tends to follow whatever that service already uses. What matters more is that recovery traffic is policy-separated from ordinary login traffic.
Shared integration detail
REST vs SMPP, the provider model, routing and fallback, and full channel detail are covered once, in full, on the OTP API overview. For how to weigh those choices against your own requirements, see the buyer guide.
Channel availability depends on the setup configured for each account. The current public REST reference documents SMS and email channel values, while configured Flow2FA setups may also include WhatsApp.
Make recovery the hardest path, not the easiest
We will look at your current recovery journey — destinations, fallback, support escalation — and where OTP delivery and attempt history can tighten it.