Seasonal staff, and the accounts that never leave
A business that triples its headcount for eight weeks has an onboarding problem in March and an access problem for the following five years.
In a packhouse, a winery or a processing operation, the workforce is not a stable number. It multiplies for a season and then contracts, and it does both faster than most IT processes are built for.
The onboarding side gets attention, because it is loud. Forty people start on Monday and need to be able to work. The offboarding side is quiet, and that is where the risk accumulates.
What actually happens
Provisioning gets done at speed and under pressure, which means it gets done by copying. A new starter is set up “the same as” someone else, and inherits whatever that person’s account had accrued. Nobody has time to think about least privilege at 6am in the second week of a peak.
Then the season ends. People stop turning up rather than resigning formally. There is no exit interview, no checklist, and often no clear moment at which someone decides a person has finished. So the accounts stay, and next year some of the same people come back and some do not.
Five seasons in, a business can be carrying hundreds of enabled accounts belonging to people who are not coming back, several with more access than they ever needed, some with passwords set in 2021 and no second factor.
Every one of those is a valid credential.
Why the usual fixes do not stick
“Follow the leaver process” assumes there is a leaving event. For seasonal work there frequently is not. And a manual list maintained by a supervisor during the busiest weeks of their year is not a control anyone should be relying on.
The fix has to be structural rather than a reminder.
What works
Time-bound accounts by default. A seasonal account is created with an expiry date matching the expected end of engagement, and it disables itself. Extending it is a deliberate action. That single change converts offboarding from something somebody has to remember into something that happens unless somebody intervenes.
Payroll as the source of truth, not IT’s list. The business already knows who is engaged, because it pays them. Where that data can drive account state, do it, even if the join is a weekly export rather than a live integration. Anything is better than two independently maintained lists.
Roles, not clones. Define a small number of seasonal access profiles and provision against those. Copying a person perpetuates whatever they had; assigning a role means the fortieth starter has the same access as the first.
Shared devices treated as shared. Line terminals and handhelds used by whoever is on shift need a different model from a laptop assigned to a person. Kiosk or shared device mode with short sessions and no persistent credentials, so a device left on a bench is not an open door.
An annual disable sweep, on a date. After the season, everything not explicitly retained gets disabled rather than deleted. Disabled is reversible if someone returns; enabled is a standing risk if they do not.
The bit that makes it easy next year
Do this once and the following season is a different exercise. Returning workers get reactivated rather than recreated, so their history and their training records persist. New starters get a role rather than a copy. And the count of enabled accounts stays close to the count of people who actually work there, which is the number that matters when someone asks how large your attack surface is.
None of it requires new software. It requires deciding that account lifecycle is part of the seasonal plan, alongside labour and logistics, rather than something IT catches up on in June.