Resources · 11

Identity and account recovery: govern the complete lifecycle

Connect account creation, change, privileges, recovery and closure to verifiable evidence and rehearsed decisions.

Updated 23 October 2026 · 8 min

Illustration · fictional scene

What this guide helps achieve

Connect every account to a person or service
Reduce standing privilege
Protect recovery requests
Revoke quickly without losing continuity

Quick check

Who approves creation and role change?
Can an old factor reset the account alone?
Are shared-account actions attributable?
Do privileges expire?
Has phone loss been exercised?

Step-by-step method

01
Inventory identities and dependencies
List human, service, shared, federated and emergency accounts. Connect them to applications, owners, authentication methods and accessible data.
Deliverable: identity, account, system and owner register.
02
Connect lifecycle to events
Define triggers for onboarding, mobility, absence, role change, departure and deletion. Measure delay between the event and effective access change.
Deliverable: event and action matrix.
03
Reduce privilege
Separate daily use from administration, limit elevated-access duration and review entitlements according to service risk.
Deliverable: role catalogue and dated exceptions.
04
Harden recovery
Use independent evidence, a safe channel, suitable delay and human escalation for unusual requests.
Deliverable: recovery decision tree.
05
Prepare for loss and compromise
Plan session, factor and device revocation, service-desk communication, fallback access and proportionate trace retention.
Deliverable: lockout and recovery runbook.
06
Exercise and improve
Test an urgent departure, lost phone and impersonation attempt. Observe decisions, timing, evidence and operational impact.
Deliverable: exercise report and remediation plan.

Worked example

Illustrative situation

An administrator loses an authentication device while on call. Support checks a pre-agreed proof, obtains a second approval for recovery and invalidates affected sessions.

Decision and expected evidence

The exercise checks service continuity and retains the request, approval, replaced factor and post-incident review.

Management indicators

Indicator	What it measures	First action
Attributed accounts	Accounts connected to an active owner	Handle ownerless accounts first
Revocation delay	Time from event to access removal	Automate reliable steps
Temporary privilege	Elevated access with duration and rationale	Expire entitlement by default
Verified recovery	Requests following every expected proof	Review each bypass

Common pitfalls

Treating personal questions as strong evidence
Letting support bypass MFA without dual control
Forgetting service accounts
Keeping privilege after an assignment

Frequently asked questions

Is MFA enough?

No. It reduces some risks, but lifecycle, recovery, sessions and privileges can still remain vulnerable.

Should every shared account be prohibited?

Prefer individual identities. When a shared account remains necessary, document why, restrict it and make each use attributable.

What should be exercised first?

Loss of the primary factor and urgent departure of a highly privileged person quickly expose real dependencies.

Identity: factors, sessions and recovery

An authentication method must be assessed alongside enrolment, recovery and the sessions it opens. A passkey label, a phone or a biometric sensor does not by itself establish the assurance level of the entire service.

References use NIST SP 800-63B-4, finalised in July 2025, and WebAuthn Level 3, a W3C Recommendation since 25 August 2026. AALs describe authentication transactions rather than product scores or certifications earned by ticking this table. Application depends on service scope and risk assessment.

Sources consulted on 2026-10-22.

Two unbranded security keys in an empty cyber laboratory — AI-generated fictional illustration: two unbranded keys in an empty lab. Appearance proves neither key non-exportability nor assurance level.

Compare eight methods without confusing their guarantees

Compare eight methods without confusing their guarantees
Method and reference	Property and conditions	Recovery and dependencies	Evidence to request
Entered password NIST · Authenticators and password requirements	Knowledge factor; a false site can relay or capture the secret.	Depends on the password manager and the password replacement path.	Length policy, compromised-secret blocking and a tested replacement journey.
Manually entered TOTP NIST · Authenticators and password requirements	Possession of a shared secret; manual entry does not bind the output to the legitimate session.	Plan for loss of the generator and protection of seeds or provider backups.	Authorised enrolment, secret protection and revocation; do not call every OTP phishing-resistant.
SMS or voice code NIST · Authenticators and password requirements	PSTN out-of-band channel, restricted in the NIST framework; manual codes are not phishing-resistant.	The number, carrier and SIM or line changes are dependencies.	Channel justification, risk signals, alternatives and number-change procedure.
Simple push approval NIST · Authenticators and password requirements	Approval without cryptographic verifier-name or channel binding does not establish phishing resistance.	Lost phones and application re-enrolment require handling.	Actual protocol, user intent and enrolment controls; the push label alone is insufficient.
Syncable WebAuthn with UV NIST · Syncable Authenticators W3C · WebAuthn Level 3	Cryptographic binding to the service; user verification (UV) must be requested and checked when required. Syncable keys are exportable in NIST terminology.	The sync account, its devices and its recovery enter the trust boundary.	Sync and UV requirements. Syncable methods do not fit AAL3, which prohibits key export.
Device-bound WebAuthn with UV NIST · Authentication Assurance Levels W3C · WebAuthn Level 3	Service binding and user verification. Device-bound alone does not establish non-exportable hardware protection.	Device loss requires another authorised method or controlled recovery.	Storage properties, UV, proof of non-exportability when needed and tests of actual clients.
WebAuthn key without UV NIST · Authenticators and password requirements W3C · WebAuthn Level 3	Service binding, but possession alone in this case. A touch or user presence (UP) flag is not proof of user verification (UV).	Plan a second authorised method and lost-key revocation.	UP/UV checks and the factor combination required by the service; hardware form alone does not establish MFA.
Biometrics considered alone NIST · Authenticators and password requirements	In the NIST framework, biometrics accompany a physical authenticator in MFA; they are neither secrets nor sufficient standalone mechanisms.	Provide a non-biometric alternative and protect biometric information appropriately.	Comparison location, activation role and accessible alternative; distinguish biometric comparison from cryptographic proof.

