Manage the Identity Life Cycle

The access a person should hold changes when they join an organization, change role inside it or separate from it, and NSA and CISA guidance names those three moments the most critical life cycle events: Join, Move, and Leave^[1]. Identity life cycle management is the process that keeps an identity's access matched to its current purpose, from the day the identity is created until the day it is removed. An identity here means the digital representation of a person, bot or service that systems recognize, usually through an account.

The ISC2 Certified in Cybersecurity (CC) exam outline^[2] lists five topics under objective 3.1: roles definition, provision, review, deprovision, and frameworks and tools. This page treats the first four as the stages of one cycle, named roles definition, provisioning, review and deprovisioning, and the fifth as the support that runs underneath all of them:

1. Roles definition decides what access a job or function needs, before anyone receives it.
2. Provisioning creates the account and grants the approved access.
3. Review checks, repeatedly, that existing access is still needed.
4. Deprovisioning removes access when the need ends.

The same outline lists the principle of least privilege, separation of duties and access control models under a separate objective, 3.2, logical access controls: that objective concerns which access is appropriate, while objective 3.1 concerns how access is created, revalidated and removed.

The join, move and leave events, which organizations also call joiner, mover and leaver events, drive the cycle: a join leads to provisioning and a leave leads to deprovisioning. Stages are also entered without a personnel event; for example, a new or changed job function starts roles definition, and a review also runs at an organization-defined frequency^[3] even when nobody has moved. A move can involve a review of the old access followed by provisioning of the new access, which the figure below draws as a loop from review back to provisioning.

Bots and service accounts are identities too

ISC2 states that just like human users, AI bots and automated service accounts must be managed through formal identity life cycle management^[2]. A service account is an account used by software, such as a scheduled job or an integration between two systems, rather than by a person signing in. It still holds permissions, so it still needs a defined role, an approved creation, periodic review and removal when the workload is retired or changes purpose. Tracking a bot only in the software asset inventory records that the software exists, but leaves its account and permissions outside anyone's access decisions.

The takeaway: identify the relevant stage or stages of the cycle first, then ask what the scenario requires.

Roles definition is the first stage of the cycle, and it decides what access a job should include before any person or bot is assigned to it.

Start from the business tasks

A role is a named collection of permissions. The US National Institute of Standards and Technology (NIST) describes role permissions as typically reflecting the permissions needed to perform defined functions within an organization^[4], and NIST Special Publication 800-53 Revision 5 (SP 800-53r5), a catalog of security and privacy controls for information systems and organizations^[3], uses the name access authorizations^[3] for the same thing. Each permission is an allowed operation on a resource, so a useful role definition lists operations, not just application names. "Access to the invoicing system" says little; viewing invoices, changing them and approving payment are three different permissions.

Business requirements decide which operations each role contains; tools then enforce whatever the definition says. Operations that conflict go into different roles, which supports separation of duties^[1] when conflicting privileges are not assigned together: in an accounts payable process, for instance, a clerk role can enter and change invoices, a separate approver role can approve payment, and both roles can view invoices.

One possible shortcut is to copy an existing employee's account as the template for a new role. That can fail because a long-serving employee's account may retain access collected across earlier jobs and projects, and copying it without review can hand unrelated permissions to the new role.

Membership needs eligibility criteria

Each SP 800-53r5 control states requirements for an organization that adopts it; the control AC-2 (Account Management) requires the organization to define prerequisites and criteria for group and role membership^[3]. Typical criteria are an assigned job function or a completed training course. A request to join a role is checked against those criteria before membership is granted, which makes membership an approved business decision rather than a matter of what the user prefers. A successful sign-in alone is not sufficient evidence of eligibility: it shows that the person controls the account, not that they are eligible for a restricted role.

Privileged roles perform restricted security-relevant functions

A privileged user is one authorized (and therefore, trusted) to perform security-relevant functions that ordinary users are not authorized to perform^[5]. NIST lists key management, account management, database administration, system and network administration, and web administration^[3] as examples of privileged roles. The test is which restricted security-relevant functions the role authorizes, not how senior its holder is: a junior administrator who creates accounts holds a privileged role, while a chief financial officer who only reads ordinary business reports does not.

The takeaway: write each role from the operations the job needs, gate membership with documented criteria, and mark a role as privileged when it authorizes security-relevant functions that ordinary users are not authorized to perform.

Before any account is created, the organization decides which kinds of account it allows at all, because each kind carries a different risk. AC-2 requires organizations to define and document the types of accounts allowed and specifically prohibited for use within the system^[3].

