The identity and access provisioning life cycle

Access is not granted once and forgotten. People join, change jobs, take leave, return, become contractors and leave; systems are added and retired; roles are redesigned. Each change should change access, and in most organizations many changes do not. The result is privilege creep, where long-serving staff accumulate rights from every job they have held, and orphaned accounts, where access survives the person or project it was created for. Sub-domain 5.5 covers managing this identity and access provisioning life cycle. This lesson walks through joiner, mover and leaver processes, automated provisioning with SCIM, access reviews and recertification, and the audit and legal expectations that make the life cycle a compliance matter as well as a security one.

Joiners, movers and leavers

The identity life cycle is often summarized as joiner, mover, leaver, JML. A joiner event, triggered by a new hire record in the authoritative HR system, creates a directory identity and grants birthright access, the baseline every member of that role, department or location receives, such as email, the intranet and the time-sheet system. Further access beyond birthright is requested and approved through a workflow, ideally by the resource owner, not just the manager. A mover event, such as a promotion, transfer or change of manager, should add access for the new role and remove access the person no longer needs; in practice the removal is often forgotten, which is the main cause of privilege creep. A leaver event, triggered by termination, should disable the identity immediately, revoke sessions and tokens, recover devices and badges, transfer ownership of data and remove access in every connected system.

Leavers deserve special attention because the risk is concentrated in the hours around departure. For voluntary departures, access can be removed at the end of the last day; for involuntary terminations, especially of privileged staff, access should be removed before or at the moment the person is told, coordinated between HR, the manager and security. Disabling the directory account is not enough if the person also has local accounts, cloud console access, personal API keys, shared credentials they know or active sessions and refresh tokens that remain valid for hours or days. Shared passwords the leaver knew must be rotated.

Copying another user's access, the make-her-like-Sam request, is a quiet but serious problem: Sam may have accumulated years of excess rights, which are now duplicated. Role-based birthright access, documented role definitions and request workflows that ask for specific entitlements with a business reason avoid it.

Automated provisioning and SCIM

Manual provisioning, where help desk staff create accounts from emailed requests, is slow and error-prone, and manual deprovisioning is worse because nobody is waiting impatiently for it. Identity governance and administration, IGA, tools connect the HR system to the directory and to applications, so that life cycle events flow automatically. Connectors for on-premises systems often use LDAP, database or API calls. For cloud applications, the System for Cross-domain Identity Management, SCIM 2.0, defined in RFC 7643 and RFC 7644, is the standard: the identity provider calls each application's SCIM API to create, update, deactivate and delete users and groups using a common JSON schema. When choosing software-as-a-service products, support for SCIM, or at least for automated deprovisioning, should be a requirement in procurement.

import json
# A SCIM 2.0 request body to deactivate a user (PATCH /scim/v2/Users/{id})
patch = {
    'schemas': ['urn:ietf:params:scim:api:messages:2.0:PatchOp'],
    'Operations': [{'op': 'replace', 'path': 'active', 'value': False}],
}
print(json.dumps(patch, indent=2))
# A minimal SCIM user resource as returned by the application
user = {
    'schemas': ['urn:ietf:params:scim:schemas:core:2.0:User'],
    'id': '2819c223-7f76-453a-919d-413861904646',
    'userName': 'priya.singh@example.ca',
    'name': {'givenName': 'Priya', 'familyName': 'Singh'},
    'active': False,
    'groups': [],
}
print('User', user['userName'], 'active =', user['active'], 'groups =', user['groups'])

{
  "schemas": [
    "urn:ietf:params:scim:api:messages:2.0:PatchOp"
  ],
  "Operations": [
    {
      "op": "replace",
      "path": "active",
      "value": false
    }
  ]
}
User priya.singh@example.ca active = False groups = []

Automation does not remove the need for reconciliation. Some systems will never be connected, and connectors fail silently. Regular reconciliation compares the authoritative HR list with the accounts that exist in each system, flagging accounts with no matching person, accounts belonging to people who have left and accounts whose attributes disagree. Each flagged account needs an owner's decision and a deadline.

