Identity and Access Provisioning Lifecycle

Where Access Accumulates and Nobody Notices

A systems administrator joins the finance department. She receives access to the ERP system, the general ledger, and the accounts payable module. Eighteen months later she transfers to operations. She gets operations access — supply chain management, inventory systems, warehouse reporting. Nobody removes the finance access. Two years after that, she moves into IT project management. More access is added. Nothing is removed. She now has permissions across three departments, including combinations that violate separation of duties.

This is privilege creep, and it is the single most common identity governance failure in enterprise environments. The CISSP exam knows it.

The identity lifecycle is not about creating accounts. It is about maintaining the principle of least privilege across every transition an identity undergoes — from hire to termination and every role change in between.

This module covers CISSP objective 5.5: manage the identity and access provisioning lifecycle. The exam tests whether you understand the governance processes that prevent access from accumulating beyond what a person’s current role requires.

The Identity Lifecycle

Every identity in an organization passes through distinct stages. Each stage requires specific governance actions.

1. Creation — A new identity is established. This is triggered by a hire, a contractor engagement, or a system integration. The identity is provisioned with an initial set of access rights based on their role
2. Management — The identity is active and in use. Access is monitored, reviewed, and adjusted as the person’s role or responsibilities change. This is where most governance failures occur
3. Suspension — The identity is temporarily disabled. Triggers include extended leave, investigation, or a security incident involving the account. The identity still exists, but access is blocked
4. Deletion — The identity is permanently removed. This happens at termination, contract expiration, or when a system account is decommissioned. All associated access, credentials, and tokens must be revoked

The exam tests lifecycle management at the governance level. The question is never “how do you disable an Active Directory account?” It is “what process ensures that all access is revoked when an employee is terminated?”

Joiner-Mover-Leaver

The joiner-mover-leaver (JML) framework maps identity lifecycle events to HR processes. It is the operational backbone of identity governance.

Joiner (Onboarding)

• HR triggers identity creation when a new hire or contractor is approved
• Access is provisioned based on the person’s role — ideally through automated role-based provisioning
• The joiner receives only the access their role requires. Birthright access (access everyone in that role needs) is granted automatically. Additional access requires a separate request and approval

Mover (Role Change)

• The most governance-intensive event. When someone transfers departments, gets promoted, or takes on additional responsibilities, their access must be recalculated
• New access for the new role is provisioned. Access from the previous role that is no longer needed must be revoked
• This is where privilege creep originates. If the “remove old access” step is skipped or delayed, accumulated permissions grow with each move

Leaver (Offboarding)

• All access must be revoked at or before the effective separation date
• This includes directory accounts, VPN access, cloud service accounts, physical badges, email, and any third-party systems the person could reach
• Voluntary departures with notice periods require careful timing — the person still needs some access to do their job during the notice period, but monitoring should increase
• Involuntary terminations typically require immediate revocation, sometimes before the person is informed

Account Provisioning and Deprovisioning

Provisioning is the process of creating accounts and granting access rights. Deprovisioning is the reverse. Both should be driven by policy, not by individual requests to the help desk.

Automated provisioning uses identity governance tools that connect to HR systems. When HR records a new hire, the provisioning system automatically creates accounts in the required systems based on the person’s role. When HR records a termination, the system triggers deprovisioning across all connected systems.

Manual provisioning relies on tickets and human action. It is slower, error-prone, and creates gaps — especially during deprovisioning. Organizations that rely on manual deprovisioning consistently have orphaned accounts: active credentials for people who no longer work there.

The exam favors automated provisioning answers when the scenario describes scale, consistency, or time-sensitivity requirements.

Role Mining and Role Engineering

Before RBAC can work effectively, roles must be defined. There are two approaches:

• Role mining (bottom-up) — Analyze existing access patterns to discover what permissions people in similar positions actually have. Group common permissions into candidate roles. The risk is codifying bad practices — if everyone in accounting has unnecessary access to the HR system, role mining will include that access in the “Accounting” role
• Role engineering (top-down) — Start from job descriptions and business processes. Define what each role should have access to based on business need, then build the role accordingly. More accurate but more labor-intensive

Most organizations use a hybrid approach: role mining to establish a baseline, followed by role engineering to refine and validate against business requirements. The exam tests whether you understand that role mining alone can perpetuate existing over-provisioning.

Access Reviews and Recertification

Access reviews (also called access recertification or attestation) are periodic checks where managers or data owners verify that each person’s access is still appropriate for their current role.

• Frequency — Typically quarterly for privileged accounts and sensitive systems, annually for standard access. The frequency should be risk-based: higher-risk access requires more frequent review
• Responsibility — The manager or data owner reviews their direct reports’ access, not IT. The business knows whether the access is still justified; IT only knows whether the account exists
• Rubber-stamping — The biggest failure mode. Reviewers approve everything without actually evaluating whether the access is needed. Effective programs include metrics on review thoroughness, flag unchanged certifications for audit, and require justification for continued access

Access reviews are the primary detective control against privilege creep. Without them, accumulated access is invisible until an incident or audit reveals it.

Privilege Creep

Privilege creep is the gradual accumulation of access rights beyond what a person’s current role requires. It results from role changes where old access is not revoked, temporary access that becomes permanent, and exception-based grants that are never reviewed.

Indicators of privilege creep:

• Users with access across multiple departments when their role is in one
• Access permissions that do not match any defined role
• Separation of duties violations that developed over time
• Users with more access than their peers in the same position

