Identity Life Cycle Management: Provisioning, Review, and Deprovisioning

Identity life cycle management is the discipline of controlling every stage of an identity's existence so that every account has an owner, every access right has a reason, and nothing is left behind when a person moves on. Every identity follows a predictable path: it is designed, created, used, reviewed, and eventually removed.

The ISC2 CC exam outline breaks the cycle into four activities, in this order:

1. Roles definition decides what access a job function needs before any account exists.
2. Provisioning verifies the person, creates the identity and grants that predefined access when the person joins.
3. Review periodically confirms that the access a person holds still matches the job they do today.
4. Deprovisioning disables or removes access when the person leaves or no longer needs it.

The order is not a one-way line; it is a loop. What reviews find feeds back into roles definition. If every reviewer of a role keeps revoking the same unneeded entitlement from every holder, the problem is not the people, it is the role profile, and the fix is to correct the role definition so new joiners stop receiving that access in the first place.

The reason this matters is simple: most access-related security failures are life cycle failures. An attacker who compromises a forgotten account belonging to a departed contractor does not need to defeat any technical control, because the organization defeated itself by skipping deprovisioning. Likewise, an employee who has changed jobs three times without a review may hold far more access than any single role requires, turning one compromised credential into a much larger breach.

Roles definition is the design stage of the life cycle: before anyone is placed in a position, the organization defines what that position needs, which systems, which applications, which data, and at what level of permission. The output is a documented role, such as accounts payable clerk or help desk technician, with a standard access profile attached.

Defining roles first enforces the principle of least privilege at the moment access is designed rather than after the fact. If the role only needs to read customer records, the role definition grants read access and nothing more. When a new person later fills that role, they inherit exactly the predefined profile, so there is no ad hoc guessing about what to grant.

Roles definition is a shared responsibility. Managers and data owners understand what the job actually requires, human resources knows the job descriptions, and the security team validates that the resulting profile follows least privilege and does not combine duties that should stay separated.

That validation is a preventive control, so its findings are fixed at the design stage. If a draft role would let one person both create a vendor and approve payments to it, the role is split into two roles before anyone is provisioned. The general rule: a conflict found at design is fixed in the design. Detective controls added later can only report misuse after it has happened; they never remove the conflict itself. Separation of duties as a principle is covered in the logical access controls lesson; here the point is when the conflict is fixed: in the role, before provisioning.

Provisioning is the act of verifying a person, creating their identity and granting it the access their role defines. It begins with an authorized request, usually triggered by human resources when a new hire starts or when an existing employee takes on a new role.

Identity proofing comes before any credential

Identity proofing is the check, made before an account or a replacement credential is issued, that the person really is who they claim to be, for example by checking government ID against HR records before the account and its authenticators are handed over. Authentication is different: it happens at every sign-in and only proves that the person signing in holds the credential.

Strong passwords and multifactor authentication only protect whoever received the credential. If a caller impersonating a new hire talks the help desk into issuing the account or resetting the MFA device, every later sign-in by the impostor will authenticate perfectly. The control for that risk is proofing at issuance and at credential reset, not stronger authentication.

One account per person

Every person receives their own account with a unique identifier so that every action can be traced back to one individual, a property called accountability. Shared or generic accounts break it. The general rule: controls layered on top of a shared login never give the system per-person attribution, because the system's own audit trail still records one identity for everyone who used it. Only individual accounts make the system itself attribute each action to a person.

The role profile is the only baseline

The access granted at provisioning should come straight from the job's own role definition, no more and no less. Granting extra access because the person might need it later is over-provisioning and violates least privilege. So are the common shortcuts:

• Copying a colleague's access ("make her like Sam") copies Sam's privilege creep too, every leftover right from every job Sam has held.
• Using a broader source, such as a department-wide profile or the line manager's access, grants rights the job does not need.

If a joiner genuinely needs something outside the standard profile, that is an exception. It is approved by the owner of the resource or data, not granted by IT because someone asked, and it is approved before the access is granted, with the reason documented, rather than recorded after the fact at the next review.

