Identity Lifecycle

The identity lifecycle covers creation, changes to authority and credentials, and retirement when the identity is no longer needed. It applies to human accounts and software principals. Kubernetes service accounts illustrate the latter: they identify non-human clients, not the people who created them. Record both the authenticated subject and the separate accountable owner.

Each stage needs a source of authority, an owner, and completion evidence. Creation may have an immediate requester, while removal depends on departure, task completion, or another lifecycle event. Define those deadlines explicitly rather than assuming that only onboarding can have one.

The stages, for both kinds of subject

Stage	For a person	For a workload	Where it leaks
Creation	An account is provisioned from a hiring or contracting event, with an initial set of grants	A deployment or platform request creates a software principal, records its accountable owner and purpose, and issues appropriate credentials	Initial grants copied from a colleague or a template, so the starting set is already wider than the work
Change	Team moves, promotions, project work, temporary cover	New integrations, new data stores, a migration that needs one extra permission	A change adds access but omits review of grants no longer needed; require evidence for both additions and removals
Credential maintenance	Authenticator binding, replacement, loss and compromise reporting	Key or certificate rotation, renewal of short-lived tokens	Rotation deferred because the consumer list is unknown, which turns a rotation into an outage risk
Removal	Departure, contract end, or the end of the project the access was for	Retire an identity whose purpose ended; transfer ownership and review credentials and grants when a continuing service outlives its creator	The responsible team has no complete inventory or evidence that the intended removal or transfer finished

Permissions can accumulate when a change process adds the new access without reviewing the old. Give removals explicit triggers and owners, using team moves, contract dates, project completion, and service retirement as inputs. Periodic review can detect changes those events missed. The appropriate action may be removal, reduced scope, time-limited elevation, or retention with a recorded justification.

Connect authoritative lifecycle decisions to enforcement

An identity platform needs authoritative information about hiring, team moves, contract dates, and service use. Those inputs may come from HR records, tickets, deployment definitions, or other systems. RFC 7642 separates SCIM provisioning and de-provisioning from authentication as functions. The functions can exist in the same product; the design still needs to state which source decides eligibility and how its decisions reach enforcement.

For each transition, identify the source, owner, consumer, and expected result. Monitor queue age and failures, implement safe retries, and verify that the destination applied the change. Reconcile intended eligibility against actual accounts and grants so a missed event is discoverable. Successful message delivery is useful evidence but does not by itself prove access ended across sessions and other credentials.

Ending an identity is more than deleting a row

NIST SP 800-63B-4 defines invalidation as removing the binding between an authenticator and a subscriber account. It requires prompt action when the account ceases to exist, the subscriber requests invalidation, compromise occurs, or eligibility ends, with a risk-based check of subscriber requests. It also recommends time limits for handling compromised authenticators. Distinguish those requirements from the broader task of ending every applicable access path.

The same guidance notes that leaving a compromised authenticator valid can be more harmful than invalidating it in error. Define response authority, evidence expectations, and recovery procedures before incidents so responders can act promptly within an agreed scope.

Removing the binding is still not the same as stopping access. Sessions, cached decisions, issued tokens, and separate credentials held by background jobs each have their own path and their own delay, which is the subject of access revocation. A lifecycle that ends at the account record ends one step early.

Orphaned identities

Treat an identity as orphaned when it lacks a valid accountable owner or a justified link to continuing work. Separately assess whether its credentials authenticate, its grants permit sensitive operations, or someone can renew credentials or reactivate it. An expired or inactive account can still need cleanup; it does not become well governed merely because no current request appears in the logs.

Record an accountable owner, purpose, review date, and expiry or retirement policy in maintained records connected to the identity. Combine registered-account inventories with observed use, grant data, and credential-issuance authority. Logs alone miss dormant identities and collection gaps. Repeat reconciliation as the estate changes, and record whether each questionable identity was retired, restricted, or transferred to a responsible team.

Four measurements

• Measure from the relevant lifecycle event to denial on each access path being retired, including credentials and sessions. State coverage, test timing, and intended bounds. NIST’s authenticator-invalidation requirement is one part of this broader operational measure, not a universal numerical offboarding deadline.
• Count identities without a valid recorded owner, separating humans and software principals and checking whether recorded owners are still responsible. Compare inventories with usage evidence and mark unknown coverage.
• Credential age against the intended rotation period, as a distribution rather than an average, because the tail is where the two-year-old key sits.
• Compare grants added and removed with changes in workforce, workloads, and required scope. Low removal counts are a prompt to investigate, not proof of excessive access. Record whether remaining grants are still justified and identify changes that should have triggered removal.

How these stages connect to permission models and to the paths a revocation has to reach is worked through in The Account Was Disabled on Friday.

References

• NIST SP 800-63B-4, Digital Identity Guidelines: Authentication and Authenticator Management (2025), Sections 4.3 and 4.5.
• RFC 7642, System for Cross-domain Identity Management: Definitions, Overview, Concepts, and Requirements (2015), Section 1.
• Kubernetes documentation, Service Accounts