Contractors and agency staff get production access on their second day, through a Slack message to whoever administers the tool, on a laptop you do not manage, under a contract signed by procurement that nobody in engineering has read.
Then the engagement ends. Nobody tells the person who granted the access, because that person was not part of the offboarding conversation, and there was no offboarding conversation.
This post is the specific ways contractor access differs from employee access, and the controls that fit without making the arrangement unworkable. For whoever has external people in their systems, which is most companies.
Why the employee process does not cover them
They are not in the HR system. Every offboarding process is triggered by a termination event in a directory. A contractor's engagement ending produces an invoice, not a directory change, and nothing downstream fires.
They are onboarded laterally. Access is granted by whoever was asked, often in a message, often outside the normal request path, because the engagement is urgent and the process is for employees.
The end date is soft. An engagement "ends" when work tapers off. There is frequently no day on which anyone decides it is over, so there is no day on which access is removed.
They use their own devices. No endpoint management, no disk encryption you can verify, no remote wipe. Their laptop holds your source code, cached credentials and an SSH agent, and you have no visibility into any of it.
People rotate within the agency. You contracted with a firm. The individual who holds the access may change without anyone telling you, and the account keeps the original name.
Each of those breaks a different assumption in your access model, and together they produce the most common real finding in a small-company access review: an active account belonging to someone who stopped working there eight months ago.
The controls that actually fit
Give every engagement an end date at the moment access is granted. This is the single highest-value change, because it fixes the structural problem rather than asking people to remember.
Access expires on the contract end date plus a short buffer. Extending is a deliberate action that someone takes, rather than the default state. Most identity providers support an account expiry date; if yours does not, a calendar entry with a named owner is a weak substitute and still better than nothing.
Separate identities, obviously external. A distinct account, in a group, with a naming convention that makes them visible in any list: ext-, or a separate directory namespace. This costs nothing and means every future audit can filter for them in one step.
Scope tighter than an employee doing the same work. Not because contractors are less trustworthy as people, but because the relationship is shorter, the review is lighter, and the recovery path if something goes wrong is weaker. Read-only where read-only will do. One repository rather than the organisation. A non-production environment where the work allows.
Name the individual in your records, not just the firm. You need to know who holds access, so that when the agency rotates staff you can act. Make it a contractual obligation that they tell you, and check it at the same time as the invoice, which is the one artifact that always arrives.
Do not let the work happen on unmanaged devices where the data is sensitive. The options, in descending order of how well they work: a managed device you supply, a virtual desktop, or a policy nobody can verify. If the third one is what you have, know that is what you have, and scope the access accordingly.
Rotate anything shared at the end of the engagement. A shared credential known to a departing contractor cannot be revoked, only changed. This is the argument for not having shared credentials, made concrete.
Hook it to the thing that cannot be forgotten
Every process here fails for the same reason: engineering does not learn the engagement ended.
The reliable signal is money. Procurement and finance know the contract dates, and they know when an invoice stops. Connect access expiry to the contract record, and review active external accounts against the current contract list on the same cycle as your finance review.
This is the same trick as keeping a subprocessor list accurate: hook the process to the one workflow that no organisation forgets, which is paying for things.
Verify, quarterly
A short check, and the first run usually finds something:
- List every external account across your major systems.
- Diff against the current contract list.
- For anything with no matching active contract, disable it and see if anyone complains.
That last step sounds cavalier and is the practical way through, provided the reversal is quick. A contractor still working will tell you within an hour. An account nobody notices for a month was not being used, and you have your answer.
Then test the credentials they could have kept: tokens, SSH keys, API keys. Account status and credential status are different things, and the second one is what actually grants access.
The contract side
Worth getting right once, because it is the same for every engagement.
The agreement should cover: who may access what, an obligation to notify you when the individual changes, device and data handling requirements, return or destruction of data at the end, a confidentiality term that survives the engagement, and the right to audit. If personal data is involved, it needs a data processing agreement and the firm goes on your subprocessor list.
None of this is exotic, and it is much easier to agree before the engagement than during it.
The concession
Every control here adds friction to an arrangement chosen for speed. You hired a contractor because you needed capacity quickly, and a two-week access request process defeats the purpose.
So the goal is not parity with employee onboarding. It is that access has an end date, external accounts are identifiable, and there is a quarterly check against contracts. That is perhaps a day of setup and a few minutes per engagement, and it closes the failure that actually occurs, which is not a malicious contractor but a forgotten account.
The implication
The risk is not the people. It is that your access model assumes a directory event that never happens for them, so access granted for six weeks persists indefinitely by default.
Give it an expiry date at the moment you grant it. Everything else on this list is refinement.