Authenticators and temporary accounts

Provisioning also covers issuing authenticators such as passwords, smart cards or tokens, and enrolling the user in multifactor authentication where required. For people engaged for a fixed period, such as contractors, interns and temporary project staff, provisioning should also set an account expiration date matching the end of the engagement. This is different from password expiration: an expired password forces the user to choose a new one and the account keeps working, while an expired account stops working altogether. The stage ends when the joiner can do their job with the minimum access the role requires.

An access review, also called recertification or attestation, is the periodic check in which a manager or data owner examines each user's current access and formally confirms that every entitlement is still required for the current job; anything no longer needed is revoked.

Reviews exist because people do not keep the same job forever. They transfer between departments, get promoted, cover for colleagues, and join temporary projects. Each change tends to add access, and unless someone actively removes the old rights, the person accumulates permissions from every role they have ever held. This accumulation is privilege creep, the classic mover risk.

Three near-twins

Scheduled and event-triggered reviews

Reviews run on a defined schedule, and also when an event changes what a person needs. Temporary cover and project assignments are a common source of creep: someone covering a colleague's leave or joining a three-month project is granted extra access that nobody remembers to take back. When the assignment ends, that event should trigger a review and removal at that time, rather than leaving the access in place until the next scheduled review months later. Reviews should also be more frequent for privileged accounts, such as administrator access, because the damage from an unnecessary privileged entitlement is far greater.

Detective backstop, not the primary control

A review is a detective and corrective control: it finds access that drifted away from the role definition and corrects it. For the leaver problem, the primary, preventive control is deprovisioning at separation. A review that finds a departed employee's account still active has caught a failure that should never have happened; it is the safety net, not the plan. Likewise, the mover process should revoke old-role access at the time of the move, with the review catching what the move missed.

Service accounts need owners

Non-human accounts, such as the service account an application uses to reach its database, have no HR joiner or leaver events, so HR-driven automation never creates, reviews or removes them. Each service account therefore needs a named owner who confirms it is still needed at each access review and requests its removal when the application no longer needs it. Without an owner, a service account can outlive the system and the person who created it.

AI agents are identities too

An AI agent or bot that acts in systems on its own is a non-human identity, and it goes through the same life cycle as any account: it is provisioned, reviewed and deprovisioned. Three rules follow.

• Its own identity, with a human owner. Each agent gets a dedicated identity, never a developer's personal account or one bot account shared by several agents, so every action it takes is attributable in the logs. A named person owns it, recertifies its access at each review and answers for what it does.
• Least privilege, scoped to the task. The agent's role contains only the actions its job needs. An AI agent can be manipulated, for example by instructions hidden in the content it reads, and whatever access it holds is what a manipulated agent can misuse. The OWASP Top 10 for LLM Applications calls this risk excessive agency: too much permission, functionality or autonomy granted to an LLM-based system.
• Retirement means revoking credentials. Shutting down the model or the application does not end the identity. The agent's account, long-lived API keys and refresh tokens stay valid until someone disables the identity and revokes every credential in every system it could reach. No HR leaver event exists for an agent, so its owner must trigger this step, exactly as for a service account.

Deprovisioning removes or disables an identity's access when the person leaves the organization or no longer needs the account. It is the leaver stage of the life cycle, and timeliness is the whole point: access that outlives the business need is pure risk with zero benefit.

Orphaned versus dormant accounts

Both are attacker favorites because nobody is watching them: no legitimate user notices strange logins and the account often retains meaningful access. A disgruntled former employee with a still-active account is an insider threat that walked out the door with the keys.

Timing: access ends when the business need ends

The rule is that access ends when the business need for it ends, which is not always the formal end date.

