I6.6 Account Lifecycle and Access Reviews
Learn how defenders manage fictional joiners, movers, leavers, temporary access, dormant accounts, ownership changes, recertification, session cleanup, resource transfer, and evidence-based closure.
Lesson Progress
Account Lifecycle and Access Reviews
High School Intermediate • I6: Identity and Access Management • Lesson 6 of 8
Readiness Check
Before You Start
0/5 ready
Professional Hook
A Closed Ticket Does Not Prove Access Is Gone
A fictional central account can be disabled while active sessions, application-local roles, shared folders, registered devices, recovery factors, service permissions, and resource ownership remain. Defenders close lifecycle work only after every relevant system and owner confirms the approved final state.
Weak response
“The directory account is disabled, so the leaver process is complete.”
Strong response
“Verify sessions, factors, devices, groups, roles, local permissions, resource ownership, retention, denied access, and accountable owner closure.”
Objective 1
Explain the fictional joiner, mover, leaver, temporary-access, inactive-account, suspension, reactivation, and deletion lifecycle.
Objective 2
Evaluate fictional account and access changes using owners, approvals, roles, groups, permissions, sessions, devices, applications, dates, and business purpose.
Objective 3
Distinguish technical removal, session revocation, application-local cleanup, resource-transfer, data-retention, and owner validation.
Objective 4
Identify stale accounts, orphaned permissions, incomplete transfers, missed temporary expirations, weak recertification, and lifecycle evidence gaps.
Objective 5
Create a professional fictional Account Lifecycle and Access Review Report with findings, owners, remediation, validation, monitoring, and residual risk.
Why This Matters
Identity Risk Often Appears During Change
Access can become unsafe when new roles are added without removing old roles, temporary access lacks expiration, service accounts lose owners, inactive identities remain enabled, local permissions are missed, or resources remain owned by departed identities. Strong lifecycle controls prevent access from drifting away from current responsibility.
Identity Lifecycle
Eight Stages from Sponsorship to Closure
Request and sponsorship
Purpose
A fictional manager, owner, project lead, application owner, or service owner documents why the identity needs access.
Required evidence
Identity type, owner, sponsor, job or service purpose, start date, resource scope, required actions, duration, and approval path.
Common risk
Vague requests create broad default access, unclear ownership, and difficult future removal.
Identity and account creation
Purpose
Approved fictional accounts are created with unique identifiers, correct ownership, required authentication, and initial state.
Required evidence
Account ID, account type, owner, creation time, directory, application, device, factor, and provisioning record.
Common risk
Duplicate accounts, shared identities, wrong account types, or accounts created before approval.
Access assignment
Purpose
The fictional identity receives exact roles, groups, permissions, resources, devices, applications, and conditions required for the approved purpose.
Required evidence
Role, group, direct permission, resource share, local access, start, expiration, owner, and implementation details.
Common risk
Broad templates, copied access, direct grants, or missing expiration can exceed business need.
Activation and validation
Purpose
The fictional identity confirms approved sign-in and required access while unrelated or higher-risk actions remain denied.
Required evidence
Authentication, MFA, device, session, application, positive test, negative test, owner confirmation, and issue resolution.
Common risk
The account is marked complete without verifying that required access works or excessive access is denied.
Normal use and monitoring
Purpose
The fictional account performs expected work while sign-ins, sessions, permissions, changes, and unusual activity are monitored.
Required evidence
Usage records, authentication, application actions, owner reviews, alerts, device state, and support records.
Common risk
Dormant, shared, unexpected, or excessive use can remain unnoticed.
Change or mover event
Purpose
The fictional identity’s access is updated when role, project, department, manager, device, application, or service responsibility changes.
Required evidence
Old and new role, effective date, owner approval, resource transfer, permissions removed, permissions added, sessions, and validation.
Common risk
New access is added while old access remains, creating privilege accumulation.
Temporary expiration or suspension
Purpose
The fictional identity or access is restricted when a project ends, an approved duration expires, risk requires review, or a temporary pause is needed.
Required evidence
Expiration, suspension reason, owner, account state, role state, session revocation, application state, and review date.
Common risk
The central account changes, but application-local access or existing sessions continue.
Separation and closure
Purpose
The fictional identity’s accounts, access, sessions, devices, resources, ownership, and records are safely transferred, disabled, retained, or removed.
Required evidence
Effective time, owner, disablement, session revocation, group removal, local-access cleanup, resource transfer, retention, deletion, and validation.
Common risk
Tickets close before every system, session, permission, resource, and owner relationship is resolved.
Joiner Controls
Eight Controls for Safe Initial Access
Unique identity and account type
Strong practice
Create the correct fictional standard, privileged, service, application, temporary, or emergency identity with named ownership.
Weak practice
Reuse a shared or existing account because creation is faster.
Approved access baseline
Strong practice
Assign only the role, groups, applications, resources, and device conditions needed for the approved starting function.
Weak practice
Copy all access from another person without comparing responsibilities.
Start and expiration dates
Strong practice
Use an approved start date and automatic expiration for temporary identities, projects, and elevated access.
Weak practice
Create the account immediately and leave temporary access permanent.
Authentication and recovery
Strong practice
Register approved fictional factors, recovery ownership, device relationships, and session policies.
Weak practice
Use a temporary shared password and never review recovery methods.
Resource ownership
Strong practice
Document which fictional folders, reports, applications, classes, services, or projects the identity owns or uses.
Weak practice
Assign broad access without naming resources or accountable owners.
Positive validation
Strong practice
Confirm the fictional identity can complete the required sign-in and business workflow.
Weak practice
Assume provisioning succeeded because the directory shows the role.
Negative validation
Strong practice
Verify unrelated, privileged, restricted, or expired actions remain denied.
Weak practice
Test only the required page and ignore broader effective access.
Review scheduling
Strong practice
Set a fictional manager, owner, project, service, and privileged-access review date.
Weak practice
Wait for a problem or separation event before reviewing access.
Mover Risks
Eight Ways Access Becomes Misaligned During Change
Privilege accumulation
Evidence
A fictional employee receives a new department role but retains all prior department permissions.
Impact
The account can access resources unrelated to the current responsibility.
Correction
Compare old and new job needs, remove stale roles, refresh sessions, and validate both required and denied actions.
Manager or owner mismatch
Evidence
A fictional account’s manager changes, but access reviews still route to the former manager.
Impact
Recertification decisions may be delayed, incorrect, or completed by someone without current context.
Correction
Update ownership and review routing, then reissue high-risk access decisions.
Project relationship remains
Evidence
A fictional user leaves a project but still belongs to its workspace group and resource shares.
Impact
Project data and collaboration access continue after the business relationship ends.
Correction
Remove project membership, shares, local permissions, and sessions; transfer owned resources; validate denial.
Privileged role follows normal transfer
Evidence
A fictional administrator moves into a non-administrative role but keeps standing privileged access.
Impact
High-impact capability remains without current job need.
Correction
Remove privileged roles, check administrative sessions and local access, and require a new approved request for future use.
Application-local access missed
Evidence
The central directory role changes, but a fictional application still lists the account as editor.
Impact
Governance records show reduced access while effective access remains broad.
Correction
Update the local application permission, refresh sessions, and add the application to future mover reviews.
Device relationship remains stale
Evidence
A fictional user changes roles and devices, but the previous managed device remains associated with remembered sessions.
Impact
Older device and session trust may outlast the current ownership and role.
Correction
Review device ownership, remembered sessions, certificates, and application access during the mover event.
Resource ownership not transferred
Evidence
A fictional project lead changes teams but remains owner of reports and shared folders.
Impact
Approvals, sharing, and lifecycle decisions route to the wrong person.
Correction
Transfer ownership to the approved successor and validate permissions and notifications.
Change date and access date disagree
Evidence
A fictional role change becomes effective on Monday, but old access remains until Friday.
Impact
The account has an unnecessary overlap window.
Correction
Align technical changes with the effective date and document any approved overlap exception.
Core Concept
Compare the Approved State with the Current State
Identity
Which fictional person, service, application, device, sponsor, manager, or owner is changing?
Access
Which roles, groups, direct permissions, shares, local access, privileged roles, and exceptions exist?
Lifecycle
What join, move, leave, suspension, expiration, return, or ownership event occurred, and when is it effective?
Dependencies
Which applications, sessions, devices, factors, resources, services, approvals, and records depend on the identity?
Closure
Which technical tests, owner confirmations, monitoring results, exceptions, and residual risks prove completion?
Leaver and Separation Controls
Eight Questions Before Declaring Closure
Effective-time coordination
When should the fictional account, role, device, session, and application access change?
Evidence
Approved separation time, owner, manager, identity team, application owners, and timezone.
Account disablement
Which fictional directories, applications, services, local accounts, and privileged identities must be disabled or expired?
Evidence
Account inventory, status changes, timestamps, owner, and error results.
Session revocation
Which fictional browser, application, mobile, administrative, service, or remembered sessions remain active?
Evidence
Session inventory, revocation state, application confirmation, and post-change sign-in attempts.
Role and group removal
Which fictional direct, inherited, nested, temporary, privileged, resource, and application-local access paths must end?
Evidence
Before-and-after effective-access records, group changes, role changes, shares, and local permissions.
Device and factor lifecycle
Which fictional devices, certificates, authenticators, keys, recovery methods, or registered factors require transfer or revocation?
Evidence
Device inventory, factor inventory, owner, return state, revocation, and replacement record.
Resource and data transfer
Who becomes the fictional owner of reports, folders, applications, services, approvals, and project records?
Evidence
Successor owner, transfer time, resource list, access validation, and communication.
Retention and deletion
Which fictional account records, logs, files, messages, or service data must be retained, archived, transferred, or removed?
Evidence
Approved policy, owner, retention period, legal or business requirement, and deletion validation.
Business closure
Which fictional manager, application owner, resource owner, and security reviewer confirm the separation is complete?
Evidence
Technical validation, denied-access tests, owner confirmation, exceptions, monitoring, and residual risk.
Evidence Matrix
What Lifecycle Evidence Can and Cannot Prove
Evidence source
Human-resources or sponsor event
Can support
The fictional join, transfer, leave, project, contract, or ownership event and its effective date.
Limitation
The event may not describe every application, role, resource, device, or session affected.
Evidence source
Directory account record
Can support
The fictional account identifier, owner, manager, department, status, groups, roles, creation, disablement, and expiration.
Limitation
Application-local permissions, external shares, local accounts, and active sessions may remain elsewhere.
Evidence source
Access request and approval
Can support
The fictional purpose, resource, action, role, duration, requester, sponsor, approver, and expected outcome.
Limitation
The implemented access can differ from the approved request.
Evidence source
Application and resource inventory
Can support
The fictional applications, reports, folders, services, devices, resources, owners, and local permissions connected to the identity.
Limitation
Inventories may be incomplete or stale and may not show current session state.
Evidence source
Authentication and session records
Can support
The fictional sign-ins, factors, devices, applications, active sessions, revocation, and post-change access attempts.
Limitation
No recent sign-in does not prove the account has no access or no active token.
Evidence source
Change and deprovisioning records
Can support
The fictional account, role, group, permission, device, session, factor, ownership, and resource changes performed.
Limitation
A closed ticket does not prove every target system applied the change successfully.
Evidence source
Access-review decision
Can support
The fictional owner’s retain, reduce, remove, transfer, suspend, or investigate decision and rationale.
Limitation
The owner may lack understandable permission details or complete technical evidence.
Evidence source
Validation and monitoring
Can support
The fictional required access, denied access, session cleanup, resource transfer, application state, owner confirmation, and residual risk.
Limitation
One successful test may miss delayed synchronization, alternate access paths, and future reactivation.
Access Review Failures
Eight Problems That Make Recertification Unreliable
Rubber-stamp approval
Evidence
A fictional owner approves every account in a large review within seconds without opening permission details.
Concern
The decision may not reflect current purpose, resource sensitivity, inherited access, or role conflicts.
Correction
Provide understandable permission summaries, require rationale for high-risk access, and reissue the affected decisions.
Unknown owner
Evidence
A fictional service account and two application roles have no current accountable owner.
Concern
No one can reliably confirm purpose, dependencies, rotation, review, or removal.
Correction
Assign an investigation owner, restrict risk where safe, identify dependencies, and establish a removal or transfer deadline.
Review covers only central roles
Evidence
The fictional review excludes application-local editor access, folder shares, and nested groups.
Concern
The owner can approve an incomplete picture while effective access remains broader.
Correction
Expand the review to direct, inherited, local, resource, session, service, and exception paths.
Temporary access lacks expiration
Evidence
A fictional project role is marked temporary but has no technical end date.
Concern
The access can remain indefinitely after the project ends.
Correction
Add an owner-approved expiration, automatic removal, session cleanup, and post-expiration validation.
Leaver ticket closes early
Evidence
The fictional central account is disabled, but one application account and two active sessions remain.
Concern
The identity can still access protected resources after the separation event.
Correction
Reopen the workflow, remove local access, revoke sessions, test denial, and review similar applications.
Mover adds without removing
Evidence
A fictional user receives a new department role while old department groups remain.
Concern
Privilege accumulates across job changes.
Correction
Use an old-state versus new-state comparison and remove access that no longer matches the role.
Dormant account treated as harmless
Evidence
A fictional enabled account has no expected activity for six months but retains report-export access.
Concern
Unused access remains available without a current operational reason.
Correction
Confirm ownership and need, suspend or disable through approval, review sessions and factors, and validate dependencies.
Resource ownership remains behind
Evidence
A fictional leaver’s account is disabled but still owns shared reports and approval workflows.
Concern
Business processes, sharing decisions, and future access reviews route to an inactive identity.
Correction
Transfer ownership to an approved successor and validate resource access, notifications, and approvals.
Lifecycle Validation
Eight Tests for Joiner, Mover, and Leaver Changes
Required access succeeds
Confirm the fictional joiner or mover can complete the approved sign-in and business workflow.
Fictional example
A newly assigned reviewer can view and comment on the required project report.
Successful result
The correct account, role, application, resource, and session support the expected workflow.
Excess access remains denied
Confirm the fictional identity cannot perform unrelated, previous-role, privileged, or restricted actions.
Fictional example
The reviewer cannot export administrator data or open the former department workspace.
Successful result
Every denied action produces the expected policy result and no alternate path works.
Temporary expiration works
Confirm a fictional temporary role, account, share, or exception ends at the approved time.
Fictional example
A project-editor role expires after fourteen days.
Successful result
The role is removed, sessions refresh, and the protected action is denied.
Session cleanup works
Confirm lifecycle changes affect existing fictional sessions and remembered devices.
Fictional example
A disabled leaver account cannot continue through a previously active application session.
Successful result
Identity and application sessions are revoked or refreshed across the relevant systems.
Application-local cleanup works
Confirm fictional local roles, shares, editors, owners, and service permissions match the central lifecycle decision.
Fictional example
A former editor is removed inside the learning application after the central role changes.
Successful result
The application denies the old action and records the current owner and role.
Ownership transfer works
Confirm fictional reports, folders, services, approval queues, and groups have an active successor owner.
Fictional example
A departing project lead’s reports move to the approved new project owner.
Successful result
The successor can manage the resources and the inactive identity no longer owns them.
Dormant-account control works
Confirm a fictional dormant or orphaned account can be suspended or disabled without breaking an approved dependency.
Fictional example
An unused service account is disabled during a controlled observation window.
Successful result
No approved service fails, and the account remains unable to authenticate or access resources.
Review closure is complete
Confirm every fictional retain, reduce, remove, transfer, suspend, expire, investigate, or exception decision has evidence and an owner.
Fictional example
The quarterly access review has no unresolved high-risk item without a due date and accountable owner.
Successful result
Technical state, business validation, monitoring, exceptions, and residual risk are documented.
Defensive Workflow
Review a Lifecycle Event in Six Steps
Identify the lifecycle event
Determine whether the fictional identity is joining, moving, leaving, expiring, suspending, returning, or changing ownership.
Inventory the identity footprint
List accounts, roles, groups, applications, resources, devices, factors, sessions, ownership, shares, and local access.
Compare approved and current state
Match purpose, owner, job or service function, permissions, duration, effective date, and review evidence.
Decide and remediate
Retain, reduce, remove, transfer, suspend, expire, investigate, or document a temporary exception.
Validate every system
Check required access, denied access, sessions, factors, devices, application-local permissions, resources, and ownership.
Close and monitor
Record owners, evidence gaps, exceptions, due dates, residual risk, monitoring, and closure criteria.
Key Vocabulary
Account Lifecycle and Access Review Terms
Joiner
A fictional person, service, or workload entering an organization or environment and receiving approved accounts and access.
Mover
A fictional identity whose job, project, department, responsibility, device, owner, or service purpose changes.
Leaver
A fictional identity ending employment, enrollment, contract, project participation, service ownership, or workload use.
Lifecycle event
A fictional change that should create, modify, suspend, expire, disable, transfer, review, or remove accounts and access.
Access review
A structured fictional process in which accountable owners decide whether access should be retained, reduced, removed, transferred, or investigated.
Recertification
A periodic fictional confirmation that an account, role, group, permission, device, application, and resource relationship is still required and correct.
Dormant account
A fictional account that remains enabled or retained but shows little or no expected activity.
Orphaned account
A fictional account with no valid active owner, sponsor, workload, manager, or review path.
Stale access
Fictional access that remains after the approved purpose, role, project, duration, or ownership has changed.
Suspension
A controlled fictional state that temporarily blocks normal account access while preserving evidence and review options.
Deprovisioning
The approved fictional process of disabling, removing, transferring, expiring, or revoking accounts, access, sessions, devices, and application relationships.
Closure criteria
The evidence required to show that the fictional lifecycle change is technically complete, business-validated, monitored, and documented.
Fake Dashboard
Fake Account Lifecycle and Access Review Dashboard
Training dashboard for the fictional Northstar Learning Services identity environment.
Lifecycle events
44
Twelve joiners, ten movers, eight leavers, six temporary expirations, four suspensions, two service-owner changes, and two reactivations.
Review findings
13
Privilege accumulation, stale project access, local-role gaps, dormant accounts, orphaned service identities, session gaps, and ownership-transfer issues.
Validated closures
37
Each includes required-access tests, denied-access tests, session review, local-access review, owner confirmation, and residual risk.
Fake SOC Alert
Mover Receives New Analytics Access but Retains Former Department Permissions
Source: Fake Identity Lifecycle Review Console • Time: 10:05 AM
Fake Log Panel
Fake Mover Access-Remediation Timeline
DAY0 09:00 MOVER user='training-mchen' old_team='student-services' new_team='learning-analytics' DAY0 09:10 APPROVAL add_role='analytics-reviewers' DAY0 09:20 OLD_OWNER remove_role='student-services-editors' remove_export='true' DAY0 10:00 DIRECTORY analytics_reviewers='added' student_services_editors='still_present' DAY0 10:05 APPLICATION old_case_editor='allow' new_analytics_view='allow' DAY0 10:15 REVIEW finding='privilege_accumulation' DAY0 10:25 OWNER_DECISION remove_old_access='approved' DAY0 10:30 CHANGE central_old_role='removed' local_case_editor='removed' DAY0 10:31 SESSION action='revoke_and_refresh' DAY0 10:35 TEST analytics_view='allow' dashboard_comment='allow' DAY0 10:36 TEST old_case_edit='deny' student_export='deny' DAY0 11:00 OWNERSHIP old_reports='transferred' DAY7 MONITORING alternate_old_access='none' DAY30 RECERTIFICATION closure='approved'
Training note: this is fake data for defensive analysis practice only.
Analyze the Evidence
Which Lifecycle Conclusion Is Best Supported?
Which conclusion is strongest?
Common Mistakes
Mistakes That Weaken Lifecycle Governance
Safe Practice Lab
Review a Fictional Joiner-Mover-Leaver Packet
Fictional Environment
Meadowbrook Identity Lifecycle Review
Review thirty-four supplied fictional records involving joiners, movers, leavers, temporary accounts, dormant identities, service accounts, groups, roles, local permissions, sessions, devices, factors, resources, owners, approvals, retention, and validation.
Required Analysis
- Identify each fictional lifecycle event, effective date, sponsor, manager, service owner, and resource owner.
- Inventory accounts, roles, groups, permissions, applications, sessions, devices, factors, resources, shares, and ownership.
- Compare approved purpose and duration with current technical access.
- Classify retain, reduce, remove, transfer, suspend, expire, investigate, and exception decisions.
- Find privilege accumulation, stale access, dormant accounts, orphaned identities, local-access gaps, and incomplete ownership transfer.
- Propose narrow owner-approved remediation with preserved evidence, rollback, communication, and due dates.
- Validate required access, denied access, sessions, local permissions, resource transfer, monitoring, residual risk, and closure.
Scenario Decision Lab
A Mover Keeps Old Department Access
A fictional employee transfers to a new team. The new role is assigned, but the old central group, local editor permission, and active application session remain.
Scenario Decision Lab
A Leaver Account Is Disabled but an Application Session Remains
A fictional separation workflow disables the central account at the approved time. One application-local account and an older browser session still provide report access.
Defender Habits
Account Lifecycle and Access Review Checklist
Check Your Understanding
I6.6 Mini Quiz: Account Lifecycle and Access Reviews
Choose your answers first. Explanations appear only after submission.
1. What is a mover event?
2. What is privilege accumulation?
3. What makes an account orphaned?
4. Why must leaver workflows include session revocation?
5. What is the strongest access-review decision for incomplete ownership evidence?
6. Which mover validation plan is strongest?
7. What should an access-review owner receive?
Portfolio Prompt
Portfolio Prompt
Create a fictional Account Lifecycle and Access Review Report containing at least thirty-four joiner, mover, leaver, temporary-access, dormant-account, service-owner, account, role, group, permission, application, session, device, factor, resource, ownership, approval, retention, and validation records. Include approved-state versus current-state comparisons, privilege accumulation, stale access, orphaned identities, application-local gaps, resource transfer, retain/reduce/remove/transfer/suspend/expire/investigate/exception decisions, narrow remediation, rollback, positive tests, negative tests, monitoring, residual risk, and closure criteria.
Key Takeaways
What You Should Remember
Navigation