Lesson Twenty

Identity Provisioning, Access Reviews, Privileged Access, and Account Lifecycle

SierraTec Secure CISSP Certification Preparation Course

Lesson Overview

Creating an account is easy.

Managing that account securely throughout its entire lifetime is much harder.

An employee may join the organization as an accounting clerk, later become a supervisor, transfer to procurement, receive temporary administrative privileges for a project, and eventually leave the organization.

During that journey, the organization must continuously answer:

Does this identity still need every permission it currently possesses?

If access is continually added but rarely removed, the result is:

• privilege accumulation;

• access creep;

• dormant accounts;

• orphan accounts;

• excessive service-account permissions;

• unnecessary administrative access;

• weak accountability.

Identity and Access Management therefore requires lifecycle control.

The lifecycle is not:

CREATE ACCOUNT

     ↓

FORGET ABOUT IT

It is:

BUSINESS NEED

     ↓

IDENTITY

     ↓

APPROVAL

     ↓

PROVISION

     ↓

USE

     ↓

MONITOR

     ↓

REVIEW

     ↓

MODIFY

     ↓

REVOKE

     ↓

DEPROVISION

The current CISSP Examination Outline places this lesson primarily under Domain 5, Objective 5.5 — Manage the identity and access provisioning lifecycle.

ISC2 currently identifies five major areas:

• account-access reviews for users, systems, and services;

• provisioning and deprovisioning, including onboarding, offboarding, and transfers;

• role definition and transition;

• privilege escalation, including sudo and auditing privileged use;

• service-account management.

This lifecycle approach is consistent with NIST SP 800-53 account-management principles. NIST's current control materials require organizations to manage account creation, modification, disablement, removal, monitoring, access authorization, account review, and coordination with personnel transfer and termination processes.

The central Lesson Twenty question is:

How should identities and privileges be created, approved, reviewed, changed, elevated, monitored, and removed so that users, systems, services, and administrators possess only the access that remains legitimately required?

CISSP Exam Objective Alignment

Learning Objectives

After completing this lesson, you should be able to:

1. Explain the identity-access lifecycle.

2. Describe Joiner-Mover-Leaver processes.

3. Explain authoritative identity sources.

4. Explain onboarding.

5. Explain provisioning.

6. Explain birthright access.

7. Explain request-based access.

8. Explain approval-based access.

9. Explain entitlement assignment.

10. Explain group-based provisioning.

11. Explain role-based provisioning.

12. Explain automated provisioning.

13. Explain manual provisioning risks.

14. Explain role transitions.

15. Explain access creep.

16. Explain privilege accumulation.

17. Explain transfer procedures.

18. Explain deprovisioning.

19. Explain planned termination.

20. Explain emergency termination.

21. Distinguish disabling an account from deleting an account.

22. Define dormant accounts.

23. Define orphan accounts.

24. Explain temporary accounts.

25. Explain emergency/break-glass accounts.

26. Explain access reviews.

27. Explain access certification.

28. Explain recertification.

29. Explain manager access reviews.

30. Explain application-owner reviews.

31. Explain data-owner reviews.

32. Explain privileged-account reviews.

33. Explain service-account reviews.

34. Explain separation-of-duty review.

35. Explain risk-based review frequency.

36. Explain privilege escalation.

37. Explain sudo.

38. Explain why direct root usage should be restricted.

39. Explain privileged-session auditing.

40. Explain PAM.

41. Explain credential vaulting.

42. Explain Just-In-Time privilege.

43. Explain Just Enough Administration conceptually.

44. Explain approval workflows for privileged access.

45. Explain break-glass access.

46. Explain privileged-account monitoring.

47. Explain service accounts.

48. Explain service-account ownership.

49. Explain service-account least privilege.

50. Explain service-account credential rotation.

51. Explain workload and machine identities.

52. Explain managed identities.

53. Explain secrets management.

54. Explain lifecycle automation.

55. Explain SCIM's provisioning role.

56. Explain identity reconciliation.

57. Explain failed deprovisioning risks.

58. Explain lifecycle governance.

59. Explain IAM lifecycle metrics.

60. Apply CISSP-style reasoning to account-lifecycle scenarios.

Part I — Identity Is a Lifecycle

1. Accounts Should Follow Business Need

An account should exist because:

A legitimate business or mission requirement exists.

Not because:

“We create these accounts for everyone just in case.”

2. Lifecycle Principle

BUSINESS REQUIREMENT

       │

       ▼

IDENTITY ESTABLISHED

       │

       ▼

ACCESS APPROVED

       │

       ▼

ACCESS PROVISIONED

       │

       ▼

ACCESS USED

       │

       ▼

ACCESS REVIEWED

       │

       ▼

ACCESS CHANGED

       │

       ▼

ACCESS TERMINATED

3. Access Must Change With Reality

When the user's:

• employment;

• responsibilities;

• project;

• risk;

• contract;

• system role

changes, access should change too.

Part II — Joiner-Mover-Leaver

4. JML

A common lifecycle model is:

Joiner — Mover — Leaver

JOINER

New relationship

     │

     ▼

MOVER

Role/status changes

     │

     ▼

LEAVER

Relationship ends

5. Joiner

A joiner is a newly authorized:

• employee;

• contractor;

• partner;

• service identity.

The key question is:

What access is necessary on day one?

6. Mover

A mover changes:

• job role;

• department;

• project;

• location;

• responsibility.

The important security question is:

What old access should be removed as new access is granted?

7. Leaver

A leaver's legitimate relationship ends.

The question becomes:

How quickly and completely should access be removed?

Part III — The Authoritative Identity Source

8. Where Does Identity Truth Come From?

An IAM system needs an authoritative source identifying:

• who the person is;

• whether they are active;

• role;

• department;

• employment status.

For employees, this is often:

the Human Resources system.

9. Example

HR SYSTEM

Authoritative employee status

       │

       ▼

IAM PLATFORM

       │

       ├── Directory

       ├── Email

       ├── Applications

       └── Cloud Services

10. Why Authoritative Sources Matter

Without a reliable authoritative source, access may remain active after:

• termination;

• transfer;

• contract expiration.

Part IV — Identity Governance

11. IAM Is Not Merely IT Administration

The business determines:

who requires access.

IAM implements and governs:

how that access is delivered.

12. Important Roles

Lifecycle governance can involve:

• HR;

• manager;

• data owner;

• application owner;

• IAM team;

• security;

• audit.

Part V — Onboarding

13. Onboarding

Onboarding establishes appropriate access for a new identity.

EMPLOYEE HIRED

      │

      ▼

IDENTITY CREATED

      │

      ▼

ROLE IDENTIFIED

      │

      ▼

ACCESS APPROVED

      │

      ▼

ACCOUNTS PROVISIONED

      │

      ▼

AUTHENTICATORS ENROLLED

14. Goal

Provide enough access to perform assigned duties.

Not:

every permission the employee might someday need.

Part VI — Provisioning

15. Provisioning

Provisioning creates or configures:

• accounts;

• roles;

• group memberships;

• entitlements;

• credentials.

16. Provisioning Example

New Finance Analyst:

IDENTITY

   │

   ├── Email

   ├── Finance Portal

   ├── Reporting System

   └── Finance Group

But not:

DOMAIN ADMIN

DATABASE ADMIN

HR ADMIN

Part VII — Birthright Access

17. Birthright Access

Birthright access is automatically granted because of a basic relationship or identity condition.

Examples:

All employees receive:

• email;

• intranet;

• basic collaboration tools.

18. Birthright Does Not Mean Unlimited

Birthright access should represent:

common minimal access.

Sensitive systems should normally require additional authorization.

Part VIII — Request-Based Access

