# Identity security: phishing-resistant login, usable recovery and verified offboarding Canonical: https://www.web3sec.news/blog/identity-mfa-recovery-runbook Author: Raiders (https://www.web3sec.news/about) Format: guide Topic: Identity Published: 2026-11-08 Updated: 2026-11-08 An operating procedure for the accounts that control email, cloud infrastructure, source code and company recovery. ### Diagram: Account recovery is part of the authority graph. Review login, sessions, service grants and recovery as connected control paths. ![Account login creates a session, which can grant connected services downstream authority. An independent recovery channel must be separately verified and must not depend entirely on the same compromised account. Session revocation alone may leave downstream grants active.](https://www.web3sec.news/diagrams/identity-recovery.svg) [Full-size SVG](https://www.web3sec.news/diagrams/identity-recovery.svg) · [PNG download](https://www.web3sec.news/diagrams/identity-recovery.png) Original explanatory control model; not a reconstruction of private incident evidence. ## Assign ownership and map the recovery graph Make one person accountable for the identity inventory and give a second person access to the recovery procedure. List the identity provider, privileged users, independent administrator accounts, service identities and every critical service that does not use central sign-in. Record the account that can reset each one. A forgotten registrar or package-publishing account can defeat an otherwise careful identity program. Draw the dependency between the work mailbox, password manager, telephone number and identity provider. Find cycles: recovering email must not require a code delivered only to the inaccessible email account. For every critical identity, record an alternate verified recovery path, the custodian of offline material and the provider escalation process. Store recovery secrets separately from the inventory itself. ## Establish a login and enrollment baseline CISA identifies FIDO/WebAuthn as phishing-resistant authentication. Use that capability for privileged and high-impact accounts where the service supports it. Inventory fallback methods as well as the preferred method: an excellent security key deployment is undermined if an attacker can choose an easier password-reset or SMS path. NIST provides the underlying distinctions between authentication, authenticator binding and recovery. Our operating recommendation is to enroll an independently stored backup authenticator before enforcing a policy. Test it from a clean session and verify that its custodian can reach it during travel or device loss. Restrict new authenticator enrollment and privileged-role assignment to a documented process. Notify the user through an existing trusted channel when either event occurs, rather than trusting a newly supplied address. ## Recognize failure and contain authority Treat an unexplained authenticator enrollment, recovery-address change or privileged session as an incident signal. The responder should verify the user through a previously established channel, preserve sign-in and enrollment logs, and assess both the account and its active sessions. A successful password reset does not establish that previously issued application sessions or refresh tokens have stopped working. Use a trusted device to revoke affected sessions and credentials, remove unapproved authenticators and review downstream application grants. If the identity provider is affected, use the independent administrator path according to the emergency procedure and investigate actions taken through connected services. Keep a decision log identifying who suspended access, the scope of that suspension and the evidence needed to restore it. ## Test recovery and employee departures Run a controlled lost-device exercise using a designated test administrator. Time the complete recovery, including approval, backup access, replacement enrollment and invalidation of the lost authenticator. The exercise fails if the team must invent an unverified shortcut or if a departed employee remains able to recover the account. Record the exact gap and an owner for its correction. For offboarding, reconcile the central identity directory with separate service inventories. Verify removal of package-publishing access, personal access tokens, SSH keys, application passwords, recovery addresses and shared administrator credentials. Use a harmless former test account to prove access denial. Retain evidence of revocation and transfer ownership of scheduled jobs before deleting an identity that those jobs still depend on. ## Controls to take away - Authentication, session control and recovery are separate controls. - A second authenticator helps only when it remains independently available. - Offboarding requires checks outside the central identity directory. ## Working checklist Assign owners and record supporting evidence in your team's system. - [ ] Name the inventory owner and independent recovery custodian. - [ ] Enroll and test a separate backup authenticator. - [ ] Review every fallback and authenticator-enrollment path. - [ ] Verify session revocation after a controlled test. - [ ] Reconcile offboarding across services outside central sign-in. ## Sources & further reading - [CISA: implementing phishing-resistant MFA](https://www.cisa.gov/sites/default/files/2023-01/fact-sheet-implementing-phishing-resistant-mfa-508c.pdf) - [NIST SP 800-63B: authentication and authenticator management](https://pages.nist.gov/800-63-4/sp800-63b.html) Incident facts are attributed to the linked reports. Recommendations are Web3Sec's analysis. [Research methodology](https://www.web3sec.news/methodology) · [Editorial policy](https://www.web3sec.news/editorial-policy) · [Send a correction](https://www.web3sec.news/contact)