Identity risk rarely begins with a dramatic event. More often it accumulates through ordinary changes: someone joins a team, changes jobs, covers for another role, receives temporary access, leaves the organization, or keeps a contractor account longer than anyone remembers. Each change may be reasonable by itself. The defensive problem is drift over time.
This guide fills the practical space between IAM Roles and Least Privilege and Privileged Access Reviews . Least privilege explains why access should be limited. Privileged review explains how elevated rights deserve attention. Lifecycle review asks whether access still matches the person’s current relationship to the organization.
Why lifecycle evidence matters
An access review is weaker when it only asks whether an account exists. The better question is whether the account still belongs to a current person, role, service, or business process. A current employee may have old permissions from a previous role. A former employee may be disabled in the central directory but still present in a SaaS application. A contractor may have a valid end date in one system and no end date in another. A service identity may be owned by a team that no longer operates the application.
Offboarding is especially sensitive because it crosses people, process, and technology. It should not become a hunt for blame. A calm review asks what the authoritative source says, when the change was approved, which systems are downstream, which access paths remain active, and how exceptions are documented. That framing keeps the work practical.
Lifecycle review also protects response teams. During an incident, stale access creates confusing evidence. A sign-in by a former contractor, a dormant shared mailbox, or an old administrator group can slow triage because responders have to reconstruct the identity story under pressure. Good lifecycle hygiene makes later Authentication Log Patterns easier to interpret.
Defensive mental model
Think of identity lifecycle as a chain of state changes. The first state is creation: why does the identity exist, who requested it, who approved it, and what initial access was granted? The second state is movement: what changes when the person’s job, project, location, employment relationship, or device set changes? The third state is removal or suspension: what access should be disabled, transferred, archived, or retained for business reasons?
The evidence should connect each state to an owner. Human resources, IT, security, application owners, and managers may each hold part of the record. A lifecycle review does not need to collapse all of those systems into one perfect database before it can improve risk. It can start by naming the authoritative source for employment status, the source for directory status, the source for application roles, and the source for privileged exceptions.
The same model applies to non-human identities, but the owner is usually a team, application, or automation process. The Service Accounts and Secrets guide covers rotation and blast radius. Lifecycle review adds a basic ownership question: is this identity still required for a current system, and who can prove that?
What evidence matters?
Strong lifecycle evidence has a timestamp, a source, an owner, and a decision. A ticket that says access was approved for a project is useful. A group membership export is useful. A manager confirmation is useful. A directory disabled date is useful. None of those records is complete alone. Together they can show whether access still fits the current role.
Pay attention to exceptions. Some accounts remain active for legal hold, payroll, customer support continuity, audit, or application ownership transfer. Those exceptions may be legitimate, but they should be named. An unnamed exception is just drift with a hopeful explanation attached.
Privileged access deserves a separate layer of care. A user moving out of an engineering role may not need repository administration. A finance approver may not need broad file-sharing rights after changing teams. A support contractor may not need production access after the contract ends. The evidence question is not whether the person is trusted. It is whether the permission still matches the job and whether the approval is current.
Toy example
Imagine a fictional software studio with a designer who moved into product management six months ago. The central directory shows the correct title. The project tracker shows the new team. A cloud folder still grants design-admin access, and a SaaS tool still lists the person as a workspace owner. No one assumes misconduct. The defender writes a narrow claim: two applications may not reflect the current role.
The next step is owner confirmation. The design lead confirms that the old access is no longer required. The product lead confirms the current access required for the new job. The application owner removes the stale rights and records the decision. The value of the exercise is not that a breach was found. It is that identity state became clearer before an incident made it urgent.
Common mistakes and false positives
A common mistake is treating employment status as the whole identity story. Central directory status matters, but many applications, shared workspaces, support portals, and data tools have their own role models. Another mistake is removing access without checking ownership or business continuity. Fast cleanup can break workflows when an exception is legitimate but undocumented.
False positives often come from naming differences. A person’s legal name, preferred name, email alias, contractor identifier, and application username may not match cleanly. Before declaring an orphaned account, compare source systems carefully and ask the owner. The goal is to reduce risk without creating avoidable outages or accusing people based on incomplete records.
What to do next
Start with a small, high-value slice. Review privileged groups, terminated-user accounts, dormant administrators, contractor end dates, or one sensitive SaaS application. Write down the source of truth, the access source, the owner, the decision, and the follow-up date. Then repeat the pattern instead of trying to fix the entire identity estate in one pass.
When lifecycle drift affects sensitive data, privileged administration, customer systems, or incident response, escalate through approved channels. When it is routine cleanup, create a record that explains what changed and why. The best outcome is an access trail that a future defender can trust.
How this guide was made
This page was written as defensive education for access governance and identity cleanup. It avoids legal and employment advice, and it focuses on observable records, ownership, and proportionate security review.
Official references
For orientation, compare this topic with the NIST Digital Identity Guidelines , CIS Critical Security Controls v8 , and the NIST Cybersecurity Framework 2.0 . These references reinforce identity governance, access control, accountability, and recovery from drift.
Related guidebooks
This guide pairs with IAM Roles and Least Privilege , Privileged Access Reviews , Service Accounts and Secrets , and SaaS Admin Change Logging .