NIST's examples of account types include individual, shared, group, system, guest, anonymous, emergency, developer, temporary, and service^[3] accounts, and it names shared, group, emergency, anonymous, temporary and guest accounts as types an organization may choose to prohibit because of their increased risk. Each permitted type can carry its own approval and usage conditions. That a system is able to create a guest or shared account does not mean the organization permits one; the policy decides.

Individual accounts versus shared accounts

An individual account belongs to one person, so the activity recorded under it points to that person, which supports accountability. A shared account is used by several people under one account name, so the name alone cannot tell you who acted. NIST allows shared and group accounts only under organization-defined conditions^[3], and asks organizations to weigh the increased risk due to the lack of accountability before permitting them. Issuing one departmental login to speed up onboarding trades exactly that accountability for convenience.

Temporary accounts versus emergency accounts

Both types are intended for short-term use; they differ in how urgently they are activated.

	Temporary account	Emergency account
Purpose	Planned short-term work, such as a six-week contractor	A crisis that needs access immediately
Activation	Through the normal account activation procedures	Rapid activation; NIST notes it may bypass normal account authorization processes[3]
End of life	Disabled or removed when the approved period ends	Disabled or removed when the crisis is over

Because emergency activation may skip normal approval, using it for a scheduled contractor applies a crisis exception to a routine need. The contractor gets a temporary account through ordinary provisioning.

Short-term accounts should not depend on someone remembering to close them. A control enhancement is a numbered addition that strengthens a base control: SP 800-53r5 describes enhancements as statements that augment a base control^[3] and are numbered within it. AC-2 enhancement (2) has the organization automatically remove or disable temporary and emergency accounts after an organization-defined time period^[3], so removal happens on schedule rather than at the administrator's convenience. The period comes from policy and the approved need; there is no universal timer. A password-expiration reminder is not a substitute, because it asks the user to change a credential and leaves the account itself authorized.

Infrequently used accounts are a different case. NIST describes local logon accounts kept for special tasks or for when network resources are unavailable, sometimes called accounts of last resort, and states that such accounts remain available and are not subject to automatic disabling or removal dates^[3]. Automatic expiry applies to temporary and emergency accounts, not to every rarely used account.

The takeaway: the policy, not the system's capabilities, decides which account types exist, and short-term types carry an automatic end date.

Provisioning is the stage that turns an authorized access request into usable access: it establishes the accounts and entitlements (the specific permissions assigned to an account) that a person needs when joining or taking on an approved responsibility. The applicable checks must be complete before access is enabled, and the figure below shows the checks feeding the final step.

Identity proofing: who is the applicant?

Identity proofing is the processes used to collect, validate, and verify information about a subject to establish assurance in the subject's claimed identity^[6]. It includes checking the evidence itself, such as an identity document, and confirming it belongs to the person presenting it: the goal of identity verification is to provide assurance that the applicant presenting the evidence is the rightful owner of that evidence^[7]. How much evidence is enough depends on the assurance the service needs.

Proofing is easy to confuse with authentication, but they answer different questions at different times. Proofing comes first, at the registration NIST calls enrollment, when a successfully identity-proofed applicant^[8] receives an account. Authentication happens at every later sign-in and demonstrates that the claimant has possession and control of one or more valid authenticators that are bound to the subscriber's identity^[8]. An authenticator is what a person presents to sign in, something that the subscriber possesses and controls^[8] such as a password or a hardware token; the claimant is the person signing in, and the subscriber is the person the account was issued to. A newly chosen password therefore proves nothing about who the applicant is; it is an authenticator the applicant just made up.

Approval by the designated approver

AC-2 requires approvals by organization-defined personnel or roles for requests to create accounts^[3], and access is authorized based on a valid access authorization and the intended system usage. Here a role identifies the responsibility that policy names as approver (the designated approver). The administrator carries out the approved decision; neither a requester's urgency nor a colleague's endorsement replaces approval by the designated approver. Under NIST AC-2, activation of an emergency account, established in response to crisis situations^[3], may bypass normal account authorization processes; labelling an ordinary request urgent does not make it an emergency account. Requests for administrative privileges get additional scrutiny^[3] from the people responsible for approving privileged access, such as the system owner, because those privileges carry wider authority.

Access agreements signed before access

SP 800-53r5 control PS-6 (Access Agreements) has individuals sign appropriate access agreements prior to being granted access^[3]. Access agreements include nondisclosure agreements, acceptable use agreements, rules of behavior and conflict-of-interest agreements. A signed agreement sets behavioral obligations; it does not configure any permissions. The technical access is still assigned separately, in the next step.

Creating the account and assigning entitlements

