D5 — IAM Lifecycle: Provisioning, Review, De-provisioning

Lesson 4 covered the mechanisms of access control — the models and federation protocols that decide what someone can access. This lesson covers the lifecycle those mechanisms run inside, often summarized as joiner-mover-leaver: a perfectly designed RBAC or ABAC system still fails the organization if an account isn't removed the day someone leaves.

The three lifecycle stages

• Provisioning (joiner) — creating an identity and granting initial access. Done well, this is driven by an authoritative source (an HR system recording a new hire and their role) rather than an ad hoc admin request, so the access granted traces directly back to a defined role rather than to whatever the requester happened to ask for.
• Access review / recertification (mover) — periodic verification that a person's existing access still matches their current role. This is specifically where privilege creep gets caught: access accumulated across several role changes, where each new role added permissions but the old role's permissions were never revoked. A person who moved from Support to Engineering to Team Lead over two years may still hold Support-tier access nobody remembered to remove.
• De-provisioning (leaver) — removing access when someone leaves the organization or no longer needs a specific entitlement.

Why de-provisioning is the control most organizations get wrong

Orphaned accounts — credentials left active after someone has left — are a disproportionately common real-world breach vector, and the reason is structural, not a matter of carelessness: granting access has an immediate, visible cost if delayed (a new hire can't work, someone complains), while revoking access has no immediate visible cost if delayed — nothing breaks the day an ex-employee's account is quietly left active. Attention naturally concentrates on the step with visible consequences.

The fix that actually works is not "respond to offboarding tickets faster." It's removing the dependency on a ticket being filed at all — wiring de-provisioning to an authoritative trigger, such as an HR termination event automatically propagating through directory sync into every downstream system, the same way Lesson 4's provisioning discussion assumed access should trace back to an authoritative source in the first place. A manual, ticket-dependent process fails silently exactly at the step that matters most: the trigger never firing, not the response once it does.

Authentication factors

Three categories, and CISSP tests the distinction precisely:

• Something you know — a password, a PIN
• Something you have — a hardware token, a phone receiving a push notification or OTP
• Something you are — a biometric (fingerprint, face)

Multi-factor authentication (MFA) requires factors from two or more different categories. A critical, frequently tested distinction: entering a password, then a PIN, is not multi-factor — both are "something you know," just requested twice. This is multi-step, not multi-factor, and it does not provide the same security guarantee, because compromising the single "something you know" category (e.g. a phished password) can plausibly compromise both steps at once. True MFA specifically requires categories that fail independently of each other.

The CISSP mindset: manager vs technician

An employee is terminated. The IT team removes their access within the organization's 24-hour offboarding SLA.

The technician answer: the SLA was met, so the process worked — 24 hours is a reasonable, documented response time.

The manager (CISSP) answer: ask what triggered the removal in the first place. If de-provisioning depended on someone in HR remembering to file a ticket, then the 24-hour SLA measures the wrong thing — it describes how fast the team responds once triggered, not whether the trigger reliably fires at all. The real control gap is upstream: the correct fix is tying de-provisioning to the authoritative HR termination event directly, so the 24-hour response window becomes largely irrelevant because removal is automatic and near-immediate. Measuring and improving SLA response time, without fixing the trigger, optimizes the visible half of the problem while leaving the actual failure mode — the ticket that's never filed — completely unaddressed.