IntegrAuth Academy
Identity, security and practical AI — free, from zero. Byte-sized lessons, real diagrams, hands-on labs, zero fluff. Two programs, each with its own exam and certificate.
English is hard? Your browser can translate this page into Tamil, Telugu, Kannada, Malayalam or Hindi. Tech words stay in English so you learn the real names.
How?
- Chrome on phone: ⋮ menu → Translate
- Chrome on computer: right-click → Translate to …
- Edge: the translate icon in the address bar
Safe account recovery
Maya's phone falls into a lake. Her passkey and her authenticator app go with it. Account recovery lets her back in without the usual proof. An attacker wants the same door. Your goal: design recovery so it is not a back door.
- The best recovery is a second strong way in.
- Recovery codes: random, shown once, stored as hashes, single use.
- Text or email alone is a weak link.
- The help desk must follow rules that never bend. Never reset on a caller's word.
- After recovery, end old sessions and tell the owner.
A second way in
Plan for loss before it happens. Give each person more than one strong way to sign in. Keep one passkey on the phone. Keep a second on a laptop, or on a security key in a drawer. If one is lost, the other still works.
Nobody needs the help desk or an inbox. So "add a second passkey" is the best advice. See passkeys.
Recovery codes
A recovery code is a long random code that the user saves at setup. Each one works once. Follow five rules.
- Random and long. A person never picks it.
- Shown once. The user saves it in a password manager or prints it.
- Stored as hashes. Keep only a hash of each code. If the database leaks, the codes do not.
- Single use. A used code is dead at once.
- Slowed down. Use throttling so nobody can guess codes quickly.
Text or email alone is weak
A text goes to whoever holds the number. A SIM swap moves the number to an attacker. An email link goes to whoever owns the inbox, and many inboxes have no MFA. Use them for a notice, never as the only proof. See the SIM swap attack and recovery for customers.
The help desk is a door too
Sometimes a person decides. A caller who sounds sure or in a hurry is the oldest trick. It is called social engineering. Give the help desk rules that do not bend.
- Never reset on a caller's word. A confident voice is not proof.
- No personal questions. Birthdays and pet names are easy to find.
- Call back a number already on file. This is out-of-band verification. Never use a number the caller gives.
- A second person approves. This is dual control.
- Wait before the change takes effect. This is a cooling-off period, for example 24 hours.
- Tell the owner on every channel. Add a "this was not me" button that freezes the account.
Losing your ATM card. The bank does not hand a new card to a caller who sounds sure. It blocks the old card. Then it posts the new card to the address on file. Your recovery rules should work the same way.
Bot A has no recovery
Bot A, the RPA bot, has no phone, no inbox and no fingerprint. So it gets no human recovery. If its secret leaks, you replace it. The owner files a request. A second person approves. A new secret comes from a secrets manager. The old one is revoked and the change is logged. See secrets management.
Do not let recovery lower the level of the account. After every recovery, end all old sessions and remove the lost authenticator. Make the user enroll a new one, and issue new codes.
Go deeper: What NIST says about recovery
NIST SP 800-63B-4 is the US standard for digital identity (final in 2025). Section 4.2 covers account recovery. It says four things:
- A service must offer at least one recovery method. It can use saved recovery codes. It can send a code to an address on file. It can use trusted recovery contacts. Or it can repeat identity proofing. The service must write down its risk analysis.
- To recover an account that needs AAL2 (a strong, two-factor sign-in), one weak proof is not enough. The user needs two codes from different methods. Or a code plus an authenticator already tied to the account. Or a new round of identity proofing.
- A code sent to an address must expire fast: 10 minutes for text or voice, 24 hours for email.
- Every recovery must send a notification to the user.
NIST asks recovery codes to have at least 64 bits of randomness, about 20 random digits. That is about 18 quintillion possible codes. So a plain strong hash is enough to store them. Slow password hashing is for secrets a person chooses.
NIST also calls the phone network a "restricted" authenticator. It says email must not be an out-of-band authenticator (see magic links).
Recovery contacts are trusted people the user names in advance. The service sends them a code, and they pass it on. The user must be able to view and manage the list.
Go deeper: Logging and watching recovery
Make recovery loud. Write an audit trail entry for every step: who asked, what proof they gave, who approved and which channel was used. Send these events to security. Zara sets alerts for strange patterns:
- A recovery right after a SIM change or a new device.
- One help-desk agent doing many recoveries.
- Any recovery on an admin account.
- Many failed recoveries for one user.
A call-back is not perfect. If the attacker also swapped the SIM, the call reaches the attacker. That is why the wait and a notice on other channels matter.
🧪 Interactive lab — enable JavaScript to play with this one.
A second passkey is the best recovery route. Grade your setup, including backup keys, with Passkey Check. Designing a recovery policy? Talk to our team.