• Voluntary resignation in good standing: the person keeps working through the notice period, so access is disabled at the close of their final working day.
• Involuntary termination: disable access at or before the moment the person is told, because the window between notification and revocation is when a resentful insider can do the most damage. For a privileged leaver, this means every access path at once: the standard account, separate admin accounts, and VPN or other remote access.
• Garden leave (the person remains employed and paid but does no further work): the business need ends when the work ends, so access goes then, not on the later contractual end date.
• Temporary accounts: an account expiration date is a backstop that stops the account if nobody acts at the planned end. It does not replace the leaver process. Whenever a temporary engagement ends sooner than planned, for any reason, the leaver process runs at that point instead of waiting for the expiry date.

Disable first, delete later

Disable the account immediately at separation, which blocks all access while preserving the account's data, mailbox and audit history for investigations and handover. Deletion, if it happens at all, follows later under the organization's retention rules.

Reach every system

Deprovisioning must reach every place the person holds an account or a way in. Disabling the central directory or SSO identity blocks only the applications that rely on it; an application with its own local logins, such as a hosted ticketing tool where the user was also given a direct username and password, stays fully usable until that account is disabled too. Full deprovisioning also removes group memberships and shared-mailbox access, revokes tokens and certificates, and collects badges, keys and equipment. Partial deprovisioning that misses one cloud application leaves an orphaned account all the same.

The Joiner-Mover-Leaver model, often shortened to JML, maps the identity life cycle onto the three events that change a person's relationship with the organization. It is a useful mental index because nearly every identity management scenario describes one of these events.

Some organizations add a fourth event, the Rejoiner (a rehire). A rejoiner is handled as a joiner: their identity is verified again, and access is provisioned from the role profile of the job they are returning to. Their old account's access is not simply restored, because the old entitlements reflect a previous job and may be long out of date.

Work through a scenario. Maya joins a hospital as a billing clerk and is provisioned read and write access to the billing system, matching the role definition. Two years later she moves to the audit team. The mover process grants audit system access and, critically, revokes her billing write access, because auditors must not be able to alter the records they audit. When Maya later resigns, her accounts are disabled at the end of her final working day, her badge is collected, and her mailbox is preserved for her successor. At each event the access changed to match the current role, and nothing survived that should not have.

The CC exam expects you to recognize the categories of tools that implement the identity life cycle, not to configure them. Each category answers a different question.

• Directory services store identity information, accounts, groups and attributes, in one central, authoritative database that systems across the organization query. A directory answers "who exists, and what groups are they in?"
• Identity providers (IdPs) authenticate users and issue signed assertions of identity to other systems, so applications can trust a central login rather than each keeping its own password store.
• Federation extends that trust across organizations. A partner's application (for example, a publisher's journal portal used by a university's staff) trusts the university's identity provider: the university authenticates its own users and sends a signed assertion, and the publisher never stores those users' passwords. When the university disables a user, new sign-ins to the partner fail, although a session already open at the partner and any local account or token the partner created still need to end, which is the same "reach every system" rule.
• Single sign-on (SSO) lets a user authenticate once and then reach multiple applications without logging in again. SSO reduces password fatigue, but it concentrates risk: one stolen sign-in reaches every linked application, so the SSO credential must be protected with multifactor authentication.
• IAM and IGA systems (identity and access management, identity governance and administration) orchestrate the life cycle itself: they automate provisioning workflows from HR records, route access requests to owners for approval, run recertification campaigns, and keep an auditable record of who approved what.
• Privileged access management (PAM) tools control administrator access specifically. They keep admin credentials in a secure vault, release them only on an approved request (checkout), record the sessions in which they are used, and support just-in-time elevation: admin rights are granted for a set period when needed and removed automatically, instead of being held as standing admin rights all the time.

Automated provisioning ties these together. When human resources records a new hire, the IAM system creates the accounts and applies the role profile; when HR records a termination, it disables everything connected to it within minutes. Automation removes the human delay that creates orphaned accounts and applies role definitions consistently. Its limits are the gaps covered above: accounts outside the feed, such as service accounts and applications with local logins, still need owners and explicit steps.