Category: Identity Lifecycle

Account Lifecycle

Also known as: User Account Lifecycle, Account Lifecycle Management

Simply put

Account lifecycle refers to all the stages an account passes through, from when it is first created, through its ongoing use and periodic review, to when it is eventually deactivated or removed. Managing this lifecycle means keeping each account accurate and appropriate at every stage, whether the account belongs to a person or to a machine such as an application. The goal is to ensure accounts exist only when needed and carry only the access they should.

Formal definition

Account lifecycle describes the collective set of governance and administration processes by which an account is managed across its stages, typically including creation/provisioning, review and update, and eventual deactivation or retirement. In IAM contexts it is generally treated as part of Identity Governance and Administration (IGA) rather than runtime access enforcement, and it applies to both human user accounts and non-human identities such as service accounts, where the latter often add stages like credential rotation. The specific stages, terminology, and automation vary by vendor and deployment; for example, IBM Security Verify frames account lifecycle as an Identity Governance process for managing accounts on target systems, while service account lifecycle definitions typically emphasize creation, use, review, rotation, and retirement. The scope of this term covers lifecycle stage management and is distinct from real-time authentication, authorization, or token validation.

Why it matters

Accounts that outlive their legitimate purpose are one of the most common sources of standing risk in an identity environment. When an account is created but never reviewed, retains access after a role change, or is left active after a person leaves or an application is decommissioned, it becomes an attractive target and a gap in accountability. Treating the account as something with a defined lifecycle, rather than a one-time creation event, lets organizations ensure accounts exist only when needed and carry only the access they should, which is the core governance objective this term addresses.

The lifecycle framing applies to more than human users. Non-human identities such as service accounts that support applications or infrastructure follow their own stages, typically adding credential rotation to the usual creation, use, review, and retirement steps. Because these accounts often hold broad privileges and are easy to forget, neglecting their lifecycle can leave rotated-but-never-retired credentials or dormant service accounts in place indefinitely.

It is worth being precise about scope: account lifecycle is an Identity Governance and Administration concern focused on managing accounts across their stages. It is distinct from the runtime enforcement that happens at authentication, authorization, or token validation time. Sound lifecycle management reduces the population of accounts and entitlements that those runtime controls must contend with, but it does not replace them.

Who it's relevant to

Identity Governance Leads

Own the definition of lifecycle stages, review cadences, and retirement processes. Account lifecycle is squarely an IGA concern, so these teams are responsible for ensuring accounts remain accurate and appropriate from creation through deactivation, and for confirming that reviews actually result in updates or removals rather than rubber-stamping.

IAM Engineers and System Administrators

Implement provisioning, review, and deprovisioning workflows on target systems, for example, managing account lifecycle from a platform such as IBM Security Verify. They also handle the operational specifics for non-human identities, including credential rotation for service accounts as part of the use and review stages.

Security Architects

Design where lifecycle governance sits relative to runtime enforcement, keeping account stage management distinct from authentication, authorization, and token validation. They ensure that reducing dormant and over-privileged accounts through lifecycle processes complements, rather than substitutes for, real-time access controls.

Compliance Officers

Rely on documented lifecycle processes, creation, review, and retirement, to demonstrate that access is granted, maintained, and removed appropriately. Evidence of periodic review and timely deactivation supports audit requirements around account accountability and access appropriateness.

Inside Account Lifecycle

Joiner (Provisioning)

The onboarding phase where an identity is created and initial access is granted, typically driven by an authoritative source such as an HR system. In most deployments this includes account creation across target systems, often via SCIM provisioning or directory writes, and assignment of birthright access based on attributes or roles.

Mover (Change Management)

The phase handling changes to an existing identity, such as a role change, department transfer, or promotion. Depending on configuration, this triggers re-evaluation of entitlements, revocation of no-longer-needed access, and granting of new access, and is a common point where excess privilege accumulates if changes only add rather than remove.

Leaver (Deprovisioning)

The offboarding phase where access is revoked and accounts are disabled or deleted when an identity leaves the organization. Timely deprovisioning reduces orphaned accounts and standing risk; in most deployments this is coordinated from an authoritative source signaling termination.

Authoritative Source

The system of record (frequently HR, or a contractor/partner directory) that drives lifecycle events. Account Lifecycle management typically depends on reliable event feeds from this source to trigger joiner, mover, and leaver actions.

Provisioning and Deprovisioning Mechanisms