19. Additional Access

Access outside basic entitlement may require:

USER REQUEST

     │

     ▼

BUSINESS JUSTIFICATION

     │

     ▼

APPROVAL

     │

     ▼

PROVISION

20. Why Approval Matters

An IAM administrator may know:

how to grant database access.

The manager or data owner should determine:

whether the access is legitimately required.

Part IX — Ownership of Approval

21. Manager

Manager may confirm:

job responsibility.

22. Data Owner

Data owner may confirm:

legitimate need to access sensitive information.

23. Application Owner

Application owner may confirm:

appropriate application role.

Part X — Provisioning by Group

24. Group-Based Provisioning

Instead of:

Alice → App1 permission

Alice → App2 permission

Alice → App3 permission

assign:

Alice

  │

  ▼

Finance Group

  │

  ├── App1

  ├── App2

  └── App3

25. Benefit

This improves:

• consistency;

• reviewability;

• scalability.

Part XI — Role-Based Provisioning

26. Roles

Lesson Nineteen introduced:

USER

 ↓

ROLE

 ↓

PERMISSIONS

Provisioning converts this authorization model into operational access.

27. Example

Role:

Accounts Payable Clerk

Automatically provisions:

• invoice-processing application;

• vendor-view access;

• payment-entry privilege.

But excludes:

final payment approval.

This supports separation of duties.

Part XII — Manual Provisioning

28. Manual Process

EMAIL REQUEST

     │

     ▼

ADMIN READS REQUEST

     │

     ▼

ADMIN CHANGES ACCOUNT

29. Manual Risks

Manual processes may create:

• delays;

• inconsistent permissions;

• errors;

• poor evidence;

• forgotten deprovisioning.

Part XIII — Automated Provisioning

30. Automation

HR EVENT

  │

  ▼

IAM WORKFLOW

  │

  ├── Create directory identity

  ├── Assign baseline role

  ├── Create email

  └── Provision applications

31. Benefit

Automation can improve:

• consistency;

• speed;

• auditability;

• revocation.

NIST AC-2 includes automated mechanisms as an account-management enhancement and expects organizations to create, enable, modify, disable, and remove accounts according to defined processes.

Part XIV — Automation Does Not Eliminate Governance

32. Important Principle

Automating the wrong rule means:

incorrect access is delivered faster.

Automation still requires:

• approved policy;

• role design;

• testing;

• monitoring.

Part XV — The Mover Problem

33. Role Transition

Suppose Alice changes from:

Accounts Payable

to:

Human Resources.

Weak process:

OLD FINANCE ACCESS

       +

NEW HR ACCESS

       =

BOTH

34. Correct Transition

CURRENT ROLE REVIEW

       │

       ▼

REMOVE OBSOLETE RIGHTS

       │

       ▼

ASSIGN NEW ROLE

       │

       ▼

VERIFY

Part XVI — Access Creep

35. Access Creep

Access creep occurs when permissions accumulate as users change roles without old permissions being removed.

36. Example

YEAR 1

Finance Access



YEAR 2

Finance + Procurement



YEAR 3

Finance + Procurement + HR



YEAR 4

Manager + all previous permissions

37. Risk

A compromised account gains:

a much larger attack surface.

Part XVII — Privilege Accumulation

38. Privilege Accumulation

Access creep involving elevated permissions can be particularly dangerous.

An employee might unintentionally retain:

• server administration;

• cloud administration;

• database administration.

Part XVIII — Role Transition Controls

39. Mover Workflow

ROLE CHANGE

    │

    ▼

IDENTIFY NEW RESPONSIBILITY

    │

    ▼

COMPARE CURRENT ACCESS

    │

    ▼

REMOVE INCOMPATIBLE RIGHTS

    │

    ▼

ADD REQUIRED RIGHTS

    │

    ▼

REVIEW SoD

    │

    ▼

CONFIRM

Part XIX — Do Not Only Add

40. CISSP Principle

A transfer event should trigger both:

Addition

and:

Removal.

Part XX — Temporary Access

41. Temporary Entitlements

Some access is required only for:

• project;

• maintenance;

• audit;

• emergency.

42. Expiration

Temporary access should have:

a defined expiration.

ACCESS GRANTED

    │

    ▼

START DATE

    │

    ▼

AUTHORIZED PERIOD

    │

    ▼

AUTOMATIC EXPIRATION

Part XXI — Time-Limited Access

43. Why Time Limits Help

Without automatic expiration:

temporary access often becomes permanent.

Part XXII — Offboarding

44. Offboarding

Offboarding removes access when a business relationship ends.

45. Offboarding Scope

Think beyond:

Disable Windows account.

Also consider:

• SaaS;

• VPN;

• cloud;

• badges;

• tokens;

• certificates;

• privileged vaults;

• local accounts;

• remote access;

• API keys.

Part XXIII — Planned Termination

46. Normal Departure

For a scheduled departure:

TERMINATION DATE

      │

      ▼

COORDINATED WORKFLOW

      │

      ├── Disable identity

      ├── Revoke remote access

      ├── Remove groups

      ├── Recover assets

      └── Transfer ownership

Part XXIV — Emergency Termination

47. High-Risk Departure

Some situations require:

immediate coordinated access termination.

Examples may include:

• hostile termination;

• confirmed insider threat;

• compromised privileged identity.

48. Timing Matters

The account should not remain enabled because:

“IT will process the ticket tomorrow.”

Part XXV — Coordinated Termination

49. Multiple Teams

Emergency termination may involve:

HR

 │

SECURITY

 │

IAM

 │

PHYSICAL SECURITY

 │

IT OPERATIONS

Coordination helps prevent gaps.

Part XXVI — Disable Versus Delete

50. Disable

Disabling prevents normal use while retaining the account record.

Benefits may include:

• investigation;

• ownership transfer;

• recovery.

51. Delete

Deletion permanently removes the account or object from the system.

52. CISSP Reasoning

Immediate deletion is not always the best first action.

Often:

disable first, preserve evidence or ownership information, then remove according to policy.

Part XXVII — Transfer Ownership

53. Former Employee-Owned Resources

Before deletion, determine ownership of:

• files;

• cloud resources;

• automation;

• shared mailboxes;

• encryption materials.

Part XXVIII — Dormant Accounts

54. Dormant Account

A dormant account has not been used for an extended period but remains enabled.

55. Why Attackers Like Them

The legitimate owner may not notice:

unauthorized use.

56. Control

NIST AC-2 includes disabling expired, unassociated, policy-violating, or inactive accounts according to organization-defined time periods.

Part XXIX — Orphan Accounts

57. Orphan Account

An orphan account has no valid accountable owner.

Examples:

• former employee account;

• forgotten service account;

• contractor account after contract completion.

58. Orphan Risk

If no one owns the account:

who reviews its permissions?

Part XXX — Temporary Accounts

59. Temporary Account

Created for a limited operational purpose.

Examples:

• external auditor;

• short project;

• testing engagement.

60. Best Practice

Temporary accounts should:

• have expiration;

• minimum privilege;

• defined owner;

• be monitored.

NIST AC-2 includes automatic disablement or removal of temporary and emergency accounts after defined periods as an account-management enhancement.

Part XXXI — Access Reviews

61. Account Access Review

Current CISSP Objective 5.5 explicitly includes account-access review for:

• users;

• systems;

• services.

62. Fundamental Review Question

Does this identity still require this access?

Part XXXII — Access Certification

63. Certification

Access certification is a formal review in which appropriate personnel confirm that assigned access remains legitimate.

64. Example

USER

Alice

   │

   ├── Finance Portal

   ├── Payroll Reports

   └── Procurement Admin

             │

             ▼