When the applicable checks are complete, access is enabled with the approved group and role memberships and access authorizations, as AC-2 requires the organization to specify for each account^[3]. Creating the account and assigning its permissions are two parts of one provisioning action. The account also gets an assigned account manager: AC-2 requires the organization to assign account managers^[3], who are notified when an account is no longer required or when its user is terminated or transferred. An account that still works technically is not evidence that anyone is managing it; a named account manager establishes who is responsible.

A new hire's first account is a provisioning task, not a review task. An access review (also called recertification) checks access that already exists, so it cannot create the initial account.

For a temporary account, provisioning also sets the automatic expiry described in the account types section above.

The takeaway: perform any required identity proofing, obtain approval from the designated approver and collect any required agreements before enabling access, with exactly the approved entitlements and a named account manager.

An access review compares the accounts and permissions that exist now with the business need that exists now. AC-2 requires the organization to review accounts for compliance with account management requirements^[3] at an organization-defined frequency. The point is that an approval granted years ago does not prove the access is still needed today.

Who confirms the need

The people best placed to say whether access is still justified are usually the business owners of an application or its data, not the IT team that configured it. Identity governance tools support that arrangement: NSA and CISA guidance notes that the access inventory such a tool maintains enables application and data owners to periodically review and reconcile accounts and privileges^[1]. Whatever the tool, the reviewer works from an inventory of who holds what.

A password change is not a review. A password change replaces an authentication secret, but it does not by itself ask whether the account's permissions are still justified.

The inventory must be complete