Remediation involves access reviews, role recertification, and — in severe cases — a complete access reset where all permissions are revoked and reprovisioned based on current role requirements.

Service Accounts and Shared Accounts

Service accounts are non-human identities used by applications, scripts, and automated processes. They present unique lifecycle challenges:

• They often have elevated privileges but no human owner performing regular reviews
• Credentials (passwords, API keys) are frequently hard-coded or stored in configuration files
• They tend to survive long after the application or process they serve has been decommissioned
• Every service account must have a named human owner responsible for its lifecycle governance

Shared accounts are used by multiple people under a single set of credentials. They destroy individual accountability — when an action is performed under a shared account, you cannot determine who did it. The exam position is clear: shared accounts should be eliminated wherever possible and replaced with individual accounts with appropriate role-based access.

Privileged Access Management (PAM)

PAM addresses the governance of accounts with elevated privileges: root, administrator, database admin, and other accounts that can cause significant damage if misused.

• Privileged account discovery — Finding all privileged accounts across the environment, including those that were created informally
• Credential vaulting — Storing privileged credentials in an encrypted vault rather than in memory, scripts, or sticky notes. Users check out credentials when needed and they are automatically rotated after use
• Session monitoring — Recording privileged sessions so that actions taken under elevated access can be reviewed and audited
• Least privilege enforcement — Granting privileged access only when needed, only for the specific task, and only for the duration required

Just-in-Time Provisioning

Just-in-time (JIT) provisioning grants access only at the moment it is needed and revokes it immediately after. Instead of maintaining standing privileges, a user requests elevated access, the request is evaluated (automatically or through approval), access is granted for a defined time window, and then it expires.

JIT provisioning reduces the attack surface by minimizing the time window during which elevated credentials exist. A compromised account with no standing privileges is far less dangerous than one with permanent administrative access.

This concept aligns directly with zero-trust principles and is increasingly common in cloud environments where temporary role assumptions (like AWS STS temporary credentials) replace permanent access keys.

Identity Governance and Administration (IGA)

IGA is the umbrella term for the policies, processes, and technologies that manage the identity lifecycle. It brings together:

• Identity lifecycle management (creation through deletion)
• Access request and approval workflows
• Role management and role mining
• Access certification and recertification
• Segregation of duties enforcement
• Policy enforcement and compliance reporting

IGA platforms automate these functions and provide the audit trail that regulators and auditors require. When the exam asks about the “best approach to managing identity governance at enterprise scale,” IGA is the answer.

Pattern Recognition

Identity lifecycle questions on the CISSP follow these structures:

• “Employee transferred and has too much access” — Privilege creep from an incomplete mover process. The fix is access recertification and revoking permissions from the prior role
• “Former employee account still active” — Deprovisioning failure. The fix is automated deprovisioning linked to HR termination events
• “Auditor finds separation of duties violation” — Access accumulated across roles that should be mutually exclusive. Access reviews would have caught it earlier
• “Service account with no owner” — Governance gap. Every account — human or non-human — needs a named owner

Trap Patterns

Watch for these wrong-answer traps:

• “IT should review everyone’s access” — IT manages the systems. Business managers and data owners review access because they understand whether the access is still justified by business need
• “Disable the account immediately on resignation” — For voluntary departures with notice periods, immediate disablement may not be appropriate. The answer depends on the risk assessment of the situation. Involuntary terminations are different
• “Role mining alone produces accurate roles” — Role mining discovers what access people currently have, not what they should have. It must be validated through role engineering against business requirements
• “Annual access reviews are always sufficient” — Review frequency should be risk-based. Privileged accounts and access to sensitive systems require more frequent review than standard user access

Scenario Practice

Question 1

A quarterly access review reveals that a senior developer who transferred from the database administration team six months ago still has production DBA privileges, including the ability to modify financial database schemas. His current role does not require database administration access.

What is the MOST appropriate immediate action?

A. Document the finding and address it at the next annual review
B. Revoke the DBA privileges and provision access appropriate to his current developer role
C. Ask the developer if he still needs the access before making changes
D. Notify internal audit and wait for their recommendation

Question 2

An organization is implementing automated identity provisioning. The project team proposes using role mining to analyze current access patterns and build role definitions from the existing data. A security architect raises a concern.

What is the MOST valid concern about this approach?

A. Role mining is too expensive for most organizations
B. Role mining may codify existing over-provisioning into the new role definitions, perpetuating privilege creep
C. Role mining does not work with cloud-based identity systems
D. Role mining requires all users to be re-authenticated before analysis

Question 3

An organization discovers that a critical batch processing service account has been using the same password for three years. The account runs nightly data synchronization between the ERP and the data warehouse. No individual is listed as the account owner, and the original administrator who created it left the company two years ago.

What governance failure is MOST significant?

A. The password should have been rotated more frequently
B. The service account has no assigned owner, making it impossible to govern its lifecycle, review its access, or manage its credentials
C. Service accounts should not be used for batch processing
D. The data synchronization should use a different authentication method

Key Takeaway

Think of the identity lifecycle as a series of risk decisions, not technical tasks. Every joiner event creates new attack surface. Every mover event risks privilege accumulation if the old access persists. Every leaver event leaves orphaned access if deprovisioning is incomplete. The governance question the exam keeps asking, in different forms, is the same: who is responsible for ensuring that every identity in your environment has exactly the access it needs for its current purpose — no more, no less — and what process catches it when that principle is violated?