MANAGER REVIEW

             │

      ┌──────┴──────┐

      ▼             ▼

   APPROVE        REVOKE

Part XXXIII — Recertification

65. Recertification

Access should be periodically reexamined rather than assumed permanently correct.

66. Risk-Based Frequency

High-risk access may deserve:

more frequent review.

Example:

• ordinary intranet access → lower risk;

• domain administrator → higher risk.

Part XXXIV — Reviewers

67. Manager Review

Manager verifies:

Does this employee still perform this job?

68. Application Owner Review

Application owner verifies:

Should the user retain this application role?

69. Data Owner Review

Data owner verifies:

Does the user still have legitimate need for sensitive data?

Part XXXV — Security Team Role

70. Security Supports Governance

Security may:

• identify risk;

• design review process;

• monitor exceptions.

But business/data owners often know:

whether access is legitimately required.

Part XXXVI — Review Evidence

71. Auditability

A review should demonstrate:

• who reviewed;

• when;

• what access was reviewed;

• decision;

• remediation.

Part XXXVII — Rubber-Stamp Reviews

72. Weak Review

Manager receives:

1,500 entitlements

and clicks:

Approve All.

The process technically occurred but may provide little assurance.

73. Better Review Design

Provide:

• understandable entitlement descriptions;

• risk ranking;

• role context;

• unusual access indicators.

Part XXXVIII — Separation-of-Duty Review

74. Review Conflicting Access

Example:

CREATE PAYMENT

      +

APPROVE PAYMENT

      =

SoD CONFLICT

Lifecycle reviews should identify toxic combinations.

Part XXXIX — Privileged Account Review

75. Privileged Access Requires Special Attention

Review:

• administrators;

• root-equivalent accounts;

• cloud administrators;

• database administrators;

• security administrators.

76. NIST Principle

NIST's current AC-2 material calls for monitoring privileged role or attribute assignments and revoking privileged access when those assignments are no longer appropriate.

Part XL — Least Privilege Review

77. Review Question

Not:

“Does Alice use the account?”

But:

“Does Alice require every privilege inside this account?”

78. Current NIST Alignment

NIST AC-6 defines least privilege around restricting users and processes to the minimum system authorizations necessary to perform assigned tasks.

Part XLI — Privilege Escalation

79. What Is Privilege Escalation?

Privilege escalation means moving from a lower privilege level to a higher one.

It can be:

Legitimate

Administrator performs approved maintenance.

Malicious

Attacker exploits a vulnerability to become administrator.

Objective 5.5 focuses primarily on securely managing legitimate escalation.

Part XLII — Standing Privilege

80. Standing Privilege

A user permanently possesses elevated access:

ADMINISTRATOR

       │

       ▼

PRIVILEGE 24/7

81. Risk

The privilege exists even when:

not needed.

If the account is compromised, the attacker immediately gains that standing authority.

Part XLIII — Temporary Privilege

82. Better Alternative Where Appropriate

STANDARD ACCOUNT

      │

      ▼

REQUEST

      │

      ▼

APPROVAL

      │

      ▼

TEMPORARY ELEVATION

      │

      ▼

TASK COMPLETE

      │

      ▼

PRIVILEGE REMOVED

Part XLIV — sudo

83. sudo

The current CISSP exam outline specifically lists use of sudo and auditing its use under privilege escalation.

sudo can allow an authorized user to execute specified commands with elevated privileges without routinely operating an entire session as the superuser.

84. Conceptual Model

NORMAL USER

    │

    ▼

sudo approved-command

    │

    ▼

POLICY CHECK

    │

 ┌──┴───┐

ALLOW  DENY

  │

  ▼

ELEVATED COMMAND

Part XLV — Why sudo Can Improve Control

85. Benefits

Compared with universally sharing a root password, controlled privilege elevation can support:

• individual attribution;

• limited command rights;

• logging;

• least privilege.

Part XLVI — Direct Root Usage

86. Weak Model

5 ADMINS

    │

    ▼

SHARED ROOT PASSWORD

Problems:

• poor accountability;

• broad privilege;

• difficult revocation.

87. Better Model

INDIVIDUAL ADMIN

      │

      ▼

AUTHENTICATE

      │

      ▼

CONTROLLED ELEVATION

      │

      ▼

AUDITED COMMAND

Part XLVII — Auditing Privilege Escalation

88. What Should Be Recorded?

Where technically and legally appropriate:

• identity;

• time;

• target;

• command/activity;

• outcome.

89. Why?

Privileged auditing supports:

• accountability;

• incident response;

• investigation;

• deterrence.

Part XLVIII — Privileged Access Management

90. PAM

Privileged Access Management controls high-risk administrative access.

Possible functions include:

• credential vaulting;

• password rotation;

• approval workflow;

• JIT access;

• session recording;

• command control.

Part XLIX — PAM Architecture

91.

ADMINISTRATOR

      │

      ▼

PAM PLATFORM

      │

      ├── Authenticate

      ├── Approve

      ├── Retrieve credential

      ├── Record session

      └── Expire privilege

      │

      ▼

TARGET SYSTEM

Part L — Credential Vaulting

92. Vault

Privileged credentials can be stored in a protected vault rather than distributed among administrators.

93. Checkout Model

ADMIN REQUEST

      │

      ▼

APPROVAL

      │

      ▼

VAULT RELEASE / BROKER

      │

      ▼

SESSION

      │

      ▼

PASSWORD ROTATED

Part LI — Protect the Vault

94. High-Value Asset

A PAM vault can contain:

• domain credentials;

• database passwords;

• device credentials.

Therefore it becomes:

critical security infrastructure.

Part LII — Just-In-Time Privilege

95. JIT

JIT provides elevated access only:

• when needed;

• for limited duration.

Lesson Seventeen introduced the concept.

96. Security Benefit

PERMANENT ADMIN

Large exposure window



versus



JIT ADMIN

Small exposure window

Part LIII — Just Enough Administration

97. JEA Concept

Just Enough Administration means:

grant only the administrative capabilities necessary for the specific task.

98. JIT + JEA

JIT

How long?



JEA

How much?

Together:

limited privilege for limited time.

Part LIV — Approval Workflow

99. Privileged Request

High-risk privilege may require:

REQUEST

  │

  ▼

JUSTIFICATION

  │

  ▼

APPROVER

  │

  ▼

TIME-LIMITED PRIVILEGE

Part LV — Dual Authorization

100. Sensitive Operations

Some extremely sensitive activities may require two authorized individuals.

Examples:

• critical key-management operations;

• highly sensitive production changes.

This supports separation of duties.

Part LVI — Break-Glass Accounts

101. Emergency Access

A break-glass account exists for exceptional emergencies such as:

• primary identity system failure;

• administrative lockout.

102. Break-Glass Design

NORMAL OPERATIONS

       │

       X

IDENTITY SYSTEM FAILURE

       │

       ▼

BREAK-GLASS ACCOUNT

       │

       ▼

EMERGENCY RECOVERY

Part LVII — Break-Glass Security

103. Protect Heavily

Break-glass accounts should generally be:

• highly protected;

• rarely used;

• monitored;

• tested;

• reviewed after use.

104. Do Not Confuse Emergency With Shared Convenience

An account should not be labeled:

emergency

merely to avoid normal governance.

Part LVIII — Service Accounts

105. Service Account

The current Objective 5.5 explicitly includes:

Service-account management.

Service accounts support:

• applications;

• databases;

• scheduled tasks;

• middleware;

• automation.

Part LIX — Why Service Accounts Are Dangerous

106. Common Weaknesses

Service accounts often:

• have long-lived passwords;

• receive excessive permissions;

• are poorly inventoried;