Three AALs: distinguish requirements and recommendations

Three AALs: distinguish requirements and recommendations
Level and factors	Resistance and key export	Overall reauthentication timeout	Inactivity
AAL1 One factor can suffice at this level.	Phishing resistance not imposed by this level; key export permitted.	At most 30 days: SHOULD recommendation.	No numeric ceiling in this reference; define the service policy.
AAL2 Two distinct factors.	A phishing-resistant option must be offered; key export permitted under applicable conditions.	At most 24 hours: SHOULD recommendation; establishing a definite overall limit remains mandatory.	At most 1 hour: SHOULD recommendation.
AAL3 Cryptographic authenticator and additional or activation factor.	Phishing resistance and a non-exportable private key required.	At most 12 hours: SHALL requirement.	At most 15 minutes: SHOULD recommendation.

These values are not cookie lifetimes to copy blindly. NIST distinguishes overall and inactivity limits and then defines reauthentication rules. Applications may choose shorter periods based on risk. IAL concerns identity proofing and FAL federation: AAL does not replace either dimension. NIST §2 →

Passwords: seven precise NIST reference points

Single factor: Minimum 15 characters required.
Within MFA: Minimum 8 characters required when the password is used only in a multifactor process.
Accepted length: Allowing a maximum length of at least 64 characters is recommended.
Composition: No imposed mixture of character types.
Replacement: No arbitrary periodic changes; force a change when there is evidence of compromise.
Secrets to reject: Compare against commonly used, expected or compromised passwords.
Entry assistance: Allow password managers and autofill; permitting paste is recommended.

NIST §3.1.1.2 →

Recovery: four classes and their conditions

Previously saved code: At least 64 random bits in the NIST framework; offline subscriber storage, hashed server storage and invalidation after use.
Code issued on demand: Codes sent by text or voice are valid for at most 10 minutes; email codes for at most 24 hours. Verify addresses and apply the target level’s conditions.
Recovery contact: Organise contact addresses and associated checks; a personal relationship does not replace technical recovery requirements.
Repeated identity proofing: An option for previously identity-proofed accounts. Without prior identity proofing, do not claim to re-verify an unknown identity.

Replacing a forgotten password through another still-valid authenticator is binding a new authenticator rather than necessarily account recovery. Document notifications, delays, revocations and responsibilities so support does not become a bypass. NIST §4 →

Connect authentication, sessions and incidents

Connect authentication, sessions and incidents
Stage	Proposed practical check	Observable evidence
Enrol	Check who authorises a new authenticator and notify the subscriber through a known path.	Record of binding, associated method and authorisation basis.
Authenticate	Check the protocol, expected domain and required factors before granting access.	Results on chosen clients, with presence and verification indicators separated.
Manage the session	Define overall expiry, inactivity, reauthentication for sensitive actions and logout invalidation.	Expired-session, logout and post-revocation access tests.
Report loss	Identify the affected authenticator, preserve useful evidence and decide invalidation based on suspected compromise.	Report timeline and observed access result after handling.
Recover	Follow a documented path, notify and prevent an old session from adding a new method without appropriate checks.	Successful recovery case and refused bypass case.
Leave the service	Remove obsolete authenticators and access; address relevant sessions, devices and sync authorisations too.	Revoked methods, removed access and remaining dependencies.

WebAuthn: verify the response at the service

The server must correlate the challenge, authorised origin, RP ID hash and signature with the expected ceremony and check required flags. UP signals presence; UV signals user verification. BE and BS describe credential backup eligibility and state without independently certifying the sync system. Use a maintained library and the complete procedures in specification sections 7.1 and 7.2. WebAuthn Level 3 →

Include people who use a different journey

WCAG 2.2 criterion 3.3.8, level AA, addresses cognitive tests during authentication with specific exceptions and assistance mechanisms. Test password managers, paste, labels, keyboard, cancellation and fallback in practice. NIST requires a non-biometric alternative; making it usable is part of design. WCAG 2.2 · 3.3.8 →

Continue with identity governance →

Primary references and scope

Publication and consultation dates are distinct. Proposed tests and evidence are editorial; linked normative texts govern. Vendor documentation describes its own product and does not establish your application’s AAL.

NIST SP 800-63B-4 · final publication · Publication : 2025-07-31
NIST · Authentication Assurance Levels · Publication : 2025-07
§2.1–2.3
NIST · Authenticators and password requirements · Publication : 2025-07
§3.1.1; §3.2.3; §3.2.5
NIST · Authenticator Event Management · Publication : 2025-07
§4.1; §4.2; §4.6
NIST · Session Management · Publication : 2025-07
§5
NIST · Syncable Authenticators · Publication : 2025-07
Appendix B
W3C · WebAuthn Level 3 · Publication : 2026-08-25 · W3C Recommendation
§6.1; §7.1–7.2
W3C · Accessible Authentication (Minimum) · Publication : 2024-12-12
WCAG 2.2 · 3.3.8 · AA

Extensions: permissions and access

Robust authentication does not describe extension access

Phishing resistance does not remove the need to examine what runs in the browser after a session opens. A manifest provides clues about cookies, scripting, debugging and identity without establishing collection.

Test approved extensions in a profile dedicated to sensitive operations.
For identity, inspect OAuth scopes and recipients; this permission does not enumerate identity-provider rights.
Distinguish session revocation, token revocation, extension disablement and native-component removal.

Read the permission directory and manifest examples →

Google Chrome · Stay secure · Documentation consulted 2026-10-23; browser behaviour remains version-dependent

Official references

References consulted: 23/10/2026. The method and worksheet propose checks to adapt to your context; they do not constitute certification.