Plan web-app login and account recovery together

Start with the people and records at stake

List who needs an account, what the app exposes, what damage a mistaken sign-in could cause, and which devices and support channels people can actually use. An internal dispatcher, a field technician on a shared device and an external customer may need different enrollment and recovery paths. Decide who creates accounts, how an invitation reaches the intended person, how the account is suspended, and who owns exceptions. Do not assume that an email address alone proves a person’s real-world identity.

NIST SP 800-63B describes levels of confidence that a claimant controls authenticators bound to an account. Its mandatory language is written for the digital identity services within that publication’s scope; use it as a reference for proportionate design, not as a claim that every small-business app has a federal compliance obligation. At AAL1, NIST allows one factor and recommends offering MFA. AAL2 requires two distinct factors and a phishing-resistant option. Choose the assurance your app needs with a qualified security reviewer where the data or consequences warrant one.

Copy this login and recovery decision matrix

Use one row for each user group whose access, risk or support situation changes the decision. Copy the header below into a controlled planning sheet. Use role names and invented examples in public material; keep real identities, recovery addresses, codes and support evidence out of the worksheet and analytics.

• Group and protected task | Account setup and verification | Normal sign-in and added factor | Device/access constraints | Lost-password or lost-factor route | Suspected-compromise route | Rebinding, sessions and notification | Decision owner and test IDs.
• Group and task: state what the person must do and the sensitivity of the records or actions they can reach. Link detailed record permissions to the separate permission matrix.
• Setup and sign-in: specify invitation or enrollment, the primary authenticator, whether another factor is needed, and whether the chosen method works on the user’s real devices.
• Loss and compromise: name the evidence that permits recovery, the channel that delivers it, the person who may approve an exception, and what happens when that evidence is unavailable or suspected stolen.
• After recovery: decide which old authenticators, sessions and unused recovery links are revoked, how new ones are bound, who receives a notice, and how a user reports an unauthorized change.
• Tests: give every allowed recovery an expected result and at least one denied or delayed case, including an unknown account, reused code and unverified factor replacement.

Choose a sign-in method with its real limits

Passwords remain possible, but they are not phishing-resistant. If the app uses them, specify password-manager and paste support, checks against common or compromised choices, and limits on repeated guesses. NIST’s current password guidance rejects composition rules and routine forced changes. Its exact minimum lengths apply within its own scope: 15 characters for a password used alone, or at least eight when it is part of MFA. Do not copy one number into a project without first deciding which authentication model and policy apply.

Passkeys can offer phishing-resistant sign-in when WebAuthn registration and server verification are implemented correctly. They still need enrollment, a way to add more than one authenticator, removal of a lost credential, and a recovery policy. A touch that proves user presence is different from local user verification by PIN or biometric; when a passkey is expected to satisfy MFA, the server must request and check user verification. Synced credentials can ease device replacement, while device-bound credentials may suit a managed environment; either choice needs an account-recovery plan.

If a second factor is required, decide how it is enrolled, changed and used when the normal device is unavailable. OWASP treats factor replacement as a high-risk action: an active session alone should not silently authorize it. Consider an already enrolled factor, single-use recovery codes, or a documented staffed process appropriate to the app’s risk. A convenient fallback that lets anyone with mailbox access disable a stronger factor may become the effective security of the whole account.

Design the lost-access and takeover paths before launch

Trace three separate cases: the user remembers a working factor but forgot a password; the user lost every usable factor; and the user suspects someone else controls the account. They can require different evidence and actions. NIST distinguishes replacement of a forgotten password while another bound authenticator is available from full account recovery after control of the needed authenticators is lost. Document which path the app offers, who approves it, and when the user is notified.

For a password reset, OWASP recommends a response that does not reveal whether an account exists, controls against automated requests, and a securely generated, single-use, expiring token or code. Do not change the account merely because someone requested a reset. After a valid reset, return the person through the normal sign-in path and decide whether to invalidate existing sessions. A lost MFA factor needs its own controlled replacement path; a password-reset link should not automatically remove that factor.

Treat suspected takeover as more than a forgotten password. Check established recovery evidence rather than trusting contact details recently changed by an attacker. Invalidate compromised authenticators, old sessions and outstanding reset links as appropriate, review recovery addresses and factors with the verified owner, and send a notice through established channels. If safe recovery evidence is missing, the written outcome may be a delayed manual review or denial, not an improvised support override.

Hypothetical example: a repair-job team loses a phone

Imagine an equipment-repair business planning an internal app. These roles and policies are invented to demonstrate the matrix; they describe no Kinetivy client, deployment or result. Dispatchers can assign work, while technicians can update assigned jobs. The business owner and security reviewer decide that both groups use named accounts and an added factor. Technicians sometimes work away from the office, so a staffed in-person-only recovery route would leave them unable to report completed work.

The team proposes enrolling a second authenticator and issuing single-use recovery codes in advance. A technician who loses a phone signs in with an existing password and an already enrolled backup factor or unused recovery code to reach a restricted replacement flow, then registers a new factor. The app invalidates sessions on the lost device and notifies an established address; suspected takeover follows the separate containment route above. A request to replace a factor using only a newly changed email address is denied and sent to a documented manual review. The business must still decide how to authenticate a person who has lost both the phone and every backup; that unresolved case is written as a launch decision, not hidden behind a “contact support” button.

• Worked matrix row, in the eight-column order above: Technician updating assigned jobs | Named account created by the operations owner after checking staff assignment | Password plus enrolled second factor | Personal phone may be lost during field work; backup enrolled before work begins | Existing password plus unused recovery code or another enrolled factor permits restricted replacement; no backup means manual hold | Suspected takeover goes to the reviewed containment and identity-check route, not an ordinary reset | Revoke sessions on the lost device, bind the new factor after proof, and notify the established address | Operations owner and security reviewer; T1–T6 below.
• T1 allow: the active technician signs in with the normal method and reaches only the permitted app task; account and record permissions remain separate checks.
• T2 allow: the technician presents an unused, valid pre-issued recovery code, replaces the lost factor through the restricted flow, and receives a change notice.
• T3 deny: a used or expired code cannot be replayed, even if the requester knows the username.
• T4 deny or hold: an active session or newly changed mailbox alone cannot silently replace the second factor.
• T5 protect: reset requests for a known and an unknown account give a non-enumerating public response and do not lock or change an account before valid proof.
• T6 contain: a reported stolen device leads to the agreed credential and session revocation, notification and reviewed recovery path.

Review the complete journey, including failure

Have the business owner, support owner and technical reviewer walk each row from enrollment through normal use, loss, recovery and closure. Check who can approve a manual exception, what evidence they can inspect, how they record the decision without storing secrets, and what the user sees while waiting. Test an unavailable mailbox or device and an unknown account as well as the happy path. The web-app acceptance-testing guide explains how to run and record release tests; this matrix supplies the authentication decisions those tests should verify.

Review the matrix when a new user group, identity provider, factor, support channel or sensitive action is added. Sign-in establishes who is presenting an account; it does not decide which records that account may access. Use the permission-matrix guide for those record and action rules, and the customer-portal guide for the broader invitation and account lifecycle.