6.1 Support and Implement the Identity Management Lifecycle

Why the identity lifecycle is an operations job

Domain 2, Access Controls, is weighted at 15% of the Systems Security Certified Practitioner (SSCP) exam under the outline effective 1 October 2025. Knowledge area 2.1 is about proving who you are. Knowledge area 2.3 — Support and/or implement the identity management lifecycle — is everything that happens around that proof: deciding what the identity may do, creating it, changing it, watching it, and destroying it. An SSCP who can configure multi-factor authentication (MFA) but leaves a terminated contractor in the virtual private network (VPN) group has failed 2.3 even if authentication looks perfect.

The lifecycle is not a human-resources poster. It is daily work in Identity and Access Management (IAM) platforms, help-desk tickets, group membership, certificate stores, and recertification campaigns. The outline names six pieces you must be able to support or implement: authorization, proofing, provisioning/de-provisioning, monitoring, reporting, and maintenance, entitlement, and IAM systems. Joiner-mover-leaver (JML) is the operational pattern that ties them together. Orphan accounts and recertification are how you catch the pattern when it breaks.

Authorization is not authentication

Authorization is the decision that a proven identity may perform a specific action on a specific resource. Authentication answers "are you who you claim to be?" Authorization answers "may this identity do that?" A successful login followed by access denied is an authorization problem, not an authentication failure. A failed login is the opposite.

Authorization shows up in three common shapes:

• Explicit permission — a named right on an object, such as write on \\files\payroll.
• Group or role membership — membership in VPN-Contractors allows a tunnel.
• Contextual decision — the same user is allowed from a managed laptop during business hours and denied from a personal phone at 02:00.

The decision is recorded as policy in the IAM system, a directory, an application, or a device access control list (ACL). The SSCP implements the decision that the data owner and written policy already made. Inventing access because someone is "in a hurry" is not authorization; it is an uncontrolled grant you will later have to explain.

Identity proofing

Identity proofing collects and verifies evidence that a person — or the named owner of a non-human identity — is who they claim to be before you create or re-bind an account. It is not authentication. Proofing happens at enrollment and at high-risk recovery. Authentication happens at each login.

Operations examples:

• A new hire presents government identification and an HR start record. The IAM operator matches legal name, start date, and employee number before creating the directory account.
• A help-desk password reset requires a second factor already bound to the account, or an in-person manager attestation — not the last four digits of a Social Security number that live in every breach dump.
• A contractor is proofed against the vendor's named roster and an expiration date on the statement of work, not "the project manager emailed from a free webmail account."
• An AI agent's service account is proofed by tying it to a named human owner, a change ticket, and a system of record — not by copying a key from a wiki.

Weak proofing is how account takeover starts. If an attacker convinces the help desk they are the chief financial officer, a fresh MFA enrollment is just a token on the attacker's phone. SSCP scenarios hide this as "the user lost their phone" or "the contractor's laptop died." Proofing standards must rise with privilege: resetting a kiosk PIN is not the same as re-binding MFA for a domain administrator.

The National Institute of Standards and Technology (NIST) Special Publication 800-63 describes Identity Assurance Levels (IAL). ISC2 does not publish how many SSCP items land on those levels, and you should not invent a scoring claim. The operations idea is enough: higher-assurance proofing (in-person or supervised remote evidence) for identities that can move money, patient records, or production infrastructure.

Provisioning and de-provisioning

Provisioning creates the identity in target systems and grants the initial entitlement. De-provisioning reverses it: disable or delete the identity, revoke tokens and certificates, remove group memberships, recover badges and authenticators, and confirm that inherited access is gone.

A complete joiner provision typically includes an authoritative record (HR, contractor portal, or robot inventory); a unique identifier (never a shared contractor login); mailbox or cloud identity; role or group membership for the job of record; authenticators (password, MFA device, certificate); and a log of who approved the grant.

De-provisioning is the mirror, and it is where operations fail. Disabling the directory account is necessary and not sufficient. The contractor may still have a local account on a jump host, a VPN profile and a still-valid certificate, an application programming interface (API) key in a pipeline, nested group membership that survived because you removed them from Staff but not from Staff-VPN (itself a member of Global-VPN), or a standing guest in a Software-as-a-Service (SaaS) tool that never federated back to the directory.

Joiner, mover, leaver

Joiner-mover-leaver is the lifecycle viewed from HR and vendor events.

Movers are as dangerous as leavers. A nurse who becomes a billing analyst should lose clinical-chart write access. A sysadmin who moves to the project-management office should lose jump-host sudo. If you only add, every internal transfer is a silent promotion to "all access." Role changes are called out in the outline under monitoring, reporting, and maintenance for this reason.

Scenario: terminated contractor still in the VPN group

A 90-day network contractor finishes on Friday. HR marks the person as a leaver in the vendor portal on Monday. The IAM connector disables the directory account Tuesday morning. On Wednesday a Security Operations Center (SOC) analyst sees a successful VPN authentication from the contractor's laptop using a machine certificate that still maps to VPN-Contractors. The account is disabled for interactive Windows logon, but the VPN concentrator authorizes on group membership and a certificate that expires next year.

That is an orphan entitlement, not a mystery. The SSCP response is operational:

