identity lifecycle

Identity Lifecycle

The identity lifecycle is the complete path an identity follows from creation to removal. It includes requesting access, approving access, provisioning accounts, changing permissions, reviewing entitlements, disabling access, revoking sessions and tokens, transferring ownership, archiving records, and keeping evidence that those steps happened.

This article is part of the Identity & Access Control pillar. It builds on the AAA model and connects to Password Policy and Password Managers, SSO and Federation, Authorization Models, Access Reviews, Account Recovery and Help Desk Security, and Identity Monitoring and Attack Detection.

The identity lifecycle matters because many access failures are ordinary drift rather than exotic attacks. People keep access after changing jobs. Contractors are not removed. Test accounts become permanent. Emergency access is never reviewed. Service owners leave. Groups accumulate privileges. SaaS accounts sit outside central provisioning. Nobody can explain why an account still exists.

In plain terms

An identity should have a beginning, a current reason to exist, and a clean ending. Joiners receive only the access they need to start. Movers have access recalculated when their job changes. Leavers lose real access, not just the most visible account. The lifecycle is how an organization keeps trust current over time.

Key takeaways

• Identity lifecycle covers creation, provisioning, use, change, review, suspension, deprovisioning, retention, and evidence.
• Joiner-mover-leaver is the simplest operating model, but the mover step is often where access accumulates.
• Every identity should have a source of truth, owner, purpose, access baseline, review cadence, and removal path.
• Provisioning automation helps only when the access model is correct; bad automation spreads bad access quickly.
• Deprovisioning must remove actual access surfaces: sessions, tokens, SaaS accounts, local accounts, keys, shared secrets, and ownership records.
• Stale, orphaned, dormant, shared, service, guest, and privileged accounts need lifecycle controls, not exceptions from lifecycle controls.
• Evidence should show who requested access, who approved it, what changed, when it changed, why it changed, and when it was removed.

Lifecycle scope

An identity lifecycle program answers a practical question: how do we keep access aligned with real need over time? The answer applies to more than employees. It includes contractors, vendors, guests, partners, customers, administrators, help desk operators, service accounts, workloads, devices, API clients, temporary test users, and emergency accounts.

Creation is the easy part. The hard part is keeping the account accurate as reality changes. A healthy lifecycle can explain why the identity exists today, who owns it, which source of truth says it should exist, what access it should have, what access it actually has, how exceptions are approved, when access will be reviewed, and how access will end.

Good lifecycle management prevents two extremes: chaotic manual access that nobody can explain, and rigid workflows that slow work so much that teams create bypasses.

Joiner, mover, leaver

Joiner-mover-leaver is the beginner-friendly model for lifecycle management. A joiner enters the environment and receives an identity plus initial access. A mover changes role, team, location, project, manager, risk profile, or responsibility and needs access recalculated. A leaver exits the organization, project, vendor relationship, system ownership, or workload purpose and needs access removed.

Joiner failures usually come from overbroad birthright access, copied access from another user, contractor accounts treated like employee accounts, vendor accounts without end dates, accounts created before the person or relationship is verified, or missing manager ownership. The early mistake becomes the baseline for every later decision.

Mover failures are often more dangerous because they are quieter. Someone moves from support to product operations and gains deployment dashboard access while retaining customer impersonation rights. A finance analyst joins a temporary audit project and keeps export rights after the project ends. A system administrator moves to a product role but keeps emergency admin privileges. The safest mover process is not "add new access." It is "recalculate access."

Leaver failures happen when offboarding removes the central account but misses the real access surface. SaaS accounts, local server accounts, SSH keys, refresh tokens, personal access tokens, shared credentials, mobile sessions, repository access, mailbox rules, managed devices, and service ownership can all survive a directory disable if the process does not look for them.

Source of truth and ownership

Lifecycle management needs authoritative context. For workforce identities, the source of truth is often the HR system. For contractors and vendors, it may be a vendor management system, procurement record, project owner, or contract record. For customers, it may be the customer application, customer identity system, or CRM. For service accounts and workloads, it may be a service catalog, cloud inventory, repository ownership file, infrastructure-as-code system, or asset inventory.

