Resources · 11
Identity and account recovery: govern the complete lifecycle
Connect account creation, change, privileges, recovery and closure to verifiable evidence and rehearsed decisions.
· 16 min
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.
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.