The technical means of applying lifecycle changes to target systems, such as SCIM for cross-system provisioning or writes to LDAP directories. These are IGA administration functions and are distinct from runtime access enforcement.

Access Reviews and Certification

Periodic or event-driven attestation that existing access remains appropriate across the lifecycle. This is an identity governance concern (IGA) supporting segregation of duties and least privilege, separate from real-time token validation or policy enforcement.

Orphaned and Dormant Account Handling

Detection and remediation of accounts no longer tied to an active identity or unused for a period. Managing these is part of reducing standing access risk within the lifecycle.

Common questions

Answers to the questions practitioners most commonly ask about Account Lifecycle.

Is account lifecycle management the same as authentication?

No. Account lifecycle management is an identity governance and administration (IGA) concern covering how an account is created, changed, and removed over time (joiner-mover-leaver processes, provisioning, and deprovisioning). Authentication is a separate runtime step that verifies who a principal is at the moment of access. Lifecycle management establishes and maintains the account and its entitlements; it does not, by itself, verify a user's identity during a login event.

Does deprovisioning an account immediately revoke all of a user's active access?

Not necessarily. Deprovisioning is a lifecycle action that removes or disables an account and its entitlements, but its effect on already-issued credentials and tokens depends on configuration. Self-contained tokens such as signed JWTs may remain valid until expiry unless the deployment enforces revocation checks, short lifetimes, or session termination at the enforcement point. In most deployments, effective revocation requires coordinating lifecycle changes with runtime enforcement rather than relying on account disablement alone.

How are account lifecycle transitions typically triggered?

In most deployments, lifecycle transitions are driven by an authoritative source of record, commonly an HR system for workforce identities, that signals joiner, mover, and leaver events. These events are propagated to downstream systems, often via provisioning connectors or SCIM, to create, update, or deactivate accounts. The specific triggers, sources, and propagation mechanisms vary by vendor and deployment context.

What role does SCIM play in the account lifecycle?

SCIM is a provisioning protocol commonly used to synchronize account creation, updates, and deactivation between an identity provider or IGA system and downstream applications. It addresses the administration side of the lifecycle by propagating account state and attribute changes. SCIM handles provisioning operations and is distinct from runtime authentication and authorization; the extent of its support varies by application.

How do access reviews and certifications relate to the account lifecycle?

Access reviews and certifications are governance controls that periodically validate whether existing accounts and entitlements remain appropriate, particularly after mover events that can leave residual access. They typically complement automated lifecycle transitions by catching accumulated or orphaned access that joiner-mover-leaver automation alone may miss. These are IGA activities and are separate from real-time enforcement decisions.

How should mover events be handled to avoid excess accumulated access?

Mover events, where a user changes roles or departments, are a common source of privilege accumulation because prior entitlements are not always removed when new ones are granted. In many deployments, this is addressed by recalculating entitlements against the new role or attributes rather than only adding access, and by supplementing automation with periodic access reviews. The exact approach depends on the access model in use and the governance tooling configured.

Common misconceptions

Account Lifecycle management is the same as authentication or runtime access enforcement.

Account Lifecycle is an identity governance and administration (IGA) concern focused on provisioning, changes, certification, and deprovisioning of identities and entitlements. It is distinct from runtime enforcement components such as a PDP, PEP, or PIP and from authentication, which verifies who a principal is at access time.

Disabling or deleting an account fully deprovisions all access.

Depending on configuration and the number of connected systems, access can persist in systems not fed by the deprovisioning process, leaving orphaned entitlements. Comprehensive deprovisioning typically requires coordinated action across all target systems, not just the primary directory.

The mover phase only needs to grant the new access a person requires.

Effective mover handling should also revoke access that is no longer needed. In most deployments, adding without removing leads to privilege accumulation over time, undermining least privilege and segregation of duties.

Best practices

Drive lifecycle events from an authoritative source (such as HR) so that joiner, mover, and leaver actions are triggered consistently rather than through manual, ad hoc requests.

Automate provisioning and deprovisioning across target systems where feasible, using standards such as SCIM, to reduce delays and orphaned accounts.

Ensure the mover process both grants new access and revokes access that is no longer needed to prevent privilege accumulation.

Prioritize timely deprovisioning on termination to minimize standing access, and reconcile regularly to detect orphaned or dormant accounts.

Conduct periodic and event-driven access reviews and certifications to keep entitlements aligned with least privilege and segregation of duties.

Keep lifecycle (IGA) processes clearly separated from, but coordinated with, runtime enforcement so that governance changes are reflected in what enforcement points ultimately allow.