The identity provider and directory should not become the only record of why access exists. They can show that a user is in a group, but they may not explain whether the access is still needed, which business owner approved it, which contract supports it, or when it should end.

Every identity and entitlement should have an owner. A workforce user usually maps to a manager. An application role maps to an application owner. Data access maps to a data owner. A service account maps to a service owner. Emergency access maps to a privileged access owner. Shared accounts, when they cannot be eliminated immediately, need stricter ownership because normal attribution is weaker. No owner usually means no accountability.

Identity proofing and account creation

Before an organization grants access, it should know whether the subject is the right person or entity for the account. The depth of identity proofing depends on risk. A public newsletter account needs little proof. A customer banking account, employee payroll access, government service, privileged administrator account, or contractor with production access needs stronger assurance.

For workforce identities, account creation usually depends on HR or vendor onboarding. For customer-facing applications, proofing may involve email verification, phone verification, document checks, in-person proofing, or third-party identity verification depending on the service. NIST Digital Identity Guidelines describe formal identity proofing and authenticator assurance concepts for systems that need assurance levels.

Account creation should come from an authoritative event, assign a unique non-reused identifier, record manager or owner, capture employment or identity type, set start date and known end date, separate employee, contractor, vendor, guest, customer, admin, and service identities, require stronger approval for privileged access, and record who requested and approved the account. Reusing old usernames can create audit confusion; even when a display name is reused, the underlying identifier should distinguish the old identity from the new one.

Birthright access and provisioning

Birthright access is the baseline access a new identity receives automatically. It may include corporate email, HR self-service, security awareness training, device management, password manager enrollment, and basic collaboration tools. It should be small, clear, documented, tested, and reviewed. It should not quietly grow into production systems, privileged tools, broad file shares, customer data, payroll, source code, or exports.

Provisioning is the process that creates accounts and assigns access. It can be manual, automated, or hybrid. Manual provisioning may use tickets, approvals, and administrator action. Automated provisioning may use HR events, identity provider rules, groups, application assignments, and downstream connectors. Hybrid provisioning often automates low-risk baseline access while requiring explicit approval for sensitive roles.

SCIM, the System for Cross-domain Identity Management, is a common standard for provisioning users and groups across systems. It helps identity providers create, update, disable, and remove identities in connected applications without a custom integration for every application.

Provisioning should be deterministic. If two users have the same role, location, and employment type, their baseline access should be explainable. If exceptions exist, they should have owners, approvals, reasons, duration, and review dates.

Requests and approvals

Not all access should be automatic. Higher-risk access needs request context and approval quality. A useful request identifies the requester, target identity, system, role or entitlement, business justification, duration, sensitivity, prerequisites, manager decision, application owner decision, and security review where needed.

Approvals should come from people who understand the risk. A manager may know that a person is assigned to a project. A system owner may know what a role permits. A data owner may know whether a dataset is sensitive. Security may know whether the request conflicts with policy or needs compensating controls.

Approval quality matters. If approvers see only "grant access to FinanceApp" with no role detail, they cannot make a meaningful decision. If every request is approved automatically because the workflow is too slow, the approval step becomes theater.

Deprovisioning by access surface

Deprovisioning removes or disables access when it is no longer needed. It should cover more than the main identity provider account. Planned departures may follow a scheduled process; involuntary departures, compromised accounts, insider-risk cases, and privileged administrator departures often require immediate disabling and coordinated containment.

The process should ask what access surfaces still exist. There may be identity provider sessions, refresh tokens, application assignments, directory groups, SaaS accounts, local accounts, VPN and remote access, privileged roles, API tokens, personal access tokens, SSH keys, shared secrets, managed devices, mailbox rules, repository access, dashboards, alerts, service accounts, and file ownership. Some access must be disabled. Some ownership must be transferred. Some secrets must rotate. Some records must be retained.

Deprovisioning should be tested. It is common to discover that central disablement works while a critical SaaS tool, legacy system, shared local account, cloud key, or personal access token remains active.

Stale, orphaned, and non-human identities

