5.5 Identity & Access Provisioning Lifecycle
5.5 Identity & Access Provisioning Lifecycle
Access should exist because there is a current, legitimate business need.
When a person joins, changes role or leaves, their access should change with them. The same principle applies to systems, applications and services.
Provision
Create identities and grant approved access when it is required.
RIGHT ACCESSMaintain
Change access as roles, responsibilities and systems change.
KEEP IT CURRENTDeprovision
Remove access promptly when the underlying requirement ends.
REMOVE TRUSTManage the Identity and Access Provisioning Lifecycle
Review access belonging to users, systems and services.
Manage onboarding, offboarding and transfers.
Ensure access changes when people move into new roles.
Control temporary or elevated privilege, including mechanisms such as sudo and auditing its use.
Manage non-human identities through their entire lifecycle.
The Big Idea
Access is not a permanent property of an identity.
It should represent:
Access Lifecycle
Joiner · Mover · Leaver
One of the easiest ways to understand identity lifecycle management is through three common business events.
A person joins the organisation or begins a new relationship with it.
CREATE + GRANT
A person's responsibilities, department, location or employment status changes.
CHANGE + REMOVE
The employment or business relationship ends.
REVOKE
JML
🏛️ Authoritative Identity Source Lifecycle automation needs a reliable trigger
Identity lifecycle processes often begin with an authoritative source containing reliable information about the person's relationship with the organisation.
If employment status, department or role information is inaccurate, automated provisioning can distribute the wrong access very quickly.
Provisioning a New Identity
Provisioning is the process of creating or enabling accounts, identities, credentials and access according to an approved requirement.
🎁 Baseline / Birthright Access Common access granted automatically from identity attributes
Some access may be appropriate for nearly everyone belonging to a particular workforce population.
A new permanent employee might automatically receive:
The fact that access is automatically provisioned does not mean every employee should receive every common application.
Baseline Access
📝 Requestable Access Sensitive access should require justification and approval
Access outside the normal baseline may require a formal request.
✅ Who Should Approve Access? Approval should reflect responsibility for the risk
Can validate whether access is required for the person's job.
Can determine whether access to the protected asset is appropriate.
May be required for particularly sensitive or administrative privileges.
Low-risk standard access may be automatically provisioned when predefined requirements are satisfied.
A manager may know that an employee needs a business application, while the information owner may be better positioned to approve access to highly sensitive data within it.
Role Definition & Transition
Transfers are one of the most important access-lifecycle events because access frequently needs to be both:
Alice moves from:
Customer Service → Cyber Security.
A poor lifecycle process:
adds security permissions while leaving every Customer Service permission intact.
A better process evaluates:
Mover
Mover ≠ just add more permissions.
📈 Privilege Creep / Access Accumulation Permissions build up as people move through the organisation
Controls
👔 Role Definition Roles should correspond to genuine organisational responsibilities
Provisioning works more effectively when organisational roles are clearly defined.
The role should correspond to a genuine job function.
The access included in the role should be known and documented.
Someone should be responsible for determining whether the role remains appropriate.
Incompatible permissions should not be bundled together unnecessarily.
Roles should evolve as applications and business processes change.
Moving into or out of the role should result in predictable access changes.
Deprovisioning
Deprovisioning removes or disables identities, credentials, sessions, accounts and access that are no longer authorised.
🧹 What Must Be Considered During Offboarding? Think beyond the primary directory account
Disable or otherwise prevent normal authentication.
Remove separate local accounts that are not automatically governed by central identity.
Remove administrative roles and privileged credentials.
Consider whether existing authenticated sessions remain usable.
Revoke credentials personally associated with the departing identity.
Remove remote connectivity.
Revoke badges, smart cards and facility access.
Determine whether passwords or secrets known to the departing person require rotation.
🚫 Disable vs Delete Stopping access and removing the account are different actions
Prevents normal use of an identity while preserving the account and associated records.
Removes the account or identity representation from the system.
Organisations may preserve disabled accounts temporarily where operational, audit, investigation, retention or recovery requirements justify doing so.
The important security outcome is that the former identity can no longer exercise unauthorised access.
⏰ Timing Matters The risk window exists between the business event and revocation
Sensitive or involuntary terminations may require carefully coordinated revocation according to organisational policy.
📅 Temporary & Contractor Accounts Known end dates should drive automatic expiry where appropriate
A contractor is hired for:
three months.
Their account is provisioned with:
no expiration date.
The approved contract end date becomes part of the lifecycle information used to expire or review access.
Temporary Access
Does This Identity Still Need This Access?
Access reviews provide a control for finding permissions that no longer match legitimate requirements.
Review employee, contractor and privileged-user access.
Review accounts belonging to infrastructure and technical systems.
Review non-human application and workload identities.
Access Review
🔍 What Should an Access Review Examine? Review effective access, not merely the account name
A manager sees:
Alice - Finance Analyst.
But Alice's effective access comes from:
A useful review should expose enough information to determine the access Alice actually has.
✍️ Access Certification / Recertification A review should produce a meaningful decision
A review process that merely preserves every historical permission does little to reduce access risk.
🔄 Access Reconciliation Does actual access match intended access?
Provisioning systems may contain a record of what access should exist.
Target systems contain the access that actually exists.
IAM records show:
Alice = Standard User.
The application itself shows:
Alice = Administrator.
Reconciliation identifies the difference.
Reconciliation
💤 Dormant & Inactive Accounts Unused access can remain valuable to an attacker
An account that has not been used for a long period may indicate:
Dormant accounts may retain legitimate permissions while receiving less operational attention.
Controlled Elevation of Privilege
Users should not necessarily operate with administrative privilege continuously.
Privilege can instead be elevated when an authorised administrative task requires it.
Privilege Elevation
⌨️ sudo & Privileged Commands Elevate selected operations rather than living permanently as root
On Unix-like systems, sudo can permit authorised users to execute commands with elevated privileges according to configured policy.
Administrator normally operates as:
standard account.
When a protected task is required:
authorised privilege is invoked for that task.
Security Considerations
⏱️ Just-in-Time & Just-Enough Privilege Limit both duration and scope
Privilege exists only during the period in which it is required.
LIMIT TIME
The elevated identity receives only the permissions necessary for the task.
LIMIT POWER
A support engineer needs to restart one production service.
Instead of permanent full administrator access:
- access is approved for 30 minutes;
- only the required administrative operation is available;
- activity is logged;
- elevation expires automatically.
JIT + Just Enough
👑 Standing Privilege Privilege that exists even when nobody currently needs it
Administrative capability remains continuously available.
Administrative capability is activated only when justified.
Reducing unnecessary standing privilege can reduce the attacker's opportunity after compromising an account.
🚨 Emergency / Break-Glass Access Exceptional access still requires governance
Organisations may require emergency access for situations where normal IAM mechanisms cannot be used or immediate privileged action is necessary.
Controls May Include
Break Glass
Non-Human Identities Need a Lifecycle Too
Service accounts are identities used by applications, operating-system services, automated jobs, integrations and other non-human processes.
🤖 Why Service Accounts Become Risky They are often powerful, long-lived and forgotten
Applications may be given broad access because it is easier than defining precise permissions.
Passwords or keys may remain unchanged for years.
Nobody knows which application or team still requires the account.
Credentials may appear in source code, scripts or configuration files.
A service account may unnecessarily permit direct human login.
The application is retired but the account remains enabled.
Service Account Risks
🛠️ Managing Service Accounts Treat them as managed identities, not technical leftovers
Give services identifiable accounts rather than reusing one shared identity everywhere.
Identify the team or individual responsible for the account.
Know which application or process depends on the identity.
Grant only the permissions the service actually requires.
Store secrets and keys using appropriate secret-management mechanisms.
Ensure credentials can be changed without breaking the service.
Detect unusual or interactive use where inappropriate.
Confirm periodically that the account is still required.
Service Account Lifecycle
👻 Orphaned Accounts Access remains after the owner or purpose disappears
Application:
retired two years ago.
Service account:
still enabled.
Permission:
database administrator.
Owner:
unknown.
👥 Shared Accounts Convenience can weaken accountability and lifecycle control
Twenty administrators use:
admin / shared-password.
When one administrator leaves, the organisation must determine:
- whether the shared password must be changed;
- who still knows the credential;
- which historical actions belong to which person.
Individual privileged identities or controlled privileged-access mechanisms are usually easier to govern and audit.
Automated Provisioning & Deprovisioning
Automation can reduce delays and inconsistency in large identity environments.
Good data can remove access quickly.
Bad data or bad policy can distribute inappropriate access quickly.
🔌 Provisioning Integrations IAM systems must communicate lifecycle changes to target services
Identity platforms may provision accounts and attributes into applications using connectors, APIs or standardised provisioning mechanisms.
Federation allows one service to trust authentication performed elsewhere.
Provisioning manages the account or identity representation and its attributes in the target service.
Federation vs Provisioning
| Federation | Provisioning | |
|---|---|---|
| Main Purpose | Trust identity/authentication across domains | Create, modify and remove identity/access |
| Typical Question | Who authenticated this user? | Should an account/access exist? |
| Lifecycle Concern | Trust and sessions | Joiner, mover, leaver |
| Memory | TRUST | CREATE / CHANGE / REMOVE |
⚖️ Separation of Duties During Provisioning Some combinations of access should not be granted together
Alice requests:
Individually, each role may be legitimate.
Together, they may violate separation-of-duties policy.
👤 Access Ownership Every sensitive entitlement should have somebody responsible for it
The person, service or organisational relationship associated with the identity.
Determines whether a role remains appropriately designed.
Determines whether access to a protected asset remains appropriate.
Remains responsible for the non-human identity and its continued business need.
🧾 Provisioning Audit Trail Access changes should be explainable
Useful Evidence
"Why did Alice have administrator access on 14 March?"
A mature lifecycle process should make it possible to determine:
- which business need existed;
- who approved the access;
- when it became active;
- how it was used;
- when it expired or was removed.
A Leaver Still Has Access
Alice leaves the organisation on Friday.
Deprovisioning must consider every relevant account and access path.
A User Changes Department
Bob moves from:
Finance → Security Operations.
Add SOC access.
Keep every Finance role.
Privilege accumulates.
Determine required SOC access.
Remove Finance access no longer required.
Retain only explicitly justified exceptions.
Mover Rule
Production Maintenance
A system engineer needs elevated privilege to install an approved production update.
An Application Is Retired
An old reporting application is decommissioned.
🎓 CISSP Scenarios Identify the lifecycle principle
A new employee receives email, collaboration and employee-portal access automatically.
Which lifecycle activity?
Provisioning / onboarding.
An employee leaves and their logical access is removed.
Which lifecycle activity?
Deprovisioning / offboarding.
A user moves departments and receives new access but retains every previous permission.
Primary concern?
Privilege creep.
A user's new role requires a different set of permissions.
Which CISSP 5.5 concept?
Role definition and transition.
An employee's department change automatically updates their IAM permissions.
Which lifecycle event?
Mover / transfer.
A contractor account has a known contract end date but no account expiry.
What would improve the design?
Time-limited access or automatic review/expiration based on the approved end date.
A terminated employee's directory account is disabled but a local SaaS account remains usable.
What failed?
Complete deprovisioning.
A departing administrator still has an active API key.
What should occur?
Credential/token revocation as part of offboarding.
An account is disabled during offboarding but preserved temporarily for audit requirements.
Is deprovisioning necessarily incomplete?
No, provided the former user can no longer exercise unauthorised access and organisational requirements are satisfied.
A manager periodically verifies that employees still require their assigned permissions.
Which activity?
Account access review / recertification.
A review identifies an account that has not been used for 18 months.
Which concern?
Dormant or inactive account.
IAM says a user is standard, but the application itself shows the user as administrator.
Which process can identify the mismatch?
Access reconciliation.
A user requests access and approves their own request.
Primary concern?
Insufficient separation of duties / approval governance.
A manager approves access to data without being responsible for that information.
Who may be a more appropriate approver?
The relevant resource or information owner.
Provisioning is automated using incorrect department data.
Hundreds of users receive the wrong role.
Primary lesson?
Automated provisioning depends on accurate authoritative data and policy.
A Unix administrator invokes sudo for an authorised privileged command.
Which 5.5 topic?
Privilege escalation.
Administrators can use elevated privilege but nobody records when or how it is used.
What is missing?
Auditing/accountability for privilege escalation.
An administrator is granted production privilege only for a 30-minute approved task.
Which approach?
Just-in-Time privilege.
A support engineer can restart one service but cannot perform unrelated administrator operations.
Which principle?
Just-enough privilege / least privilege.
Administrative access exists permanently even though it is required only once per month.
Which risk?
Unnecessary standing privilege.
An emergency administrator account is used and security is immediately alerted.
Activity is reviewed afterwards.
Which control?
Break-glass / emergency access governance.
An application uses an account with database administrator rights even though it only needs to read one table.
Which principle is violated?
Least privilege for service accounts.
A service-account password has not changed in ten years.
Which area requires improvement?
Service-account credential management.
A service account has no documented owner.
Why is this dangerous?
Nobody is clearly responsible for reviewing, changing or deprovisioning the identity.
An application is retired but its privileged database service account remains active.
Which problem?
Orphaned service account.
Twenty administrators use one shared privileged identity.
What is significantly weakened?
Individual accountability.
A service account is used interactively by administrators even though it was intended only for an application.
What should be examined?
Whether interactive use should be restricted and why the service identity is being used by humans.
Access is created automatically the first time a federated user reaches an application.
Which mechanism?
Just-in-Time provisioning.
Federation authentication is disabled when a user leaves, but the third-party account itself remains active with a local password.
Which lesson?
Federation and provisioning lifecycles must both be considered.
Payment Creator and Payment Approver access are individually valid but should not be held together.
Which provisioning check?
Separation-of-duties conflict checking.
A quarterly review shows every existing permission but does not show why the user has it.
What would improve the review?
Business context, entitlement description and ownership information sufficient for meaningful certification.
An employee has left, but an existing authenticated session remains active for several hours.
Which lifecycle consideration?
Session termination during deprovisioning.
An employee transfers roles and has a legitimate temporary need to retain one old permission.
What is preferable?
Explicitly justify and preferably time-limit the exception rather than retaining all historical access.
A provisioning workflow successfully sends a disable command, but the target application fails to apply it.
Which control helps detect this?
Reconciliation / verification of actual access.
A privileged role is granted after approval but no expiration is configured despite being needed for only one project.
Which improvement?
Time-limited privilege with automatic expiry.
Recognise the Clue Words
New Employee
Create identity and access.
ProvisioningEmployee Leaves
Remove trust.
DeprovisioningChanges Department
Add and remove access.
MoverOld Access Accumulates
Historical privileges remain.
Privilege CreepStill Need This Access?
Periodic validation.
Access ReviewManager Confirms Access
Periodic approval.
RecertificationShould Have vs Does Have
Find discrepancies.
ReconciliationUnused Account
Forgotten identity.
Dormant AccountApplication Gone, Account Remains
Identity lost its purpose.
Orphaned AccountKnown Contract End Date
Avoid permanent access.
Automatic ExpiryTemporary Administrator
Limit duration.
JIT PrivilegeOnly Required Admin Commands
Limit scope.
Just-Enough Privilegesudo
Elevated command execution.
Privilege EscalationWho Used sudo?
Trace privileged use.
AuditEmergency Administrator
Exceptional privileged access.
Break GlassApplication Identity
Non-human account.
Service AccountNo Service Account Owner
Lifecycle problem.
Ownership Gap10-Year Service Password
Long-lived secret.
Credential ManagementFirst Login Creates Account
Provision on demand.
JIT ProvisioningIncompatible Roles
Prevent dangerous combination.
Separation of Duties⚠️ Common CISSP Mistakes Lifecycle questions often test what must be removed, not just what must be created
Provisioning can include identities, roles, entitlements, credentials and target-system access.
Access from the old role should also be evaluated and removed where no longer needed.
Applications, privileged roles, sessions, tokens, remote access and physical access may need separate revocation.
Access must stop, but records may need to remain according to operational, retention or investigation requirements.
Historical access should not survive a transfer without a current justification.
Review effective roles, groups, permissions and privileged access.
The reviewer should make a meaningful keep-or-revoke decision.
Reconciliation can verify whether target-system access matches the intended state.
Bad source data or policy can automate inappropriate access.
Privilege can be elevated only for appropriate tasks rather than remaining permanently active.
Who may elevate, what they may execute and how activity is audited still matter.
Break-glass use should remain protected, visible and reviewed.
Non-human identities need owners, least privilege, credential management, review and deprovisioning.
A service identity should still have an identified business or technical owner.
Service identities, API keys and permissions may remain unless the decommissioning process explicitly removes them.
Federation establishes trust in identity information; provisioning creates, modifies and removes identities and access.
JIT provisioning can create an account on demand.
JIT privilege grants elevated permissions only when required.
Quick Reference
| If you see... | Think... |
|---|---|
| New employee | Joiner / Provisioning |
| Department change | Mover / Role Transition |
| Employment ends | Leaver / Deprovisioning |
| Automatic standard access | Baseline / Birthright Access |
| Additional sensitive access | Request + Approval |
| Old permissions accumulate | Privilege Creep |
| Does user still require access? | Account Access Review |
| Reviewer re-approves appropriate access | Recertification |
| Expected access vs actual access | Reconciliation |
| Long-unused identity | Dormant Account |
| No owner / no purpose | Orphaned Account |
| Temporary employee / contractor | Time-Limited Access |
| Elevate privileges for task | Privilege Escalation |
| Unix elevated command | sudo |
| Who used elevated privilege? | Audit / Accountability |
| Privilege for 30 minutes | JIT Privilege |
| Only required admin commands | Just-Enough Privilege |
| Permanent admin capability | Standing Privilege |
| Emergency administrative identity | Break-Glass Access |
| Application or workload identity | Service Account |
| Application retired, service identity remains | Orphaned Service Account |
| Account created on first federated login | JIT Provisioning |
| Trust external authentication | Federation |
| Create/change/delete target account | Provisioning |
| Two incompatible entitlements requested | Separation-of-Duties Check |
Joiner · Mover · Leaver Memory Aid
Join = Grant · Move = Adjust · Leave = Revoke
Access Review Memory Aid
Privilege Escalation Memory Aid
Service Account Memory Aid
5.5 Master Memory Aid
Provision → Maintain → Review → Revoke
The IAM Lifecycle Questions
Key Takeaways
Identity and access provisioning is a lifecycle rather than a one-time account-creation activity.
The current CISSP 5.5 objective covers account access reviews, provisioning and deprovisioning, role definition and transition, privilege escalation and service-account management.
The Joiner-Mover-Leaver model provides a simple way to understand workforce identity lifecycle.
Joiners require appropriate identities, credentials and access to be provisioned.
Movers require both new access to be added and obsolete access to be removed.
A mover process that only adds permissions creates privilege creep.
Leavers require access to be revoked when their relationship with the organisation ends.
Deprovisioning should consider all relevant access paths rather than only the primary directory account.
Application accounts, privileged roles, active sessions, API keys, VPN access and physical credentials may all require revocation.
Deprovisioning does not necessarily require immediate deletion of every account record; the essential security outcome is that unauthorised use is prevented while retention and operational requirements are respected.
Timing matters. The period between termination and revocation is a period of unnecessary exposure.
Temporary workers and contractors should not receive indefinite access when an approved end date is already known.
Some low-risk baseline access can be provisioned automatically from trusted identity attributes.
Sensitive or unusual access may require formal request, business justification and approval.
Approval should be performed by an authority able to judge the legitimate requirement and associated risk.
Access provisioning should also consider separation-of-duties conflicts between individually legitimate permissions.
Account access reviews ask whether users, systems and services still require their existing access.
Reviews should consider effective access, including roles, groups, inherited privileges and direct permissions.
Recertification should result in a meaningful keep-or-revoke decision rather than automatic preservation of historical access.
Reconciliation compares expected access with the permissions actually implemented in target systems.
Dormant accounts may retain valuable permissions despite no longer being actively used.
Privilege escalation allows authorised identities to perform elevated operations when required.
Privilege elevation should be controlled and appropriately audited. The current CISSP outline explicitly gives sudo and auditing its use as an example.
Just-in-Time privilege limits how long elevated authority exists.
Just-enough privilege limits how much elevated authority is granted.
Standing administrative privilege should be avoided where temporary elevation can satisfy the legitimate requirement.
Emergency or break-glass access can provide resilience when normal mechanisms cannot be used, but its use should remain protected, visible and reviewed.
Service accounts are identities used by applications, services, integrations, workloads and automation.
Service accounts require lifecycle management just as human identities do.
Service accounts should have identifiable owners, documented purposes and least-privilege permissions.
Their credentials should be appropriately protected, managed and changeable.
Long-lived, highly privileged service accounts with no known owner are a significant governance concern.
Application retirement should trigger review and deprovisioning of associated service identities, keys and permissions.
Shared accounts weaken individual accountability and complicate provisioning and offboarding.
Automation can make provisioning and deprovisioning faster and more consistent, but it depends on accurate authoritative information and correctly designed policy.
Federation and provisioning are related but different: federation establishes identity trust, while provisioning creates, changes and removes identities and access.
Every important identity, role and entitlement should have sufficient ownership to support approval, review and eventual revocation.
An audit trail should make it possible to explain why access was granted, who approved it, when it changed and when it was removed.
The central CISSP principle is simple: grant access when the requirement begins, change it when the requirement changes, review it while it exists and remove it when the requirement ends.
📚 Sources & Further Reading Identity lifecycle, account management and privileged-access references
- ISC2 - CISSP Certification Exam Outline
View the current CISSP Exam Outline - NIST SP 800-53 Rev. 5 - Security and Privacy Controls for Information Systems and Organizations
View NIST security and privacy controls - NIST SP 800-63-4 - Digital Identity Guidelines
View NIST Digital Identity Guidelines - NIST SP 800-63A-4 - Identity Proofing and Enrollment
View NIST identity-proofing and enrollment guidance - NIST CSRC - Capability, Privilege and Account Management
View NIST privilege and account management terminology - NIST CSRC - Provisioning API
View NIST provisioning terminology