Domain 3 · Objective reference 3.1 · Chapter 10 of 19
Manage human and service identities throughout their lifecycle
About 6 minutes · ISC2 CC outline effective 1 September 2026
Session only. Enable saving or download a backup from this course’s hub.
Completion is self-reported and does not certify understanding.
See it · Try it · Recall it
Picture the topic
Remember this: Join move leave: access must follow the role.
Explore the anchors
Approve and provision necessary access.
Concept matching activity
Match this task or description to its concept:
Remove old rights and grant new ones.
Choose a concept before checking the explanation.
Access-decision sandbox
Try to edit a fictional record as a reader. Then change one condition and evaluate again. This simplified policy requires authentication, object scope and action permission; real policies have more conditions.
Change the request, then evaluate it.
A quick way to study this topic
- Hide the explanation and redraw these three anchors from memory.
- Explain the difference between the anchors in your own words.
- Apply the distinction to the worked example below. Check the full lesson for assumptions and exceptions.
- Recall it again tomorrow, then after a few days. A memory hint is a retrieval cue, not a replacement for understanding.
Original academy illustrations and fictional exercises. These are learning simulations, not a real virtual machine, network assessment or measure of job readiness. Activities reset when you leave or reload; they do not change quiz scores.
What this chapter explains
- Provision an identity for an approved purpose
- Handle transfers, reviews and departure completely
- An operational joiner, mover and leaver checklist
Provision an identity for an approved purpose
Identity lifecycle management covers role definition, approval, provisioning, modification, review and deprovisioning. Establish a named owner, required operations and an authoritative source for relevant status. Human accounts, workload identities, integrations and AI service accounts all need accountable ownership. Shared accounts weaken attribution unless their use is constrained and individually traceable through an approved mechanism.
Authentication factors include something known, something possessed and an inherence characteristic. Two knowledge secrets are not two different factor types. Multi-factor authentication strengthens identity verification but does not determine the permissions granted afterward. Account recovery and authenticator enrollment are also security-sensitive steps, not merely help-desk conveniences.
Handle transfers, reviews and departure completely
A transfer may require removing an old role before adding a new one. Periodic reviews should evaluate effective access, not just account existence or friendly role names. Nested groups, application-local accounts and delegated grants can create unexpected permissions. Non-human identities need credential, key and secret lifecycle procedures even when no employee departure triggers them.
Disabling a directory account may leave sessions, tokens, API keys or independent application accounts active. Deprovisioning should address relevant access paths and verify the outcome. Federation and single sign-on can centralize identity decisions, but applications still need suitable trust checks and authorization. Protect identity records, approvals and activity evidence against unnecessary disclosure.
An operational joiner, mover and leaver checklist
For a joiner, verify the approved identity, sponsor, role, start date and required applications before provisioning. For a mover, compare the old and new duties, remove incompatible rights and then verify the resulting access. For a leaver, use the approved timing and check directory access, local applications, remote access, sessions, tokens, physical badges and entrusted devices.
Keep evidence of approval and verification without collecting unnecessary personal details. Review orphaned service identities when their owner leaves or a project ends. A scheduled job may still need its account, so transfer accountable ownership and evaluate permissions rather than blindly deleting every automation identity associated with a departing employee.
Worked example
A contractor leaves. The organization disables their main account, revokes application sessions and integration keys, removes remote access and verifies the result against the applications they used. It preserves required activity evidence.
Check your understanding
Why is a role transfer not simply an account-provisioning task?
Show explanation
Adding the new role without removing conflicting old rights can accumulate privilege and violate separation of duties. The change must assess the complete resulting access set.
Source and study boundary
Official syllabus source. The reference identifies the topic being taught. Explanations and examples are original academy material; a topic link does not establish independent approval or sufficient exam mastery.