Stale accounts still exist without a current reason to be active. Orphaned accounts lack a clear owner. Dormant accounts may be unused, though not every dormant account is automatically bad. Emergency accounts should be rarely used, and service accounts may run scheduled jobs. The point is not to delete blindly; it is to know why the identity exists, who owns it, and how it is controlled.

Common problem areas include departed employees, expired contractors, old test accounts, migration leftovers, local server accounts, emergency accounts, shared accounts, SaaS accounts outside SSO, personal access tokens, old API clients, and accounts from deleted teams or projects. These accounts are attractive because they often have old credentials, weak MFA, broad privileges, poor monitoring, and unclear accountability.

Service and workload identities need the same lifecycle discipline. They need a clear owner, purpose, system or workload association, least privilege, credential rotation plan, review cadence, monitoring, expiration or renewal process where possible, and a decommissioning plan. They become risky when the application owner changes teams, the project ends, or the credential keeps working after everyone forgets why it exists.

Privileged lifecycle

Privileged identities need stricter controls because their compromise can change systems, disable logging, reset credentials, read sensitive data, or create persistence. Domain administrators, cloud administrators, database administrators, production support accounts, CI/CD administrators, security tool administrators, backup administrators, help desk reset operators, and break-glass accounts should not follow the same lifecycle cadence as low-risk baseline access.

The lifecycle of privileged access should often be shorter than the lifecycle of the user. A person may remain employed for years, while production admin access may be needed for two hours. Stronger MFA, separate admin accounts, approval for elevation, just-in-time access, expiration on assignments, privileged session monitoring, frequent review, immediate removal after role change, and tested break-glass procedures are all part of privileged lifecycle management.

Evidence and metrics

Identity lifecycle controls need evidence because access decisions are often challenged later by audits, incidents, and reviews. Useful evidence includes the source onboarding event, account creation time, request ticket, approver, business justification, assigned groups and roles, privileged approval, start and end dates, mover event, access review result, deprovisioning time, session revocation, token revocation, exception, expiration date, and owner change.

The best evidence is generated as part of the workflow. Screenshots and ad hoc spreadsheets are fragile. Identity governance records, tickets, directory logs, provisioning events, application audit logs, and access review decisions are easier to search and defend.

Metrics should reveal whether the process works. Time from hire event to baseline access matters, but fastest provisioning is not good if access is overbroad. Time from termination event to account disablement matters, but disablement alone is incomplete if tokens remain. Useful lifecycle metrics include accounts with owners, contractor accounts with end dates, dormant accounts, orphaned accounts, privileged assignments with expiration, overdue reviews, manual accounts, apps not integrated with SSO or provisioning, and time to remove access after role change.

Walkthrough: role change access drift

A support engineer moves into product operations. The new role needs deployment dashboard access, but the old role had customer impersonation permission for troubleshooting. A weak process adds the dashboard group and leaves old support groups untouched. Six months later, the account has both product operations access and customer impersonation.

The safer process treats the HR or identity attribute change as a recalculation trigger. Old role baseline access is removed. New role baseline access is assigned. Any exception needs owner approval and an expiration date. The change is logged and appears in the next access review. Mover controls prevent privilege accumulation.

Walkthrough: contractor offboarding gap

A contractor finishes a cloud migration project. The central directory account is disabled, but the contractor also had a local admin account on a migration host and a personal access token in a code repository. The disabled central account creates a false sense of completion while old access can still work.

The stronger process tracks contractor access by project, requires end dates, uses SSO and provisioning where possible, inventories local accounts and tokens, revokes personal access tokens, removes repository access, rotates shared project secrets, and confirms deprovisioning in evidence records. Offboarding should remove actual access, not just the most visible account.

Walkthrough: orphaned service account

A scheduled integration exports data from one SaaS platform to another. The engineer who created it leaves. The service account remains active with broad API permissions, but no owner reviews the access, no one knows whether the activity is expected, and the credential may never rotate.

The lifecycle fix is ownership. Register the service account, assign an application owner, store credentials in a managed secret store, reduce permissions, monitor use, review periodically, and decommission the account when the integration ends. Non-human identities need lifecycle management because they do not leave through HR.

Practice Exercise: Handle Joiner-Mover-Leaver Events

