The problem nobody schedules time for
Offboarding an employee is a documented process at most companies. Offboarding a contractor is often a Slack message that says "thanks, we're all set" and a closed invoice. The difference matters because contractors routinely touch credentials that were never formally provisioned — API keys pasted into a chat thread, database passwords shared over email, staging environment logins forwarded from a colleague.
Those secrets don't disappear when the contract ends. They sit in the contractor's inbox, their local shell history, their notes app. If their accounts are ever compromised — or if the relationship ends badly — you find out about it in the worst possible way.
This is not a hypothetical. Credential exposure from former contractors and third-party vendors is a documented pattern in breach reports going back years. The fix isn't complicated, but it requires treating offboarding as a security event, not just an administrative one.
Start with an audit, not a rotation
Rotating credentials before you know what you're rotating is just noise. Start by building a list of every secret the contractor could have seen. That means:
- Every shared login you sent them directly
- Every API key they needed to integrate with your services
- Every environment variable you added to a repo they had access to
- Every password manager entry that was shared with them explicitly
- Every "temporary" credential that was going to be rotated later and wasn't
The last item is where things get uncomfortable. Temporary credentials are almost never rotated on schedule. They become permanent through inertia. If you shared a staging database password six months ago and told yourself you'd rotate it after the sprint, it's still the same password.
If you used one-time encrypted links to share API keys with the contractor rather than pasting them into a shared doc, you have a meaningful advantage here: you know the contractor received the secret once, not that it's sitting in a Google Doc with seventeen viewer permissions. This is worth doing from the start of every engagement, not just thinking about at the end.
The rotation checklist
Once you have the list, work through it systematically. The order matters: rotate the highest-privilege credentials first.
- Production API keys and service account credentials. Revoke the old key before generating the new one where the service allows it. If you have to generate first and revoke second, keep the window as short as possible.
- Database and infrastructure passwords. These are the ones most likely to have been reused or saved somewhere. Rotate them even if you're confident the contractor wouldn't misuse access — confidence isn't a security control.
- Third-party service logins. If the contractor had access to your AWS console, your Stripe dashboard, your DNS provider — remove their user account if it was a named account, or rotate the shared credential if it wasn't. This is also a good moment to ask why a contractor had a shared login to a financial service rather than a scoped API key.
- Deployment and CI/CD secrets. Check your pipeline configuration. Contractors who needed to debug a deployment pipeline sometimes get added to environment variable lists and stay there.
- Recovery codes and MFA backup credentials. If the contractor ever touched account recovery materials, rotate them. See a practical threat model for sharing recovery codes for why this category deserves its own attention.
What to do if you didn't track what you shared
This is the real-world scenario for most teams. You didn't keep a log. The contractor worked across three different projects over eight months. You're not sure what they had access to.
The pragmatic answer is: rotate everything that touches production, assume everything that touches staging was seen, and audit your version control history for any secrets that were committed and then removed. Tools like git log -S 'password' or a dedicated secrets scanner will surface things you've forgotten about.
The uncomfortable answer is: this situation is why secrets sitting in chat history create lasting exposure. A one-time link that self-destructs on read leaves no copy for you to audit, but it also leaves no persistent copy for anyone else. The trade-off is real, but for most teams it lands in favor of the one-time link.
Confirm, don't assume
After rotation, verify. Make a test call with the old API key — it should fail. Try the old database password — it should be rejected. This sounds obvious, but rotation processes break in subtle ways: a key gets rotated in one environment and not another, a service has the old credential cached, a backup config file still has the original value.
Document what you rotated and when. Not for bureaucratic reasons, but because if something breaks in two weeks and someone asks whether it could be related to the contractor offboarding, you want to be able to answer that question.
Build the process before you need it
The hardest part of offboarding credential rotation isn't the rotation itself — it's not knowing what to rotate. The fix is upstream: use scoped credentials from the start, share them through channels that don't leave persistent copies, and keep a running note of what each contractor has access to. When the engagement ends, you close the note and work the list.
If you're starting a new contractor engagement and want a reference for what secrets typically need to change hands, the post on onboarding secrets for new hires covers similar ground from the other direction.
Send your next contractor credential the right way
Good offboarding starts with good onboarding. If you share every secret through a channel that self-destructs after one read, you'll spend less time at the end of a contract wondering where your credentials ended up. Create an encrypted, self-destructing note the next time you need to pass a password or API key to someone outside your team — it takes less time than writing it in a message, and it won't be sitting in their inbox six months from now.
