Contractor Access and Offboarding: The Security Checklist

Last updated: September 28, 2026

By Robert Ardell, Co-Founder and Strategic Advisor, KORE1

Contractor offboarding access revocation means closing every path a contractor had into your systems, not just disabling the SSO account: live sessions, refresh tokens, personal access tokens, cloud keys, and the shared secrets they could read.

Most teams do the first item and call it done.

A payments company in Irvine rolled a contract DevOps engineer off at the end of a nine-month platform migration. Good engineer. Clean exit, by every measure anyone was checking. IT disabled his Entra ID account at 5:02 on his last Friday and closed the ticket. Nineteen days later the security team was chasing an unrelated alert through CloudTrail and found API calls signed with an AWS access key that belonged to an IAM user named after him. The calls came from a residential IP in Tustin. Every one of them was a read against Cost Explorer.

He had written a little script months earlier to email himself the weekly spend report, and it was still running on a cron job on his personal laptop. Nothing malicious. He had honestly forgotten it existed. But for nineteen days a person with no contract, no badge, and no SSO account held a working credential to a production AWS account, and the only reason anyone found out was luck.

The Entra account had nothing to do with that key. It never did.

I should say where I sit on this. KORE1 places contractors through our contract staffing practice, which means our people are the ones walking out of your building on the last day, and I would rather they walk out with nothing still attached. The front half of this, provisioning access so it can be taken back, is in our contractor onboarding checklist. This page is the back half. The last day, and the week after it.

Disabled Is Not Revoked

Revoking access means the person can no longer use anything they were issued. Disabling an account means they can no longer sign in to get new things. Those overlap less than people assume, because a lot of what a contractor holds on their last afternoon was issued hours, weeks, or months earlier and does not go back through the identity provider to be used.

Microsoft is unusually direct about this in its own guidance. The Entra ID documentation on revoking user access in an emergency says access tokens it issues last one hour by default, and that the user keeps access to apps using them until the token expires. Browser apps are worse. Once an app hands out its own session cookie, Entra “can’t directly revoke a session token issued by an application,” and some apps may never send the user back to check. That’s the vendor saying it, not a critic.

So even inside the identity provider, the switch has two positions that matter. Disable the account. Then revoke the sessions, which is a separate button on the user’s overview page and a separate cmdlet, Revoke-MgUserSignInSession, if you script it. Okta and Google Workspace have their own equivalents. Plenty of offboarding runbooks list only the first one.

Outside the identity provider, it gets looser fast.

GitHub is the one that surprises engineering managers most. If your organization uses SAML single sign-on without SCIM provisioning, GitHub’s documentation on SCIM for organizations says members whose IdP access is removed “aren’t automatically removed from the organization,” and that authorized tokens keep granting access even after their sessions expire. Someone has to remove them from the org by hand. In my experience someone usually forgets, because the IdP dashboard already says the person is gone.

AWS is blunter still. Its IAM guide calls access keys long-term credentials and warns that handing them out can give someone “permanent access to your account.” An IAM user with keys doesn’t care what your SSO thinks. That was the Irvine problem, exactly.

Where Access Survives the Account Switch-Off

Here is the inventory I would walk through for any technical contractor. Not every row applies to every seat. Obviously. A contract accountant probably never touched an AWS key, and a contract data engineer probably touched six.

Local database roles and SFTP accounts belong on that list too. Kris Drouet covers them in depth in a piece on deprovisioning evidence, including the nightly reconciliation that catches them, so I won’t repeat it.

The fourth row is the one I’d circle. In red. A token the contractor created on day twelve to get a CI job working is a credential nobody else on your team knows exists. It isn’t in the provisioning ticket, because nobody provisioned it. They made it themselves, which is normal and fine and exactly why it survives. Somebody on your side has to own that inventory, and at most companies that’s the kind of work IAM engineers are hired for.

The Last-Day Order of Operations

Order matters here more than completeness does. Rotate a shared secret while the contractor can still open the vault and they could, if they were so inclined, simply read the new one. Delete an account before you transfer what it owns and you lose the files, the scheduled jobs, and the audit trail in one click. The sequence below is the one I’d give a new IT lead.

1. Pull the access list from the onboarding ticket, then ask the contractor’s manager what got added since. The ticket is always incomplete. The manager usually knows about two more things.
2. At the scheduled end time, disable the account and revoke sessions in the same sitting. Not end of day whenever. The time on the calendar.
3. Remove them by hand from everything that isn’t wired to SCIM: the GitHub org, any AWS IAM users, the vendor portals, the one Tableau server that still runs local accounts.
4. Revoke the tokens and keys they minted. Deactivate cloud keys rather than deleting them on day one, and watch the logs for 48 hours. Anything that breaks tells you what they had quietly wired into production.
5. Rotate every shared secret they could read, starting with anything that grants admin.
6. Transfer ownership of documents, dashboards, scheduled jobs, and cloud resources tagged to their name.
7. Recover or wipe devices. For a personal machine that means a selective wipe of corporate apps, which only works if the device is online.
8. Delete the account after your retention window, usually 30 to 90 days, once nothing still points at it.

Step four is where teams find out what they didn’t know. A regional grocery distributor in Fontana revoked a departed contractor’s GitHub personal access token on a Wednesday and failed its Thursday release, because the pipeline’s tag-and-push step had been authenticating as him since a crunch week in March. Nobody had noticed. Why would they? That’s annoying. It’s also the best possible outcome, because the break happened on a weekday with the right people in the room, not eight months later in front of an auditor.

The Secrets Step Everyone Skips

Rotation is expensive. That’s the whole reason it gets skipped.