• have interactive login enabled unnecessarily;

• remain active after applications are retired.

Part LX — Service Account Ownership

107. Every Service Identity Needs an Owner

Record:

• business owner;

• technical owner;

• purpose;

• system;

• required privileges.

108. Bad Example

Account:

svc_oldapp

Owner:

Unknown

Purpose:

Unknown

Password age:

Six years

Privilege:

Domain Administrator

This is a serious governance failure.

Part LXI — Service Account Least Privilege

109. Example

Application needs:

Read one database table.

Do not grant:

database administrator.

110. NIST Alignment

NIST explicitly applies least privilege to processes acting on behalf of users, not only to human identities.

Part LXII — Interactive Login

111. Restrict Where Unnecessary

A service account designed only for automated processing may not need:

interactive desktop login.

Reducing unnecessary functionality reduces misuse opportunities.

Part LXIII — Credential Rotation

112. Long-Lived Secret

A service password that never changes creates increasing exposure.

113. Rotation

GENERATE

  │

  ▼

STORE SECURELY

  │

  ▼

USE

  │

  ▼

ROTATE

  │

  ▼

REVOKE

Part LXIV — Rotation Challenges

114. Hard-Coded Password

If an application contains:

password = "Secret123"

rotation becomes operationally difficult.

This encourages insecure static credentials.

Part LXV — Secrets Management

115. Better Design

APPLICATION

     │

     ▼

SECRETS SERVICE

     │

     ▼

AUTHORIZED SECRET

Secrets-management platforms can help control:

• storage;

• retrieval;

• rotation;

• auditing.

Part LXVI — Managed Identities

116. Modern Alternative

Some cloud/platform environments support managed workload identities where applications obtain temporary identity credentials without administrators distributing a static password.

117. Security Benefit

Reduce:

• embedded passwords;

• manual credential handling;

• long-lived secrets.

Part LXVII — Machine and Workload Identities

118. Non-Human IAM

Modern environments contain many identities belonging to:

• applications;

• containers;

• virtual machines;

• automation pipelines;

• APIs.

119. Human and Machine Lifecycle

HUMAN IDENTITY

Join → Move → Leave



MACHINE IDENTITY

Deploy → Change → Retire

Both require lifecycle governance.

Part LXVIII — Service Account Review

120. Review Questions

Ask:

• Does the service still exist?

• Who owns it?

• Is the privilege still needed?

• Is interactive access required?

• When was the credential rotated?

Part LXIX — System Accounts

121. Current Objective Includes Systems

ISC2 explicitly includes account-access reviews for:

• users;

• systems;

• services.

Do not assume access review concerns only human users.

Part LXX — Shared Accounts

122. Shared Account

Multiple individuals use the same identity.

123. Primary Problem

Accountability

Who performed the action?

124. NIST Position

NIST account-management guidance recognizes the increased accountability risk associated with shared and group accounts and calls for defined restrictions and management conditions.

Part LXXI — Shared Credential Change

125. Membership Changes

If a shared credential is unavoidable and one authorized member leaves:

the credential may need to change.

Otherwise the former member may retain access.

NIST AC-2 explicitly addresses this lifecycle issue.

Part LXXII — Account Inventory

126. You Cannot Review What You Do Not Know Exists

Organizations should maintain visibility into:

• user accounts;

• service accounts;

• system accounts;

• privileged accounts;

• emergency accounts.

Part LXXIII — Account Discovery

127. Sources

Account discovery can include:

• directories;

• cloud IAM;

• databases;

• applications;

• operating systems;

• SaaS.

Part LXXIV — Identity Reconciliation

128. Reconciliation

Compare:

authoritative identities

against:

actual accounts.

129. Example

HR ACTIVE EMPLOYEES

        │

        ▼

COMPARE

        ▲

        │

DIRECTORY ACCOUNTS

Differences may identify:

• orphan accounts;

• missing accounts;

• incorrect attributes.

Part LXXV — Entitlement Reconciliation

130. Compare Expected Versus Actual

ROLE MODEL

Expected access

      │

      ▼

COMPARE

      ▲

      │

ACTUAL PERMISSIONS

Part LXXVI — Provisioning Drift

131. Drift

Manual changes can cause actual access to differ from the approved IAM model.

132. Example

Role says:

Read Only.

Administrator manually grants:

Administrator.

Periodic reconciliation should identify the difference.

Part LXXVII — SCIM and Lifecycle Automation

133. SCIM Review

Lesson Eighteen introduced SCIM as a provisioning protocol.

Conceptually:

IAM PLATFORM

     │

     │ SCIM

     ▼

SAAS APPLICATION

     │

     ├── Create

     ├── Update

     └── Disable User

134. Authentication Versus Provisioning

Remember:

SAML / OIDC

Authentication / federation



SCIM

Provisioning / lifecycle

Part LXXVIII — The Last-Mile Problem

135. Central Account Disabled, Local Account Remains

Example:

CORPORATE IDENTITY

DISABLED

      │

      X



LOCAL APPLICATION ACCOUNT

STILL ACTIVE

This creates residual access.

136. Solution

Lifecycle processes must identify:

downstream identities and local credentials.

Part LXXIX — Deprovisioning Failure

137. Why It Is Dangerous

Provisioning failure:

User cannot work.

Deprovisioning failure:

Former user may still access systems.

The security consequences can be much greater.

Part LXXX — Access Review Versus Provisioning

138. Provisioning

What access should be granted now?

139. Access Review

Should the existing access still remain?

Both are required.

Part LXXXI — Continuous IAM

140. Mature Lifecycle

PROVISION

   │

   ▼

MONITOR

   │

   ▼

REVIEW

   │

   ▼

ADJUST

   │

   ▼

MONITOR

IAM is continuous rather than one-time.

Part LXXXII — Risk-Based Access Reviews

141. Not All Access Is Equal

A review program may prioritize:

1. privileged accounts;

2. sensitive applications;

3. service accounts;

4. ordinary accounts.

142. High-Risk Indicators

Examples:

• excessive permissions;

• dormant use;

• owner missing;

• privileged role;

• SoD conflict;

• unusual activity.

Part LXXXIII — Review Frequency

143. Risk Determines Frequency

A high-risk privileged role may be reviewed more frequently than:

access to a public intranet.

The CISSP principle is not memorizing one universal interval.

It is:

define review frequency according to risk, policy, and requirements.

Part LXXXIV — Access Certification Campaign

144. Example

IDENTITIES

    │

    ▼

ENTITLEMENTS

    │

    ▼

REVIEWER

    │

    ▼

CERTIFY / REVOKE / MODIFY

    │

    ▼

REMEDIATION

    │

    ▼

EVIDENCE

Part LXXXV — Review Must Lead to Remediation

145. Finding Is Not Enough

If reviewer selects:

Remove access

but no system actually removes the access:

the review failed operationally.

Part LXXXVI — Closed-Loop Governance

146.

REVIEW

   │

   ▼

DECISION

   │

   ▼

REMEDIATION

   │

   ▼

VERIFY

Part LXXXVII — Privileged Activity Monitoring

147. Monitor More Than Login

For high-risk accounts, consider:

• commands;

• configuration changes;

• privilege grants;

• data access;

• session duration.

Part LXXXVIII — Detect Unusual Privilege

148. Example

Administrator normally works:

Monday-Friday 08:00–17:00.

Suddenly:

logs in at 02:30 and creates 50 privileged accounts.

This deserves investigation.

NIST AC-2 includes monitoring accounts for atypical usage as an account-management enhancement.

Part LXXXIX — Privileged Role Changes

149. Monitor Privilege Assignment

A user becoming:

Domain Administrator