hr = {  # authoritative source: employee id -> status
    'E1001': 'active', 'E1002': 'active', 'E1003': 'terminated', 'E1004': 'leave', 'E1005': 'active',
}
app_accounts = [  # accounts found in an unconnected finance application
    ('jlee', 'E1001'), ('mroy', 'E1003'), ('temp-audit', None), ('kpatel', 'E1004'), ('svc-report', None), ('aotieno', 'E1005'),
]
service_owners = {'svc-report': 'finance-systems-team'}
for account, emp in app_accounts:
    if emp is None:
        if account in service_owners:
            print(f'{account:11s} service account, owner {service_owners[account]} - confirm still needed')
        else:
            print(f'{account:11s} ORPHAN: no person or owner - disable and investigate')
    elif hr.get(emp) == 'terminated':
        print(f'{account:11s} LEAVER STILL ACTIVE ({emp}) - disable now, review recent activity')
    elif hr.get(emp) == 'leave':
        print(f'{account:11s} on leave ({emp}) - suspend until return')
    else:
        print(f'{account:11s} matched to active employee {emp}')
missing = [e for e, s in hr.items() if s == 'active' and e not in {emp for _, emp in app_accounts}]
print('Active employees with no account (expected for most):', missing)

jlee        matched to active employee E1001
mroy        LEAVER STILL ACTIVE (E1003) - disable now, review recent activity
temp-audit  ORPHAN: no person or owner - disable and investigate
kpatel      on leave (E1004) - suspend until return
svc-report  service account, owner finance-systems-team - confirm still needed
aotieno     matched to active employee E1005
Active employees with no account (expected for most): ['E1002']

Access reviews and recertification

An access review, also called recertification or attestation, asks a responsible person to confirm that each user's access is still appropriate, and removes what is not. Reviews can be organized by user, with managers reviewing their staff's access, or by resource, with data and application owners reviewing who can reach their systems; resource-owner reviews are usually better for sensitive systems because owners understand what each entitlement does. Privileged access, access to regulated data and access granted by exception should be reviewed more often, typically quarterly, while ordinary access may be reviewed twice a year or annually.

Reviews fail in predictable ways. Reviewers rubber-stamp hundreds of items without reading them, especially when entitlements have cryptic names such as GRP_FIN_AP_RW_03. Reviews arrive as spreadsheets that take weeks to reconcile. Revocations decided in the review are never carried out. Good programs give reviewers business-friendly descriptions, highlight risky or unusual access such as access unused for 90 days or outside the person's peer group, track revocation to completion and measure the results.

reviews = {  # reviewer: (items reviewed, items revoked, median seconds per decision)
    'manager-a': (120, 9, 21),
    'manager-b': (340, 0, 2),
    'app-owner-payroll': (85, 14, 48),
    'manager-c': (60, 0, 3),
}
print('reviewer            items revoked  rate   s/item  flag')
for who, (n, revoked, secs) in reviews.items():
    rate = revoked / n
    flag = 'possible rubber-stamping' if revoked == 0 and secs < 5 else ''
    print(f'{who:20s}{n:5d} {revoked:7d} {rate:6.1%} {secs:6d}  {flag}')
total = sum(r[0] for r in reviews.values()); revoked = sum(r[1] for r in reviews.values())
print(f'Overall revocation rate: {revoked / total:.1%} of {total} items')
print('Revocations completed within 5 business days: 21 of 23 (91.3%) - chase the 2 open items')

reviewer            items revoked  rate   s/item  flag
manager-a             120       9   7.5%     21  
manager-b             340       0   0.0%      2  possible rubber-stamping
app-owner-payroll      85      14  16.5%     48  
manager-c              60       0   0.0%      3  possible rubber-stamping
Overall revocation rate: 3.8% of 605 items
Revocations completed within 5 business days: 21 of 23 (91.3%) - chase the 2 open items

Audit and legal expectations

In the United States, the Sarbanes-Oxley Act requires public companies to assess internal control over financial reporting, and external auditors routinely test user access provisioning, timely removal of leavers and periodic access reviews for financial systems; findings such as terminated users with active access are common deficiencies. Other regimes have similar expectations: HIPAA's security rule requires access authorization, establishment and modification procedures; PCI DSS requires reviews of user accounts and removal of inactive accounts within 90 days; NYDFS Part 500 requires at least annual review of user access privileges; and federal agencies follow NIST SP 800-53 access control requirements. State privacy laws limit how long personal data about former employees may be retained. Checked October 2026.

Evidence matters as much as practice. Auditors ask for proof: lists of leavers with the time their access was removed, completed review records with reviewer decisions, approvals for new access and exception registers. A life cycle that works but leaves no trail will still fail an audit.

Thinking like a manager

Life cycle questions usually describe a symptom, such as a former employee logging in, a long-serving employee with excessive access, or an audit finding, and ask for the best response. The best answer fixes the process that caused it: connect provisioning to the authoritative HR source, automate deprovisioning, remove old access on moves, reconcile unconnected systems, and run risk-focused reviews whose revocations are carried out and evidenced. Disabling the single account in the example is necessary but never sufficient.