Identity lifecycle management is the process of creating, changing and removing accounts and access as a person or service joins, changes role and leaves. Done well, access matches the current job and ends the day it should. Done badly, old access piles up and nobody notices.
What are the stages?
Teams call them joiner, mover and leaver.
Joiner: an account is created, linked to a person or owner, and given the access the role needs, no more. Mover: access changes when the person changes team, and the old access is removed rather than added to. Leaver: all accounts are disabled promptly, sessions and tokens are revoked, and data and ownership are handed over.
Two further stages tend to be forgotten. Periodic review checks that existing access is still justified. Service and machine identities need the same lifecycle with an owner, a purpose and an expiry.
What do the standards ask for?
NIST SP 800-53 Rev. 5 control AC-2, Account Management, is the usual reference. It covers defining account types, assigning account managers, requiring approvals, creating, enabling, modifying, disabling and removing accounts, and monitoring their use. Related controls cover least privilege (AC-6) and separation of duties.
The control wording is deliberately general. How fast "promptly" is depends on your risk. Write your own number, for example one business day for a standard leaver, and measure against it.
Where does it go wrong?
A constructed example. A contractor finishes a project in March. The contract ends in the finance system, but the contractor's cloud account was created by a team lead through a different path. Nothing links the two records. In November, the account still works and still holds read access to a code repository.
The failure is not a missing tool. It is a missing source of truth. Accounts created outside the main path never receive the leaver event.
Movers are the quieter problem. A person who moves from support to engineering keeps support tools and gains engineering ones. After three moves, they hold the union of everything they ever did.
How to check or apply this
- Pick a source of truth for people, such as the HR system, and a registry for non-human identities with a named owner.
- List every system that holds accounts. Mark which ones receive automatic updates and which rely on a person to remember.
- Define role based access bundles for common jobs so joiner and mover steps are repeatable.
- On a move, remove the old bundle in the same change that grants the new one.
- On leaving, disable first, then delete after a retention period. Revoke tokens, API keys and sessions, and rotate shared secrets the person knew.
- Review access on a schedule: quarterly for privileged roles, less often for the rest.
- Run a monthly orphan check: accounts with no matching active person or owner.
What about contractors and temporary access?
Contractors, interns and partner staff are the hardest case because they sit outside the HR system. Give every external account an end date at creation and a sponsor who is an employee. When the date arrives, the account is disabled unless the sponsor renews it. Renewal should be a deliberate act, not a default.
The same idea works for temporary elevation. If an engineer needs production access for a day, grant it for a day. Access that expires on its own cannot be forgotten, and the audit trail shows who asked and why.
How do you measure whether it works?
Track a few numbers. Time from the leaving date to all accounts disabled. Count of accounts with no owner. Share of reviews completed on time. Count of accounts with privileges not matched to a role. Trends matter more than a perfect score on day one.
Quick check
Does identity lifecycle management include service accounts?
Yes. Service accounts and API keys need an owner, a purpose and an expiry or review date, otherwise they outlive the project that created them.
Is disabling an account enough when someone leaves?
It is the first step. Also revoke active sessions and tokens, rotate any shared credentials they knew, and transfer ownership of their data and resources.
Sources
- NIST SP 800-53 Rev. 5, AC-2 Account Management (CSF Tools reference)
- NIST SP 800-53 Rev. 5, AC-6 Least Privilege (CSF Tools reference)
- NIST SP 800-53 Rev. 5 publication page
Last reviewed: 18 October 2026.
