Scope and fit
Account recovery often grants the same power as authentication and can be easier to manipulate. Include it in security testing as a first-class user journey.
Check token and channel handling
Test token entropy, expiry, single use, rate limits, and binding to the intended account. Verify that errors and timing do not unnecessarily disclose account existence.
Exercise support-assisted recovery
Review the evidence an agent accepts, escalation rules, audit trails, and safeguards against social engineering. Include changes to email, phone, MFA device, and payment destination.
Verify sessions after recovery
Check whether old sessions and credentials are revoked and whether users receive clear alerts. Test recovery under concurrent requests and confirm that the account's security state remains consistent.
Decisions and tradeoffs
Use this table as a working review record. Replace assumptions with evidence from the target environment.
| Decision area | Working guidance |
|---|---|
| Check token and channel handling | Test token entropy, expiry, single use, rate limits, and binding to the intended account. Verify that errors and timing do not unnecessarily disclose account existence. |
| Exercise support-assisted recovery | Review the evidence an agent accepts, escalation rules, audit trails, and safeguards against social engineering. Include changes to email, phone, MFA device, and payment destination. |
| Verify sessions after recovery | Check whether old sessions and credentials are revoked and whether users receive clear alerts. Test recovery under concurrent requests and confirm that the account's security state remains consistent. |
Implementation questions
What should the team decide about check token and channel handling?
Test token entropy, expiry, single use, rate limits, and binding to the intended account. Verify that errors and timing do not unnecessarily disclose account existence. Use a named owner and a written acceptance check so this decision can be reviewed after deployment.
What should the team decide about exercise support-assisted recovery?
Review the evidence an agent accepts, escalation rules, audit trails, and safeguards against social engineering. Include changes to email, phone, MFA device, and payment destination. Use a named owner and a written acceptance check so this decision can be reviewed after deployment.
What should the team decide about verify sessions after recovery?
Check whether old sessions and credentials are revoked and whether users receive clear alerts. Test recovery under concurrent requests and confirm that the account's security state remains consistent. Use a named owner and a written acceptance check so this decision can be reviewed after deployment.
Plan, build, verify, operate
Check token and channel handling: Test token entropy, expiry, single use, rate limits, and binding to the intended account. Verify that errors and timing do not unnecessarily disclose account existence. Record the result and the next owner before changing the next boundary.
Exercise support-assisted recovery: Review the evidence an agent accepts, escalation rules, audit trails, and safeguards against social engineering. Include changes to email, phone, MFA device, and payment destination. Record the result and the next owner before changing the next boundary.
Verify sessions after recovery: Check whether old sessions and credentials are revoked and whether users receive clear alerts. Test recovery under concurrent requests and confirm that the account's security state remains consistent. Record the result and the next owner before changing the next boundary.
Deployment checks
Turn the page into a reviewable handover by assigning each check to a person and retaining its result.
Test Password Reset and Account Recovery as Security-Critical Features: decision 1
Write down the boundary, owner, dependency, and proof required for test password reset and account recovery as security-critical features before implementation begins.
Test Password Reset and Account Recovery as Security-Critical Features: decision 2
Write down the boundary, owner, dependency, and proof required for test password reset and account recovery as security-critical features before implementation begins.
Test Password Reset and Account Recovery as Security-Critical Features: decision 3
Write down the boundary, owner, dependency, and proof required for test password reset and account recovery as security-critical features before implementation begins.
Test recovery without leaking control
Password reset is an account-recovery process and a high-value attack path. Test it with authorised test accounts and a written scope that covers request, identity verification, delivery channel, token or link lifetime, password update, session invalidation, and support escalation. Do not use a real person's reset flow or capture reset tokens outside the approved test record.
Check for account enumeration through page messages, response timing, email content, and rate-limit behaviour. A recovery link should be bound to the intended account, expire as designed, resist replay, and be invalidated after use. Review whether the flow demands reauthentication or other controls before changing a credential, especially for accounts with elevated access.
Test what happens after success: old sessions, remembered devices, API tokens, browser state, audit logs, notifications, and support records. OWASP ASVS and NIST digital identity guidance help frame expectations, but the application's identity architecture decides the actual test cases. DeployOpen can test authorised flows; the system owner decides remediations and customer communications.
Handover and ownership
Before handover, name the system owner, support path, access boundary, backup or recovery responsibility, and the condition that pauses a change.
Keep a short record of what was tested, what remains outside scope, and when the review should happen again.