should itself be a security-relevant event.

Part XC — Audit Separation

150. Administrator Should Not Control Their Own Evidence

Separation of duties may require separating:

• system administration;

• audit-log administration.

NIST AC-5 specifically identifies separation of system-support and access-control duties from certain audit functions as an example of reducing abuse risk.

Part XCI — Termination Checklist

151. Logical Access

Remove:

• directory accounts;

• cloud accounts;

• VPN;

• email access;

• privileged access.

152. Physical Access

Remove:

• badge;

• keys;

• facility access.

153. Devices

Recover:

• laptop;

• phone;

• tokens;

• smart cards.

154. Application Ownership

Transfer:

• files;

• projects;

• automation;

• shared resources.

Part XCII — Contractor Lifecycle

155. Contractors Need Expiration Dates

Contractor access should reflect:

• contract start;

• contract end;

• approved scope.

156. Extension

If the contract is extended:

extend access through an approved workflow.

Do not create indefinite access on day one.

Part XCIII — Vendor Identities

157. Vendor Account

Vendor access should have:

• sponsor;

• owner;

• purpose;

• expiration;

• limited scope.

Part XCIV — Cloud Identity Lifecycle

158. Cloud Accounts

Cloud identities may include:

• users;

• service principals;

• roles;

• API identities;

• automation identities.

159. Cloud Offboarding

Do not only disable:

local Active Directory

while leaving:

standalone SaaS administrator accounts.

Part XCV — Local Accounts

160. Forgotten Local Access

Central IAM cannot remove an account it does not know exists.

Inventory local:

• server;

• application;

• database;

• appliance accounts.

Part XCVI — Emergency Privilege Escalation

161. Incident Scenario

During an outage, an engineer needs temporary production administrator access.

Secure model:

EMERGENCY

   │

   ▼

REQUEST / BREAK-GLASS

   │

   ▼

TEMPORARY ACCESS

   │

   ▼

AUDIT

   │

   ▼

RECOVER SERVICE

   │

   ▼

REVOKE

   │

   ▼

POST-USE REVIEW

Part XCVII — Emergency Does Not Mean Uncontrolled

162. Critical Principle

Urgency may change:

how quickly approval occurs.

It should not automatically eliminate:

• accountability;

• monitoring;

• review.

Part XCVIII — Identity Lifecycle Metrics

163. Useful Metrics

Examples:

• time to provision;

• time to deprovision;

• number of orphan accounts;

• dormant-account count;

• overdue reviews;

• privileged-account count.

164. Security Value

Metrics help management determine whether IAM governance is actually functioning.

Part XCIX — More Useful Metrics

165. Review Completion Rate

COMPLETED REVIEWS

───────────────── × 100

REQUIRED REVIEWS

166. Revocation Lag

Time between:

termination decision

and:

actual removal of access.

For sensitive environments, excessive lag represents material exposure.

Part C — Lifecycle Metrics Should Drive Improvement

167. Bad Metric

We completed 100% of access reviews.

But:

40% of revocations were never implemented.

Measure outcomes, not only activity.

Part CI — Lifecycle Control Failure Chain

168.

WEAK PROVISIONING

      │

      ▼

EXCESS ACCESS

      │

      ▼

NO ACCESS REVIEW

      │

      ▼

ROLE CHANGE

      │

      ▼

ACCESS CREEP

      │

      ▼

EMPLOYEE LEAVES

      │

      ▼

FAILED DEPROVISIONING

      │

      ▼

ORPHAN PRIVILEGED ACCOUNT

A small governance failure can grow over time.

Part CII — SierraTec Secure ACCESS Framework

169. ACCESS

Use the SierraTec Secure ACCESS model for identity-lifecycle questions.

A — Authoritative Source

Confirm who or what legitimately requires an identity.

C — Create Minimum Access

Provision only what is needed.

C — Change With Role and Risk

Modify access when duties or circumstances change.

E — Examine Regularly

Review users, systems, services, and privileges.

S — Secure Privileged and Service Identities

Apply stronger controls to elevated and non-human accounts.

S — Stop Access Promptly

Deprovision when the legitimate need ends.

Part CIII — ACCESS Diagram

170.

A

AUTHORITATIVE SOURCE

        │

        ▼

C

CREATE MINIMUM ACCESS

        │

        ▼

C

CHANGE WITH ROLE

        │

        ▼

E

EXAMINE REGULARLY

        │

        ▼

S

SECURE PRIVILEGE / SERVICES

        │

        ▼

S

STOP ACCESS

Part CIV — CISSP Scenario 1: Onboarding

171.

A new employee joins the finance department.

What should occur FIRST before application privileges are assigned?

A. Determine the employee's approved role and legitimate access requirements.

B. Grant all finance permissions.

C. Provide domain-administrator rights.

D. Copy the previous employee's account.

Correct Answer

A

Part CV — Scenario 2: Birthright Access

172.

All employees require email and the corporate intranet.

What is the MOST appropriate approach?

A. Define approved baseline/birthright access tied to active employee status.

B. Make every employee an administrator.

C. Use shared accounts.

D. Require manual database-admin approval for email.

Correct Answer

A

Part CVI — Scenario 3: Transfer

173.

An employee moves from Finance to Marketing.

What is the BEST IAM action?

A. Review existing rights, remove obsolete finance access, and provision authorized marketing access.

B. Add marketing access and leave all old permissions.

C. Disable auditing.

D. Create a shared account.

Correct Answer

A

Part CVII — Scenario 4: Access Creep

174.

A long-term employee has permissions from six previous positions.

What is the PRIMARY concern?

A. Access creep.

B. Strong authentication.

C. Network latency.

D. Encryption overhead.

Correct Answer

A

Part CVIII — Scenario 5: Termination

175.

A privileged employee is terminated unexpectedly.

What should happen?

A. Coordinate prompt logical and physical access revocation according to the termination process.

B. Wait until the next quarterly access review.

C. Leave administrator access active for convenience.

D. Only change the employee's email password.

Correct Answer

A

Part CIX — Scenario 6: Disable or Delete

176.

A terminated employee's files must be transferred to a manager and security may need to investigate recent activity.

What is the BEST initial account action?

A. Disable the account while preserving required records and ownership information.

B. Immediately erase all records.

C. Increase the user's permissions.

D. Share the password.

Correct Answer

A

Part CX — Scenario 7: Dormant Account

177.

An account has not been used in 18 months but remains active.

What should occur?

A. Review the business need and disable/remove it according to policy if no longer required.

B. Grant more privileges.

C. Ignore it because it is inactive.

D. Remove logging.

Correct Answer

A

Part CXI — Scenario 8: Review

178.

A manager receives a quarterly list of employee entitlements.

What is the PRIMARY purpose?

A. Confirm that access remains appropriate.

B. Reset every password.

C. Encrypt every file.

D. Test network performance.

Correct Answer

A

Part CXII — Scenario 9: sudo

179.

A Linux administrator needs to restart one production service.

Which approach BEST supports least privilege?

A. Permit the specific authorized command through controlled sudo policy and audit its use.

B. Share the root password.

C. Give permanent unrestricted root access.

D. Disable command logging.

Correct Answer

A

Part CXIII — Scenario 10: Privileged Audit

180.

Multiple administrators share the root account and security cannot determine who changed a critical configuration.

Which property has failed?

A. Accountability.

B. Confidentiality only.

C. Availability only.

D. Data retention.

Correct Answer

A

Part CXIV — Scenario 11: JIT

181.

A database administrator requires privileged access only during a four-hour maintenance period each month.

Which control BEST minimizes risk?

A. Just-In-Time privileged access.

B. Permanent database-administrator membership.

C. Shared password.

