The contractor offboarding hap: When HR triggers don’t apply

A vendor engineer receives access to a production environment to support a two-week migration. The migration completes. Nineteen months later, the account is still active, carrying the same standing access it had on day one. No alert fired. No ticket was opened. No termination event existed to trigger one.

This is not a configuration failure. It is a structural gap. The lifecycle automation that deprovisioned every employee who left during those nineteen months never touched that account — not because it malfunctioned, but because it was never designed to deprovision it. Automated deprovisioning in enterprise IAM environments depends on a termination event propagated from an authoritative source, typically an HR system or directory. The vendor engineer had no internal HR record. No termination event ever existed to fire.

What an authoritative source provides

For the employee population, the model is sound. An HR system holds the record of employment. A joiner event triggers provisioning; a leaver event triggers deprovisioning; role changes propagate through the mover flow. The authoritative source is the control plane. When the source is updated, the identity system reacts. The practitioner's job is to keep provisioning protocol mechanics correct not to substitute manual judgment for automated signal.

NIST SP 800-53 Revision 5 defines the AC control family, including AC-2, which addresses account management — creation, activation, modification, review, disabling, and removal (Source: NIST SP 800-53 Rev. 5, https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final). AC-2 does not prescribe that lifecycle automation must depend on an HR event, and it explicitly addresses account expiration as a mechanism. The control gap described here is not that NIST fails to provide options — it is that an organization's process may not extend to everyone who actually has access. When non-employee populations are not registered in an authoritative source, the controls that depend on that source do not reach them.

The employee model's reliability is its dependency. It works precisely because employment is a formal, documented relationship with a defined end state. Populations outside that relationship often produce no comparable signal.

The four populations it does not cover

Four distinct non-employee populations generate access without reliably generating a termination event. Each has a sponsor. Many lack an internal HR record, or have one that does not drive access deprovisioning. The table below maps each population to where the control breaks.

The FFIEC IT Examination Handbook on Outsourcing Technology Services addresses third-party and subcontractor relationships as a recognized, supervised risk category — establishing that these populations are treated as distinct from the employee base, not as a variant of it (Source: ithandbook.ffiec.gov, https://ithandbook.ffiec.gov/it-booklets/outsourcing-technology-services). That framing matters: it means the control gap is not incidental. Third-party access operates under different relationship structures, and those structures do not reliably produce the internal events that lifecycle automation consumes.

Contractors engaged through procurement often have a contract end date in a purchase order or master service agreement but the date lives in a system the IAM platform does not watch. Vendor support staff may carry standing access under a support contract that auto-renews without triggering any access review. Partner users provisioned for an integration frequently outlive the project they were created for because project closure is a business event with no guaranteed IAM notification path. Assessors and auditors receive time-limited access tied to an engagement that ends on a calendar date nobody recorded in the directory.

The sponsor is not negligent. Remembering is the control they were given and memory is not an event.

Why a review is not a substitute for a trigger

A periodic access review asks: should this access continue? It depends on a reviewer recognizing a name, associating that name with a relationship that may have ended months ago, and making an active judgment to remove access. Each of those dependencies can fail independently.

A trigger asks nothing. It fires on a date or an event. It does not require a reviewer to remember who the vendor engineer was or whether the migration project ever finished.

Replacing an event with a judgment moves the control from deterministic to probabilistic. The exposure window in a deterministic model is bounded by the lag between the termination event and the deprovisioning action — typically hours to days, depending on provisioning pipeline configuration. The exposure window in a probabilistic model is bounded by the review interval at best, and by the next time someone notices at worst. Those are not equivalent risk postures.

There is a secondary failure mode. When a reviewer does not recognize a name, the path of least resistance is to approve continued access rather than escalate. Reviews measure whether access looks wrong; triggers measure whether a condition has changed. These are different tests. One catches access that someone notices is anomalous. The other catches access that has simply persisted past its intended end.

Periodic reviews remain useful for detecting access that has drifted or accumulated beyond the original grant. They are not a substitute for the event that should have ended the account. Treating them as equivalent understates the residual exposure between review cycles.

The registration discipline worth imposing at creation

The end date is the trigger. A date stored in a directory attribute or IGA field is cheaper than any review process, and it fires without human judgment. The registration discipline that closes the gap has four components, each required for the mechanism to hold.

A mandatory end date tied to the individual's access, not just the contract. Non-employee accounts registered without an end date have no termination trigger by definition. Critically, the end date should reflect when a specific person's access is needed, not simply when the contract or engagement formally concludes. A vendor engineer can finish their assigned work — or leave the vendor entirely — while the support contract remains active. Access should end when the work ends, not when the agreement does. This is a least-privilege question: if the person no longer has a current need for access, the account should not persist because a contract has not yet expired. The end date does not need to be permanent — it can be extended — but the default state must be expiry, not perpetual access. Setting account expiry as the default for non-employee account types, with extension requiring explicit approval, inverts the risk posture: access ends unless renewed, rather than persisting unless revoked.

A named sponsor who receives the expiry notification. The sponsor is the relationship owner. They receive the expiry alert at a defined interval before the end date — what interval is appropriate depends on the organization's operational cadence and the complexity of the deprovisioning workflow, and should be set by policy rather than convention. The notification is not a review; it is a renewal decision forced by an approaching date. The sponsor either extends with documented justification or the account expires.

An early-termination path. Access should be revocable before the recorded end date when a person's work concludes ahead of schedule. Sponsors should have a clear, low-friction mechanism to revoke access as soon as it is no longer needed, without waiting for the expiry date to fire. This also means deprovisioning must be complete: ending an HR record or expiring a directory account does not help if the person retains access through other accounts, active sessions, or credentials that were not covered by the same automation. Deprovisioning should be verified across all systems the individual could reach, not just the primary account.

A sponsor-change rule that covers both planned and unplanned departures. When a sponsor leaves the organization, the accounts they own require reassignment. For planned departures, reassignment should be a required step before offboarding is complete. For unplanned departures — where there is no time for a handover — the organization needs a defined process to identify orphaned accounts and assign a new responsible owner immediately. Without handling both cases explicitly, a sponsor's departure creates exactly the same gap the registration discipline was designed to prevent: a non-employee account with no active owner. This is not an edge case; it is a required branch in the IAM workflow.

Non-employees registered in the authoritative source with an end date and a named sponsor are covered by this model. Non-employees who exist only in the target system, with no record in the authoritative source, are not covered — and a date in a field the provisioning pipeline does not read does nothing. The prerequisite is that the registration creates a record the automation can act on. Without that, the trigger has nowhere to land.

Sources