1. Revoke the certificate and kill the VPN session immediately.
2. Remove the identity from VPN-Contractors and every nested group that grants network access.
3. Search for other standing access: SaaS, cloud IAM, local UNIX, API keys issued to that contractor.
4. Open a problem ticket on the workflow: directory disable must trigger certificate revocation and VPN group removal in the same change, not "eventually."
5. Recertify remaining contractor identities. If one was missed, others were too.

Do not watch it for a few days to see if the contractor was wrapping up. A leaver with a live tunnel is an unauthorized subject on your network.

Entitlement: inherited rights and resources

Entitlement is the set of rights an identity actually has, including rights inherited through groups, roles, nested membership, and resource hierarchies. The grant you typed ("add to HelpDesk") is not the same as the effective permission ("can reset MFA, read every mailbox via nested Exchange-Support, and remote desktop to the jump host because HelpDesk sits inside IT-All").

Operations implications:

• Nested groups are inherited rights. Review effective access, not just the last group you clicked.
• Resource hierarchies inherit. A folder grant on \\files\hr may flow to \\files\hr\payroll.
• Cloud IAM inherits similarly: a folder-level role on a project applies to child resources unless an explicit deny interrupts it.
• Shared mailboxes, distribution lists, and security groups are different objects. Putting someone on an email list is not a security grant, but many directories blur that line and operators treat them as interchangeable.

When you recertify, you recertify entitlement, not the original ticket. "We added them for the enterprise-resource-planning cutover in 2023" is not a current business justification.

Monitoring, reporting, and maintenance

Outline 2.3 calls out monitoring, reporting, and maintenance, with examples: role changes and new security standards.

Monitoring watches failed logons, impossible travel, grants of Domain Admin, creation of new service accounts, MFA bypass events, and access from disabled identities. Feed those to the Security Information and Event Management (SIEM) system. An identity that authenticates after its HR termination date is an incident, not a curiosity.

Reporting covers JML metrics, time-to-disable, orphan-account counts, recertification completion, and privileged-account inventory. Reports exist so managers can recertify and so you can prove the control to an auditor. A report nobody reads is not maintenance.

Maintenance is the work those reports create. When someone changes roles, you run the mover workflow. When a new security standard lands — "all privileged access must use phishing-resistant MFA," or "AI service accounts may not hold standing Owner" — you inventory affected identities and remediate. Disabling stale authenticators, rotating service-account secrets, and closing access that a new data-classification standard no longer allows are the same job.

Recertification

Recertification (access review, attestation) is a periodic manager or data-owner confirmation that each entitlement is still required. It is the detective control that catches privilege creep, movers who were only added-to, and contractors who outlived their statement of work.

A recertification worth keeping as evidence:

• Shows effective entitlement, including inherited groups and resource trees.
• Names a human reviewer who does not hold the access being reviewed, or at least cannot be the sole reviewer of their own admin rights.
• Has a deadline and an automatic disable or ticket if the reviewer does not act.
• Keeps artifacts: who reviewed, when, what they certified, what they revoked.
• Covers non-human identities. Service accounts, bots, and AI agents have owners who must attest.

Empty recertification tickets are findings. Rubber-stamping "keep all" on four hundred accounts is not recertification. Closing incomplete tickets to make a sample look clean is an integrity failure, not a completed review.

IAM systems

IAM systems store identities, authenticate them, and enforce or broker authorization: enterprise directories, cloud identity providers, privileged access management tools, HR-to-directory connectors, and application-level identity stores.

What SSCP operators actually do with them:

• Integrate an authoritative source (HR or the contractor portal) so joiners and leavers are not typed by hand.
• Use unique IDs. Disable shared admin and temp accounts.
• Automate group membership from job code where possible, then exception-handle the rest with tickets.
• Provision downstream apps through System for Cross-domain Identity Management (SCIM) or connectors so de-provisioning is not "send an email to the vendor."
• Log administrative actions in the IAM platform itself. Who granted Domain Admin is an IAM audit event.
• Treat the IAM platform as a crown-jewel system: its admins are privileged, its backups matter, and its own service accounts need the same lifecycle.

A spreadsheet of accounts is not an IAM system. A directory that nobody deprovisions from is an IAM system you are not operating.

Non-human identities follow the same lifecycle

ISC2's current outline expects SSCPs to apply Domain 2 to AI agents and service accounts, not only badge-wearing staff. An inference bot that can query production customer records is a joiner when you deploy it, a mover when its scope expands, and a leaver when the model is retired. It needs proofing (named owner and purpose), authorization (least privilege, not the whole data lake), provisioning (unique identity, secret in a vault), monitoring (every call logged), entitlement review (does it still need personally identifiable information?), and de-provisioning (key destruction, not "leave the key in case we roll back").

A shared svc-ai-prod password in a wiki is an orphan waiting to happen. When the contractor who stored it leaves, you have a leaver problem with no HR record and no recertification owner.

How to attack a CAT item on 2.3

Translate the stem into a lifecycle stage:

1. Is someone being created, changed, or removed? (JML)
2. Was proofing skipped? (help-desk social engineering)
3. Did authorization fail or succeed incorrectly? (wrong group)
4. Is the right inherited? (nested group, resource hierarchy)
5. Did de-provisioning stop at the directory and miss VPN, certificates, or SaaS?
6. Would recertification have caught it?

The operational answer is almost always a unique identity, least privilege, complete de-provision including inherited rights, and evidence.