D. Anonymous access.

Correct Answer

A

Part CXV — Scenario 12: Service Account

182.

A service account used by a reporting application has Domain Administrator privileges.

What should occur?

A. Reduce access to the minimum permissions required by the application.

B. Leave privileges because it is not a human account.

C. Give it interactive logon.

D. Share its password.

Correct Answer

A

Part CXVI — Scenario 13: Orphan Account

183.

A service account has no known owner and belongs to an application retired two years ago.

What should happen FIRST?

A. Determine dependency and legitimate need, then disable/remove it through controlled lifecycle procedures.

B. Increase privilege.

C. Ignore it.

D. Convert it to a shared administrator account.

Correct Answer

A

Part CXVII — Scenario 14: Credential Rotation

184.

A production application has used the same embedded service-account password for seven years.

What is the BEST long-term improvement?

A. Move to managed secrets/identity with controlled rotation and remove hard-coded credentials.

B. Publish the password.

C. Disable monitoring.

D. Make the password shorter.

Correct Answer

A

Part CXVIII — Scenario 15: Failed Deprovisioning

185.

A former employee's central account is disabled, but a locally managed SaaS administrator account remains active.

What failed?

A. Complete downstream deprovisioning.

B. Authentication.

C. Encryption.

D. Network routing.

Correct Answer

A

Part CXIX — Scenario 16: Review Ownership

186.

Security analysts are asked to determine whether every employee still needs access to sensitive financial records, but they lack knowledge of employee duties.

Who should normally participate in the access decision?

A. Appropriate manager/data or application owner.

B. Firewall administrator alone.

C. Any end user.

D. Internet provider.

Correct Answer

A

Part CXX — Common CISSP Exam Traps

187. Trap — Provisioning Means Creating an Account Only

No.

Provisioning can include:

• roles;

• groups;

• entitlements;

• credentials.

188. Trap — Transfers Require Only Adding New Access

No.

Mover processes should also remove obsolete access.

189. Trap — Disabled Account Equals Deleted Account

No.

Disabling preserves the identity record while preventing normal access.

190. Trap — Dormant Accounts Are Safe Because Nobody Uses Them

Dormant accounts can be attractive to attackers precisely because legitimate owners may not notice misuse.

191. Trap — Access Review Means Change Every Password

No.

Access review asks whether:

access remains appropriate.

192. Trap — Manager Should Approve Everything Automatically

Review requires meaningful confirmation.

Rubber-stamping does not provide effective assurance.

193. Trap — Admins Need Permanent Admin Rights

Not necessarily.

JIT and task-specific elevation may reduce standing privilege.

194. Trap — sudo Means Unlimited Root Access

No.

It can be configured to allow specific authorized privileged actions.

195. Trap — Emergency Means No Audit

Emergency access should still provide accountability where possible.

196. Trap — Service Accounts Do Not Need Reviews

ISC2 explicitly includes account-access review for services and service-account management under Objective 5.5.

197. Trap — Service Accounts Can Have Permanent Passwords Because Applications Need Stability

Stable operations do not justify unmanaged long-lived secrets.

198. Trap — Central Deactivation Removes Every Account

Not necessarily.

Local and third-party accounts can remain.

199. Trap — Automation Eliminates IAM Risk

Automation can consistently implement good policy—or bad policy.

200. Trap — More Access Helps Productivity

CISSP reasoning favors:

legitimate business need + least privilege.

Part CXXI — Knowledge Check

201. Question 1

What does the Joiner-Mover-Leaver model describe?

A. Identity and access lifecycle events.

B. Network routing.

C. Encryption algorithms.

D. Backup rotation.

Correct Answer

A

202. Question 2

What is provisioning?

A. Creating or assigning accounts and authorized access.

B. Deleting evidence.

C. Encrypting backups.

D. Network segmentation.

Correct Answer

A

203. Question 3

What is birthright access?

A. Baseline access automatically associated with a legitimate identity relationship.

B. Permanent administrator access.

C. Anonymous access.

D. Access inherited from family members.

Correct Answer

A

204. Question 4

What is access creep?

A. Accumulation of unnecessary access over time.

B. User authentication failure.

C. Data encryption.

D. Network latency.

Correct Answer

A

205. Question 5

What should a mover process do?

A. Remove obsolete access and provide legitimate new access.

B. Add rights without reviewing existing ones.

C. Disable all auditing.

D. Create a shared account.

Correct Answer

A

206. Question 6

What is deprovisioning?

A. Removing or disabling access that is no longer authorized.

B. Issuing more privileges.

C. Creating a backup.

D. Installing software.

Correct Answer

A

207. Question 7

What is a dormant account?

A. An account remaining enabled despite extended inactivity.

B. A deleted account.

C. A firewall rule.

D. A certificate authority.

Correct Answer

A

208. Question 8

What is an orphan account?

A. An account without an appropriate accountable owner.

B. A new employee account.

C. A VPN.

D. An encrypted account.

Correct Answer

A

209. Question 9

What is the PRIMARY purpose of access recertification?

A. Confirm access remains appropriate.

B. Increase all privileges.

C. Reset every credential.

D. Improve throughput.

Correct Answer

A

210. Question 10

Which access should generally receive heightened review?

A. Privileged administrative access.

B. Public website viewing.

C. Anonymous public data.

D. None.

Correct Answer

A

211. Question 11

What does sudo support?

A. Controlled privilege escalation for authorized commands.

B. SAML federation.

C. Network segmentation.

D. Disk encryption.

Correct Answer

A

212. Question 12

Why should privileged activity be audited?

A. Accountability and investigation.

B. Higher bandwidth.

C. Data compression.

D. Certificate renewal.

Correct Answer

A

213. Question 13

What does PAM primarily control?

A. Privileged identities and administrative access.

B. Public websites.

C. Physical cables.

D. DNS.

Correct Answer

A

214. Question 14

What does JIT privilege reduce?

A. Standing privileged-access exposure.

B. Authentication strength.

C. Encryption.

D. Availability.

Correct Answer

A

215. Question 15

What does Just Enough Administration emphasize?

A. Only the administrative capability needed for the task.

B. Permanent root access.

C. Shared administrator credentials.

D. Anonymous access.

Correct Answer

A

216. Question 16

What is the most important management requirement for a service account?

A. Defined purpose, owner, least privilege, and lifecycle.

B. Permanent domain-admin privilege.

C. Shared human credentials.

D. No monitoring.

Correct Answer

A

217. Question 17

Why are managed workload identities useful?

A. They can reduce dependency on distributed long-lived static secrets.

B. They eliminate authorization.

C. They remove auditing.

D. They provide physical security.

Correct Answer

A

218. Question 18

What does identity reconciliation do?

A. Compares expected/authoritative identity data with actual accounts and entitlements.

B. Encrypts user data.

C. Creates VLANs.

D. Tests firewalls.

Correct Answer

A

219. Question 19

What should happen after an access reviewer selects REVOKE?

A. Access should actually be removed and the change verified.

B. Nothing.

C. Increase privilege.

D. Disable logs.

Correct Answer

A

220. Question 20

Which statement is MOST accurate?

A. IAM lifecycle security requires provisioning, review, modification, and timely revocation.

B. Secure IAM ends after account creation.

C. Service accounts need no owners.

D. Privileged access should always be permanent.

Correct Answer

A

Part CXXII — Original CISSP-Style Practice Questions

221. Practice Question 1

An employee is promoted and requires several new permissions. The manager asks IAM to simply add the new role.

What should IAM do FIRST?

A. Review whether current permissions remain appropriate before finalizing the new role assignment.

B. Add the role without review.

C. Give administrator privileges.

D. Create a shared account.

