Who is accountable when temporary workers retain access after the season ends?

Why This Matters for Security Teams

Seasonal workers are a familiar identity lifecycle problem, but the accountability question is really about control ownership. Once access outlives the business need, the organisation has failed at revocation, review, and evidence retention, which are core duties in identity governance and zero trust programmes. OWASP’s Non-Human Identity Top 10 is useful here because the same weakness appears when credentials or entitlements are left behind after the original purpose ends.

NHIMG’s Ultimate Guide to NHIs frames the broader pattern: identity failure is rarely caused by one bad actor, but by weak lifecycle governance that leaves access active after the need has expired. For temporary staff, that gap becomes especially dangerous because their access often spans payroll systems, shared devices, SaaS tools, and contractor onboarding workflows. The question is not whether the worker clicked after the season ended, but whether the organisation allowed stale access to persist. In practice, many security teams encounter the issue only after an audit finding, an account review, or a post-season incident reveals that offboarding was treated as admin work rather than a governed control.

How It Works in Practice

Accountability should sit with the business owner and the identity control owner who manage the worker lifecycle, not with the individual who still holds credentials. Best practice is to map every seasonal role to a start date, end date, sponsor, and system owner, then automate revocation when the contract or season closes. That means combining joiner-mover-leaver workflows with privileged access management, scheduled reviews, and evidence capture. The most reliable programmes also treat access as time-bound by default, using just-in-time approvals where possible rather than standing access that must later be remembered and removed.

This is where governance becomes measurable. A mature process should answer four questions:

• Who approved the access in the first place?
• Who owns the review and revocation deadline?
• What evidence proves access was removed on time?
• What exception process exists if revocation failed?

For identity architecture, the logic aligns with the OWASP Non-Human Identity Top 10 because stale credentials and unmanaged lifecycle states create the same exposure pattern seen in machine identities. NHIMG’s 52 NHI Breaches Analysis reinforces that identity weakness becomes breach material when access is not retired cleanly. The practical control set is straightforward: define expiry at issuance, automate disabling on end date, verify downstream tokens and API keys are revoked, and retain audit evidence for review. These controls tend to break down when seasonal hiring is decentralised across multiple managers because no single owner is accountable for the end-of-season offboarding step.

Common Variations and Edge Cases

Tighter revocation often increases operational overhead, requiring organisations to balance fast onboarding against controlled offboarding. That tradeoff becomes sharper when workers are rehired each season, when identities are shared across multiple locations, or when access is granted through third-party platforms that do not integrate cleanly with the HR system. Current guidance suggests treating each season as a fresh entitlement cycle rather than assuming prior access can simply be reactivated without review.

There is also a distinction between account status and actual access. Disabling a primary account may not remove cached sessions, API tokens, delegated access, mobile device trust, or local application credentials. That is why evidence must cover downstream revocation, not just directory deactivation. In environments with contractors, unions, or franchise operations, the business sponsor may own the operational relationship while IT owns the technical control, so accountability needs to be explicitly documented in the policy. Where this guidance breaks down most often is in high-turnover environments with manual approvals and no central identity inventory, because no one can prove which accounts should have expired and when.

Related resources from NHI Mgmt Group

• Who is accountable when a hospital contractor keeps access after the work ends?
• Who is accountable for third-party access after a campaign or project ends?
• Who is accountable when vendor access remains active after a banking engagement ends?
• Who is accountable when access remains after the business need ends?