Provisioning, Deprovisioning, and Identity Proofing(OBJ.4.5)

A payroll analyst resigns on a Friday. Her badge is collected at the door, but her account stays enabled, her phone keeps syncing mail, and three weeks later a sign-in with her credentials pulls the customer list out of the CRM. No exploit was needed; the account simply outlived the job.

Identity work starts and ends with the account life cycle. On the CompTIA Security+ SY0-801 exam this falls under objective 4.5, a scenario objective that gives you situations like this one and expects you to choose the right identity and access decision. This lesson covers how accounts are created, changed and removed, how permission assignments add up to what a user can actually do, and how an organization proves a person is who they claim before it hands over credentials.

Every account follows a joiner, mover, leaver life cycle

Identity teams describe account management as three events, usually called joiner, mover and leaver:

• Joiner: a new employee, contractor or intern needs an account, group memberships, a mailbox, licenses and an MFA enrollment, ideally before day one.
• Mover: someone changes role, department or location, so their access has to change with them.
• Leaver: someone leaves, by choice or not, and every account, session and credential they hold must stop working.

Provisioning is the work done for joiners and the "add" half of a move. Deprovisioning is the leaver work and the "remove" half of a move. Each event should start from an authoritative source, not from an email to the help desk. In most organizations that source is the HR system, which records the hire date, job title, department, manager and termination date. Identity tooling reads those fields and acts on them.

The reason is consistency. A manual process depends on someone remembering to file a ticket, and the ticket that gets forgotten is almost always the removal. An HR-driven process fires on a record change, so the termination date HR enters is the date the account is disabled, with no one in between who might forget.

Provisioning should be automated from HR data and grant access by role

A typical automated joiner flow looks like this. HR enters a new hire, Mia Lopez, with a start date of 3 November, job code FIN-ANALYST and manager Priya Shah. An identity governance or directory sync tool reads the record and:

• creates mlopez in Active Directory or the cloud directory, disabled until the start date;
• adds the account to the groups mapped to FIN-ANALYST, such as Finance-Users and ERP-AP-Clerk;
• assigns an email license and creates the mailbox;
• pushes the account to SaaS applications through SCIM, the System for Cross-domain Identity Management standard that many cloud apps accept for creating, updating and disabling users;
• issues a one-time enrollment credential so Mia registers her MFA methods on her first morning.

The access that comes automatically with a job code is often called birthright access. Anything beyond it, such as a restricted project share, goes through a request that the resource owner approves, and the approval is recorded so a later review can see why the access exists.

On Windows, account creation appears as event 4720, "A user account was created". Alert on any 4720 event that the provisioning tool didn't generate. An account created by hand on a domain controller at 11 p.m. is not part of your process, and attackers who reach domain admin often create one for persistence.

Provisioning applies least privilege from the first minute. A common shortcut is "set her up like Sam", which copies another employee's account. It's a bad habit, because Sam has collected years of extra access the new hire was never meant to have.

Movers are where that extra access comes from. The new role's access gets added quickly, because the employee complains if it's missing. The old role's access is rarely removed, because nobody complains about having too much. After three moves an employee can hold access from four jobs, which is privilege creep. A sound mover process treats a role change like a leave followed by a join: the old role's groups are removed on the effective date, the new role's groups are added, and any access the person still needs from the old job is requested and approved explicitly. Periodic access reviews catch what the process misses; they're covered in the last lesson of this section.