Correct Answer

A

222. Practice Question 2

An organization terminates an employee's directory account immediately but discovers the employee can still access a cloud application with local credentials.

Which process requires improvement?

A. Enterprise-wide deprovisioning.

B. Firewall rule review.

C. Hashing.

D. Backup retention.

Correct Answer

A

223. Practice Question 3

An administrator needs a single privileged Linux command once per week.

Which control BEST supports least privilege and accountability?

A. Authorized sudo configuration with audit logging.

B. Shared root password.

C. Permanent unrestricted root shell.

D. Anonymous administration.

Correct Answer

A

224. Practice Question 4

A contractor's account will automatically expire on the contract end date.

Which principle is BEST demonstrated?

A. Time-bound lifecycle management.

B. Permanent privilege.

C. Shared identity.

D. Anonymous access.

Correct Answer

A

225. Practice Question 5

A quarterly access review identifies ten unnecessary privileged roles, but they remain active six months later.

What is the PRIMARY problem?

A. Review findings are not being remediated.

B. Reviews occurred too frequently.

C. MFA is too strong.

D. There are too many logs.

Correct Answer

A

226. Practice Question 6

A service account uses a password embedded in source code and cannot be rotated without rebuilding the application.

What is the BEST architectural improvement?

A. Move credential retrieval to an appropriate secrets/managed-identity service.

B. Publish the password.

C. Never rotate the password.

D. Give developers the production password.

Correct Answer

A

227. Practice Question 7

A PAM system provides a database administrator with elevated privileges only after approval and automatically removes them after one hour.

Which concept is MOST clearly implemented?

A. Just-In-Time privileged access.

B. DAC.

C. Permanent access.

D. Shared authentication.

Correct Answer

A

228. Practice Question 8

During an outage, an engineer uses a break-glass account. What should happen after service is restored?

A. Review the emergency access, verify actions, and secure/reset the emergency credential as required.

B. Ignore the activity because it was an emergency.

C. Keep the account logged in permanently.

D. Disable auditing.

Correct Answer

A

229. Practice Question 9

A manager receives an access-review list containing cryptic entitlement IDs such as APP_X_R42_P07 and approves everything because the descriptions are meaningless.

What is the BEST improvement?

A. Present understandable business-level access information so the reviewer can make meaningful decisions.

B. Remove the manager from all reviews.

C. Automatically approve everything.

D. Stop access reviews.

Correct Answer

A

230. Practice Question 10

A service account has not been used for a year, and its owning application was decommissioned.

What should occur?

A. Validate dependencies, then deprovision the service identity if no legitimate need remains.

B. Grant more privileges.

C. Leave it active permanently.

D. Convert it to a human administrator account.

Correct Answer

A

231. Practice Question 11

An employee leaves the procurement team but retains the ability to create vendors while gaining authority to approve payments in the new finance role.

What is the GREATEST concern?

A. Access creep has created a separation-of-duties conflict.

B. The user has strong MFA.

C. The network is segmented.

D. Logs are retained.

Correct Answer

A

232. Practice Question 12

Which lifecycle control would MOST directly identify accounts that exist in applications but no longer correspond to active identities?

A. Identity/account reconciliation.

B. Encryption.

C. Penetration testing only.

D. Firewall clustering.

Correct Answer

A

Part CXXIII — Joiner-Mover-Leaver Memory Table

Part CXXIV — Account-State Memory Table

Part CXXV — PAM Memory Table

Part CXXVI — Review Memory Table

Part CXXVII — Key Terms

Provisioning

Creation and assignment of accounts, roles, groups, credentials, and entitlements.

Deprovisioning

Removal, disabling, or revocation of no-longer-authorized access.

Joiner

New identity entering an authorized relationship.

Mover

Identity whose role or responsibilities change.

Leaver

Identity whose legitimate relationship ends.

Birthright Access

Baseline access automatically associated with a defined identity status.

Entitlement

Specific access granted to an identity.

Access Creep

Accumulation of unnecessary access over time.

Access Certification

Formal validation that existing access remains appropriate.

Recertification

Periodic repetition of access certification.

Dormant Account

Enabled account with extended inactivity.

Orphan Account

Account without an appropriate accountable owner.

Privilege Escalation

Movement from lower to higher privilege.

Standing Privilege

Privilege continuously available to an identity.

Just-In-Time Access

Privilege granted only when needed for a limited period.

Just Enough Administration

Limiting administrative capability to the specific functions required.

sudo

Unix/Linux mechanism capable of allowing controlled execution of privileged commands.

PAM

Privileged Access Management.

Credential Vault

Protected system for privileged credentials.

Break-Glass Account

Highly protected emergency account intended for exceptional recovery conditions.

Service Account

Identity used by an application or automated service.

Workload Identity

Identity assigned to a software workload, application, or automated process.

Managed Identity

Platform-managed non-human identity designed to reduce manual static-secret management.

Secrets Management

Controlled storage, retrieval, rotation, and revocation of credentials and cryptographic secrets.

Identity Reconciliation

Comparison of authoritative identity data with actual accounts and access.

Entitlement Reconciliation

Comparison of approved access models with actual permissions.

SCIM

Standardized protocol used for cross-domain identity provisioning and management.

CISSP Exam Focus

For lifecycle questions, use this reasoning sequence:

WHY DOES THE IDENTITY EXIST?

        ↓

WHO APPROVED ACCESS?

        ↓

WHAT IS THE MINIMUM ACCESS?

        ↓

HAS THE ROLE CHANGED?

        ↓

HAS ACCESS BEEN REVIEWED?

        ↓

IS ANY PRIVILEGE EXCESSIVE?

        ↓

DOES THE IDENTITY STILL NEED TO EXIST?

        ↓

HAS ACCESS ACTUALLY BEEN REVOKED?

Remember:

• Current Objective 5.5 explicitly covers user/system/service access reviews, provisioning/deprovisioning, onboarding/offboarding/transfers, role transitions, privilege escalation including sudo auditing, and service accounts.

• NIST's current SP 800-53 controls page identifies Revision 5 controls as the current catalog, with Version 5.1 downloads available.

• NIST AC-2 requires lifecycle management of accounts, including account creation, modification, disablement, removal, monitoring, review, and alignment with transfers and terminations.

• A new account should originate from a legitimate authoritative source.

• Provision only minimum access required.

• Birthright access should remain minimal.

• A transfer requires removing old access, not merely adding new rights.

• Access creep is one of the most important lifecycle risks.

• Account-access reviews must include users, systems, and services.

• High-risk access deserves more scrutiny.

• Access-review decisions must be implemented and verified.

• Dormant accounts should not remain indefinitely enabled without legitimate need.

• Orphan accounts are dangerous because no valid owner is accountable.

• Temporary access should expire.

• Privileged access should be more tightly controlled and monitored.

• NIST AC-6 applies least privilege to users and processes acting on their behalf.

• sudo supports controlled privilege elevation and should be audited.

• Shared root/admin credentials weaken individual accountability.

• JIT reduces the duration of privilege.

• JEA reduces the extent of privilege.

• Break-glass accounts require strong safeguards and post-use review.

• Service accounts are identities and need owners.

• Service accounts should use least privilege.

• Long-lived embedded service-account passwords create lifecycle risk.

• Managed identities and secrets platforms can reduce static credential exposure.

• Deprovisioning must include downstream/cloud/local accounts.

• Disabling is different from deleting.

• Emergency termination may require immediate coordinated action.

• IAM automation improves consistency but does not replace sound governance.

• Security outcomes matter more than merely completing review paperwork.

Lesson Summary

Lesson Twenty completed the core CISSP Domain 5 lifecycle sequence by moving IAM beyond authentication and authorization into continuous identity governance.