A review is only as good as the list it reviews. CIS Control 5 (Account Management) is one of the CIS Critical Security Controls, which the Center for Internet Security (CIS) publishes as a prescriptive, prioritized, and simplified set of best practices^[9]; it covers credentials for user accounts, including administrator accounts, as well as service accounts^[10]. Accounts can also be created directly in an application or on a single system, outside the central directory (the organization's central store of user accounts, a system responsible for authenticating and authorizing users and devices^[1]), and NIST describes such local logon accounts^[3] explicitly. A review that uses a list of people as the complete inventory can miss those local accounts and the service accounts, which still need assigned account managers even though software uses them, and each one is still a way in.

Reconcile account changes with approvals

AC-2 enhancement (4) has systems automatically audit account creation, modification, enabling, disabling, and removal actions^[3]. Those records can be compared with the approved access requests. A new account with no matching approval is a discrepancy to investigate even if its name looks plausible, because an account nobody approved may be an administrator's mistake or a way for an intruder to keep access (persistence). Checking whether the account has signed in recently does not settle the question: that measures use, not whether its creation was authorized.

Inactive and user-disassociated accounts

AC-2 enhancement (3) has the organization disable accounts within a defined period when they have expired; are no longer associated with a user or individual; are in violation of organizational policy; or have been inactive^[3] for a defined period. Review both inactive accounts and accounts no longer associated with an authorized user. NIST notes that disabling them reduces the attack surface^[3]. A strong password on an account with no authorized user protects the credential but supplies no legitimate reason for the account to exist.

Not every quiet account is illegitimate. The accounts of last resort described in the account types section above are used rarely by design, so a rarely used account is evaluated against its approved account type and documented purpose before it is disabled.

Findings must change the access

A review finding that sits in a report leaves the excessive access in place. When a permission's need cannot be revalidated, it is reassigned or removed through the approved process; for privileged roles AC-2 enhancement (7) states the same rule directly: revoke access when privileged role or attribute assignments are no longer appropriate^[3].

The takeaway: review current access against current need, over a complete inventory that includes local and service accounts, and act on unjustified access and other discrepancies through the approved process.

An internal transfer, the mover event, combines two stages: the old access is reviewed and the new access is provisioned. SP 800-53r5 control PS-5 (Personnel Transfer) has the organization review and confirm ongoing operational need for current logical and physical access authorizations^[3] when someone is reassigned, and modify access to match the new need.

If a transfer is treated as add-only, so the new job's access is granted and nothing is removed, permissions pile up across successive jobs. This accumulation is called privilege creep. It can defeat separation of duties, which addresses the potential for abuse of authorized privileges^[3]: an employee who keeps a finance permission to approve invoice payments after moving to procurement, where the job is to raise purchase orders, can both order goods and approve paying for them.

NIST lists actions that a transfer may require, including closing system accounts and establishing new accounts; changing system access authorizations^[3] and providing access to official records the person handled in their previous role. AC-2 also requires that account managers be notified when users are transferred and that account management be aligned with personnel termination and transfer processes^[3], so the HR change actually reaches the people who manage the accounts. If the person still needs an old permission for a while, for example to hand over work, that continuing need is justified explicitly rather than assumed.

The takeaway: a transfer is a review of the old access followed by provisioning of the new, never an addition alone.

Deprovisioning is the stage that removes an identity's access when the need ends, and the departure itself is the trigger. SP 800-53r5 control PS-4 (Personnel Termination) requires the organization, upon termination of employment, to disable system access within an organization-defined time period^[3].

The departure triggers removal

AC-2 requires account management to be aligned with personnel termination and transfer processes^[3], so the departure date that human resources (HR) holds reaches the administrators who control the accounts. PS-4 enhancement (2) allows automated mechanisms to notify the right people and to disable access to system resources^[3] quickly. For terminations for cause, NIST notes that timely execution is essential and that organizations may consider disabling the system accounts of individuals who are being terminated prior to the individuals being notified^[3].

The periodic access review is a backstop that catches what was missed; it is not the trigger. Waiting for the next scheduled review after a known departure can leave access active until that review.

Every access path, not one account

The figure below shows one departing person and the access paths that deprovisioning has to close. Removing access starts from the person's account and privilege inventory, because one central account may not be the only way in:

• Central directory account: disable it.
• Local and cloud application accounts: disable each one. Some applications keep their own account records even when users sign in through an identity provider (the central service users sign in through); an application that accepts that sign-in is a relying party (RP), and the arrangement is called federation. When the identity provider ends a person's account, the matching accounts in connected applications must be deprovisioned too: where the relying party receives account data through a provisioning API, NIST requires the identity provider to use that API to de-provision accounts terminated at the identity provider^[11], except where restricted by relying-party data retention requirements, policies or regulation; an account also linked to another identity-provider identity (a federated identifier) may remain linked to that one.
• Credentials and hardware tokens: PS-4 requires the organization to terminate or revoke any authenticators and credentials^[3] associated with the person and to retrieve security-related property, which includes hardware authentication tokens^[3], keys, identification cards and building passes.
• Shared account passwords: AC-2 requires a process for changing shared or group account authenticators^[3] when individuals are removed from the group, so that former members do not keep access through a password they still remember. The remaining members get the new password through the established process.
• Active sessions: a session already open can keep its privileges where a system applies privilege changes only after users terminate and restart their sessions^[3].

Closing the email account alone does not establish that independent accounts and existing sessions have been disabled. Recovering the company laptop is not enough either, because the credentials that worked on that laptop may still work from another device until they are revoked. Resetting only the person's own password does nothing to a separately shared password they also knew.

Revocation and sessions already in progress

Changing the stored role assignment does not always end access immediately. NIST contrasts immediate revocation of privileges from users^[3] through dynamic privilege management with systems that require users to terminate and restart their sessions before privilege changes take effect. Where removal must be immediate, the process has to make the revocation effective for current sessions as well as for future sign-ins.

Keep the records, remove the person

PS-4 also requires the organization to retain access to organizational information and systems formerly controlled by terminated individual^[3]. Removing a person's access and disposing of business information are separate decisions: the records the person managed are transferred to someone who still needs them, and deleting them would destroy business information without being necessary to end the person's access. This is one reason an organization may disable accounts first and remove them later, once ownership of the data has been settled.

The takeaway: deprovisioning starts when a departure takes effect, on the effective date HR holds, and in a termination for cause the organization may consider disabling the system accounts^[3] before the person is notified; it does not wait for the next scheduled review, and it is complete only when every account, credential, shared secret and session has been dealt with while the organization's records stay reachable.

A framework tells an organization what identity life cycle management must cover; the organization still has to decide the specifics and do the work. SP 800-53r5 is one such control catalog; its controls are flexible and customizable and implemented as part of an organization-wide process to manage risk^[3].

The catalog makes the tailoring visible. Many AC-2 requirements contain an assignment placeholder that the organization fills in, for example the organization-defined personnel or roles^[3] who approve account creation, the frequency of account reviews, and the time period within which inactive accounts are disabled. The catalog alone does not specify who approves, how often to review or how fast to disable; the organization must supply those values in its policy and procedures. Adopting the catalog is therefore a starting point: it does not create, review or disable a single account.

Each of the four stages draws on SP 800-53r5 controls and enhancements:

Life cycle stage	Where SP 800-53r5 covers it
Roles definition	AC-2 account types, membership criteria and per-account authorizations; AC-2(7) privileged user accounts
Provisioning	AC-2 approval and creation requirements; AC-2(2) automatic expiry of temporary and emergency accounts; PS-6 access agreements; PS-5 transfer (access for the new position)
Review	AC-2 periodic account review; AC-2(3) disabling expired, inactive and no-longer-associated accounts; AC-2(4) audit of account changes; PS-5 transfer (review of current access)
Deprovisioning	AC-2 shared-authenticator change and alignment with personnel processes; AC-2(6) dynamic privilege management; PS-4 termination

Identity proofing and federation are covered by a separate NIST series, the Digital Identity Guidelines, NIST Special Publication 800-63-4 (SP 800-63-4), with identity proofing and enrollment^[7] and federation^[11] in their own volumes.

The takeaway: frameworks supply the checklist and the blanks; the organization's own procedures fill the blanks and carry out the work.

An organization with thousands of people and hundreds of applications can automate parts of the life cycle rather than create, review and remove every account by hand. The table below distinguishes each tool type's primary purpose from functions it does not guarantee on its own.

Tool type	Primary purpose	What the mechanism alone does not guarantee
Identity governance	Automates access requests, approvals, role management, reviews and reporting across join, move and leave	Credential storage or interactive authentication
SCIM provisioning	Creates, updates and removes user and group records in connected systems, serving both the provisioning stage and the deprovisioning stage	Sign users in
Federation and single sign-on	Let applications rely on one identity provider's sign-in	Complete account lifecycle synchronization
Privileged access management	Adds control and monitoring around administrator accounts	Replace provisioning and review for ordinary accounts

Identity governance

Identity governance combines policies with automation to manage who has access to what across the organization. Identity governance solutions can manage the identity and access lifecycle across join, move and leave events^[1], with role management, access reviews and reporting. A password manager has a different purpose: NIST describes password managers as apps that work by generating long, complex passwords and storing them securely^[12], and storing credentials alone does not supply the role management, access reviews and reporting of identity governance.

These tools usually start from an authoritative source of personnel data. NSA/CISA guidance describes collecting personnel data to build an identity record and automatically create accounts in directories and applications^[1] with entitlements based on that data. The automation follows the approved HR record and the configured rules; it does not decide employment status itself. A field that users can edit about themselves, such as a self-written job description, is not an authoritative trigger, because it would let unapproved data drive access.

SCIM: a standard for provisioning between systems

SCIM (System for Cross-domain Identity Management) is an application-level HTTP-based protocol for provisioning and managing identity data^[13] across domains, for example from an enterprise to a cloud service provider. It supports creating, retrieving, modifying and deleting identity resources such as users and groups, whose common format is defined in the SCIM core schema^[14]. In the names of protocols and tools, provisioning therefore covers the whole exchange of account data, removal included: a SCIM client can request resource removal^[13], so a SCIM connector serves the deprovisioning stage as well as the provisioning stage. Automated app provisioning built on such connectors can automatically deactivate accounts in the right systems when people leave^[1]. SCIM moves account data; it does not sign anyone in.

Federation and single sign-on

These two terms primarily answer how a user signs in; they do not by themselves ensure that account records stay synchronized throughout the life cycle.

• Federation lets separately administered services rely on one sign-in instead of each issuing an additional authenticator^[11]. Federation is a process that allows for the conveyance of identity and authentication information across a set of networked systems^[15]. An identity provider (IdP) creates an assertion for the subscriber and transmits the assertion to the relying party^[16], the application that relies on it. An assertion is a statement from an IdP to an RP that contains information about an authentication event^[17]. Copying a user's password into every partner service is not federation; it spreads the secret instead of relying on a verifiable assertion.
• Single sign-on (SSO) is an authentication process by which one account and its authenticators are used to access multiple applications^[18], generally implemented with a federation protocol. Using the same password on unrelated applications is password reuse, not SSO: there is no shared authentication service, only the same secret typed in many places.

SSO reduces the number of sign-ins but concentrates trust in the identity provider. NIST lists the case where a compromised IdP asserts the identity of a claimant who has not properly authenticated^[11], which can compromise relying parties that accept the assertion. Strong authentication at the identity provider and protection of the identity provider itself therefore matter more, not less.

Privileged access management

Privileged access management (PAM) focuses on accounts with administrative or similarly powerful permissions, the privileged roles defined in the roles definition section above. AC-2 enhancement (7) asks organizations to monitor privileged role or attribute assignments^[3], monitor changes to them and revoke them when no longer appropriate. PAM products add controls such as just-in-time privileged access^[1] to complete a specific task or resolve an issue. The central directory records that an administrator account exists, but it does not by itself control or watch how that elevated authority is used.

The takeaway: identity governance and SCIM manage accounts and entitlements, federation and SSO manage sign-in, and PAM adds oversight for elevated accounts.