Revoking an account touches one person. Rotating a shared secret touches every system and every human that uses it. Change the password on the service account behind a nightly ETL job and somebody has to update it in Airflow, in the Kubernetes secret, in the vault, and in whatever a former engineer hardcoded into a config file in 2023. If that goes wrong at 2 a.m., the on-call engineer gets paged for a problem the offboarding caused. So teams quietly decide the contractor was trustworthy, which they probably were, and leave the secret alone.

Trustworthy isn’t the question. The question is where their laptop goes next. A secret a contractor could read now lives in their memory, their browser’s saved passwords, possibly a notes app, and whatever malware finds that machine next year. The 2026 Verizon Data Breach Investigations Report found that breaches involving a third party now account for 48% of all breaches. That’s up sharply from the prior edition. Every contractor you bring in counts toward that number.

Two things make rotation survivable. First, scope it at onboarding. If a contractor only ever gets secrets through a vault with per-person access and an audit log, you know exactly which ones they read, and the rotation list is short. If they got the break-glass admin password in a Slack DM, the list is everything. Second, put the rotations on a calendar before the last day, with the owning team’s name next to each one. Rotation that is scheduled happens. Rotation that is “we should” does not.

I’m going to be slightly unfair to security teams here. Most security leads I talk to could recite this list from memory. The gap is plumbing. Offboarding tickets route to IT, and IT doesn’t own the secrets. Teams that bring in contract security engineers for an audit push feel this most, because those seats tend to hold the admin credentials.

Planned Endings and the Other Kind

Most contract endings are planned. Boring, even. The end date sits in the statement of work, everyone has known it since March, and the only real risk is drift, the ticket that gets opened a week late because the manager was out. For those, schedule the revocation at the exact end time the moment the end date is set, and let the extension-or-release decision move the date if it changes. On long engagements, a tenure cap may set that date before the project does.

For-cause is a different animal. Revoke during the conversation. Before it, ideally, timed so the account goes dark while the manager is still talking. That feels cold and it is a little cold, but a contractor being walked out for cause with live admin access to your EDR console is not a situation where courtesy should set the timing. If you haven’t yet decided whether a struggling contractor should be coached or replaced, settle that question first.

Then there’s the middle case. Budget cut in October, project killed by a new VP, a client of yours pulling the contract that funded the seat, and nobody did anything wrong. Treat those like planned exits with the calendar squeezed into a day or two, and don’t let the awkwardness of the conversation push the revocation to next week.

One structural wrinkle catches almost every company I’ve worked with. Contractors usually aren’t in your HR system. They’re on the staffing firm’s payroll, so the HRIS termination that triggers employee offboarding never fires. The end date lives in a statement of work, a vendor management system, or someone’s inbox. Whoever places the contractor should send that end date to the people who own access, not just to the hiring manager. If your staffing partner can’t tell you who on your side receives that notice, ask them. It’s a two-minute question and it’s the whole trigger.

What IT Can’t Take Back

A contractor who cloned your repository has your code on their disk. GitHub’s own documentation on removing an organization member says removed members lose access to private forks “but they may still have local copies.” No console fixes that. Contractors working from their own hardware are the hardest case, which is why remote contract staffing engagements should settle the equipment question before day one.

The contract does. A return-or-destroy clause with a written certification at the end of the assignment, plus clean IP assignment language, is the only real control over copies. We cover the ownership side in our piece on contractor IP ownership. Get the certification signed on the last day, while the person is still engaged and cooperative, rather than chasing it in week three. It belongs in the same folder as the assignments, and the paperwork file for a contract engineering engagement shows where it falls in the signing order.

What IT Leads Ask Us About Contractor Offboarding

Should we delete the account on the last day or just disable it?

Disable it on the last day and delete it 30 to 90 days later, once ownership has moved and nothing breaks. Deleting on day one destroys the audit trail and, in some tools, every file and scheduled job the account owned. Disabled accounts cost almost nothing to keep around for a quarter.

The contractor came through an agency. Whose job is revocation?

Yours. The staffing firm ends the assignment and the payroll, but it has no admin rights in your Okta, your GitHub org, or your AWS accounts, and it shouldn’t. What the firm owes you is timely, written notice of the end date, sent to someone who can act on it.

We’re letting someone go for cause. What changes?

Timing, mostly. Revoke sessions and disable the account while the conversation is happening, rotate anything admin-level the same day, and skip the 48-hour key deactivation window in favor of immediate deletion for anything that grants production access. Take the breakage. It’s cheaper.

Realistically, how fast is fast enough for a planned exit?

Same business day for accounts and sessions, within a week for secret rotation. Many SOC 2 programs write 24 hours into policy for account removal, and auditors will sample departed contractors against it. Rotation takes longer because other teams own the secrets, which is fine as long as each one has a date and a name.

Can we stop a contractor from keeping a copy of our code?

Not with any tool you own, because once code is cloned to a laptop, revoking access doesn’t reach it. The controls that work are company-managed devices you can wipe, a return-or-destroy clause, and a signed certification on the last day. If the work is sensitive enough that the thought keeps you up, issue the laptop.

The Short List

If I had to fit this on an index card: revoke sessions, not just the account. Remove people by hand from anything without SCIM. Hunt the tokens they made themselves. Rotate what they could read. Delete last.

We’ve placed contract technology talent in more than 30 U.S. metros since 2005, and our average search closes in about 17 days, which means we are on the other end of a lot of last days. If you want the contractors you bring in to leave as cleanly as they arrive, or you’re scoping your next IT staff augmentation engagement and want the offboarding plan written into it from the start, talk to our team.