The complete lifecycle is:

AUTHORITATIVE NEED

        │

        ▼

IDENTITY CREATED

        │

        ▼

ACCESS APPROVED

        │

        ▼

PROVISIONED

        │

        ▼

USED

        │

        ▼

REVIEWED

        │

        ▼

MODIFIED

        │

        ▼

REVOKED

        │

        ▼

DEPROVISIONED

The current CISSP Objective 5.5 specifically identifies:

ACCOUNT ACCESS REVIEW

        │

PROVISION / DEPROVISION

        │

ROLE TRANSITION

        │

PRIVILEGE ESCALATION

        │

SERVICE ACCOUNT MANAGEMENT

You learned the Joiner-Mover-Leaver model:

JOINER

  ↓

Create minimum access



MOVER

  ↓

Remove old + add new



LEAVER

  ↓

Revoke and deprovision

You learned why mover processes are especially important:

OLD ACCESS

    +

NEW ACCESS

    +

NO REMOVAL

    =

ACCESS CREEP

You studied access certification and recertification as mechanisms for answering:

Does this identity still need this access?

You learned that access reviews must lead to:

REVIEW

   ↓

DECISION

   ↓

REMEDIATION

   ↓

VERIFICATION

NIST AC-2 similarly requires organizations to review accounts, monitor their use, manage role and privilege assignments, and align account management with transfer and termination processes.

You then examined privileged-access management.

STANDARD IDENTITY

       │

       ▼

APPROVED ELEVATION

       │

       ▼

MINIMUM PRIVILEGE

       │

       ▼

AUDITED SESSION

       │

       ▼

PRIVILEGE REMOVED

The CISSP outline specifically identifies sudo and auditing its use as privilege-escalation examples.

Finally, you examined service and workload identities.

APPLICATION

    │

    ▼

SERVICE IDENTITY

    │

    ▼

MINIMUM ACCESS

    │

    ▼

MANAGED CREDENTIAL

    │

    ▼

MONITOR

    │

    ▼

ROTATE / RETIRE

NIST's least-privilege guidance explicitly applies not only to human users but also to processes acting on their behalf.

The central Lesson Twenty principle is:

Access should exist only while a legitimate business need exists. Secure IAM continuously creates the minimum necessary access, removes obsolete permissions during role changes, reviews existing entitlements, tightly controls privilege escalation, governs service identities, and promptly revokes access when trust is no longer justified.

Exam Readiness Check

Before proceeding to Domain 6, make sure you can explain without reviewing:

• What the identity-access lifecycle is.

• What Joiner-Mover-Leaver means.

• Why an authoritative identity source matters.

• What onboarding means.

• What provisioning means.

• What birthright access means.

• What request-based access means.

• Who should approve business access.

• How group-based provisioning works.

• How role-based provisioning works.

• Advantages and risks of automation.

• Why movers present unique security risk.

• What access creep means.

• What privilege accumulation means.

• Why transfers require both additions and removals.

• Why temporary access should expire.

• What offboarding includes.

• How planned and emergency termination differ.

• Why access termination should be coordinated.

• The difference between account disablement and deletion.

• Why resource ownership may need transfer before account deletion.

• What dormant accounts are.

• Why dormant accounts are dangerous.

• What orphan accounts are.

• Why temporary accounts need lifecycle controls.

• What account-access review means.

• What access certification means.

• What recertification means.

• Why privileged access should be reviewed more frequently when risk warrants.

• Why reviews require meaningful business context.

• Why rubber-stamp reviews are weak.

• Why SoD conflicts should be identified during reviews.

• What privilege escalation means.

• What standing privilege means.

• How temporary privilege reduces exposure.

• What sudo does conceptually.

• Why direct shared root usage harms accountability.

• Why privileged actions should be audited.

• What PAM is.

• What credential vaulting does.

• What JIT means.

• What JEA means conceptually.

• How JIT and JEA differ.

• What break-glass accounts are.

• Why break-glass use should be reviewed.

• What a service account is.

• Why service accounts require owners.

• Why service accounts require least privilege.

• Why interactive login may be inappropriate for many service identities.

• Why long-lived credentials are dangerous.

• What secrets management does.

• What managed identities are conceptually.

• Why machine identities require lifecycle management.

• Why system and service accounts must be included in access reviews.

• Why shared accounts weaken accountability.

• What identity reconciliation means.

• What entitlement reconciliation means.

• What provisioning drift means.

• How SCIM helps lifecycle automation.

• Why disabling a central identity may not remove every downstream account.

• Why deprovisioning failure can be more dangerous than provisioning failure.

• Why access reviews must lead to remediation.

• What IAM lifecycle metrics can demonstrate.

Coming Next

Lesson Twenty-One: Security Assessment and Testing Foundations

Lesson Twenty-One will begin CISSP Domain 6 — Security Assessment and Testing, which currently represents 12% of the CISSP examination.

The current Domain 6 objectives include:

6.1 — Design and validate assessment, test, and audit strategies

Including:

• internal;

• external;

• third-party;

• on-premises;

• cloud;

• hybrid environments.

6.2 — Conduct security control testing

Including:

• vulnerability assessments;

• penetration testing;

• red-team, blue-team, and purple-team exercises;

• log reviews;

• synthetic transactions;

• benchmarks;

• code review;

• misuse-case testing;

• coverage analysis;

• interface testing;

• breach-attack simulations;

• compliance checks.

6.3 — Collect security process data

Including:

• account management;

• management review and approval;

• KPIs and KRIs;

• backup verification;

• training and awareness;

• disaster recovery and business continuity.

6.4 — Analyze test output and generate reports

Including:

• remediation;

• exception handling;

• ethical disclosure.

6.5 — Conduct or facilitate security audits

Across internal, external, third-party, on-premises, cloud, and hybrid contexts.

Lesson Twenty-One will therefore cover:

• assessment versus testing versus audit;

• independence;

• internal versus external assessment;

• third-party assessment;

• test strategy;

• rules of engagement;

• authorization to test;

• scope;

• vulnerability assessments;

• vulnerability scanning;

• authenticated versus unauthenticated scanning;

• false positives;

• false negatives;

• penetration testing;

• black-box, white-box, and gray-box concepts;

• red teams;

• blue teams;

• purple teams;

• breach-and-attack simulation;

• control validation;

• security-control testing;

• evidence;

• test limitations;

• remediation prioritization;

• original testing diagrams;

• exam traps;

• knowledge checks;

• CISSP-style practice scenarios.

The central Lesson Twenty-One question will be:

How should an organization design, authorize, conduct, analyze, and report security assessments and tests so that management receives reliable evidence about whether security controls actually work?

Publication and Independence Notice

This lesson is independently developed educational material for the SierraTec Secure CISSP Certification Preparation Course.

CISSP is administered by ISC2. SierraTec Secure's program is independent certification-preparation material and should not be represented as official ISC2 training unless separately authorized.

The lesson's primary alignment was verified against the current official CISSP Certification Exam Outline. Objective 5.5 currently includes user/system/service account reviews, provisioning/deprovisioning, onboarding/offboarding/transfers, role definition and transition, privilege escalation including sudo auditing, and service-account management.

Account-management, separation-of-duty, and least-privilege concepts were supplemented with current NIST SP 800-53 control material. NIST's current downloads page identifies Revision 5 controls as current Version 5.1, and the relevant controls include AC-2 Account Management, AC-5 Separation of Duties, and AC-6 Least Privilege.

The SierraTec Secure ACCESS framework, diagrams, examples, knowledge checks, scenarios, and practice questions are original educational material and are not actual, recalled, leaked, or official CISSP examination questions.