You are reviewing lifecycle tickets from the identity queue. For each event, identify the lifecycle risk and the control action that should happen before the ticket is closed.

Scenario

The queue contains these events:

Expected Answer

Explanation

Lifecycle control is strongest when it follows the actual access surface. Joiners need bounded baseline access, movers need recalculation rather than accumulation, leavers need real revocation across sessions and downstream systems, and non-human identities need owners even though they do not pass through HR.

Common pitfalls and misconceptions

"Copy Alice's access"

Copying access from another user is fast, but it copies hidden mistakes: temporary access, old role access, privileged exceptions, and inherited group sprawl. Role baselines and deliberate exceptions are safer.

"Mover means add access"

Mover events should recalculate access. Adding new access without removing old access creates privilege accumulation and makes later reviews harder.

"Offboarding means disable the main account"

Directory disablement is necessary, but not sufficient. Sessions, refresh tokens, SaaS accounts, local accounts, SSH keys, API tokens, shared credentials, devices, and ownership transfer may remain.

"Automation fixes lifecycle"

Automation makes good models scale, but it also spreads bad models quickly. Automate standard low-risk access and deprovisioning, but keep approval, justification, expiration, and review for high-risk access.

"Service accounts are outside JML"

Service accounts do not join or leave through HR, but they still have a beginning, owner, purpose, review cadence, credential lifecycle, and end condition.

How identity lifecycle connects to the rest of the pillar

Identity lifecycle is the foundation for the rest of identity and access control. Authentication factors and MFA prove that the right subject is using the identity. Password policy and password managers reduce credential weakness. Authorization models decide what access means. Privileged access management tightens high-impact permissions. SSO and federation centralize login and trust. Directory services and groups store many lifecycle decisions. Service and workload identity extends lifecycle thinking to non-human identities. Credential storage and rotation protects secrets tied to identities. Access reviews check whether lifecycle decisions are still correct. Account recovery prevents attackers from bypassing the lifecycle through support channels. Identity monitoring detects abuse when lifecycle controls fail or are bypassed.

A strong lifecycle does not make every identity safe by itself. It gives every later control a cleaner, more accountable foundation.

Authoritative references

• NIST SP 800-53 Rev. 5 Update 1 includes account management, access enforcement, least privilege, audit, identification, and authentication controls.
• NIST Cybersecurity Framework 2.0 provides a risk-management structure covering identity, access, asset management, governance, detection, and response outcomes.
• NIST SP 800-63A-4 covers identity proofing and enrollment concepts for systems that need formal assurance.
• NIST SP 800-63B-4 covers authenticator and lifecycle guidance for digital identity systems.
• RFC 7643 and RFC 7644 define SCIM schema and protocol for cross-domain identity provisioning.
• CIS Controls v8.1 Navigator includes account management and access control management safeguards.
• Microsoft Entra identity lifecycle governance explains joiner, mover, and leaver lifecycle management concepts in Entra governance.

FAQ

What is the identity lifecycle in simple terms?

It is the full process for managing an identity from creation to removal. It covers who gets an account, what access they receive, how access changes, how it is reviewed, and how it is removed when no longer needed.

Why are mover events so risky?

Mover events often add new access without removing old access. Over time, a user can accumulate permissions from previous jobs, projects, temporary assignments, and emergency work. That makes account compromise more damaging.

Is disabling the identity provider account enough for offboarding?

Not always. Teams also need to consider active sessions, refresh tokens, SaaS accounts, local accounts, SSH keys, API tokens, shared credentials, devices, and ownership transfer for files or services.

Should all access be automated?

No. Automation is useful for standard low-risk access and deprovisioning, but high-risk access often needs explicit approval, justification, expiration, and review. Automating a bad access model spreads mistakes faster.

How often should access be reviewed?

It depends on risk. Privileged access, sensitive data, contractors, vendors, and high-impact systems should be reviewed more often than low-risk baseline access. Reviews should also be triggered by role changes, incidents, and project endings.

Who owns identity lifecycle management?

It is shared. HR or vendor management provides lifecycle events. IT and identity teams operate systems. Managers and application owners approve need. Security defines risk controls. System and data owners confirm whether access is appropriate.