Offboarding a contractor: the access checklist most small teams skip

Offboarding a contractor involves more than deleting their accounts. Removing an account does not necessarily remove every way that person can access company systems or data. For example, GitHub notes that removing a collaborator does not delete their local repository clones. Revoking an SSO authorisation also does not automatically remove the associated token. AWS similarly treats access keys as long-term credentials that need to be managed separately.

The safest approach is to keep an access inventory from the start of the contractor's engagement. When the contract ends, use that inventory to work through every system and credential individually. Access should be revoked, credentials should be disabled or rotated where necessary, and company data should be checked to make sure it is no longer accessible through the contractor's accounts or devices.

Key facts

In this article

• Why contractor access is the widest access you grant
• Why a contractor's access is harder to revoke than an employee's
• What to record when a contractor starts
• The offboarding checklist, system by system
• Ending the engagement well
• Where RocketDevs sits
• Conclusion
• FAQ

Why is contractor access the widest access a small team grants?

Contractors are often brought in to deliver work quickly. To do that, they may receive access to production systems, code repositories, cloud platforms, customer data, and other critical tools. When the contract ends, however, there may be no formal security process to make sure all of that access is removed.

Security standards make the requirement clear. NIST's personnel controls expect organisations to disable system access when someone leaves and revoke the credentials associated with that person. Its contractor-specific controls also expect organisations to require external providers to notify them when contractors with organisational credentials or system privileges leave. The difficult part for a small company is not understanding the requirement. It is making sure someone actually carries it out.

Contractors are also a common part of modern development teams. Stack Overflow's 2025 Developer Survey found that 13.9% of respondents identified as independent contractors, freelancers, or self-employed. A further 32.4% worked fully remotely. For a small team, a contractor may remain involved for months or even years, accumulating access to more systems as their responsibilities grow.

The risks associated with contractor credentials are not theoretical. In September 2022, Uber said that its breach began when an external contractor's account was compromised. The attacker was believed to have obtained the contractor's corporate password after malware infected their personal device. After repeated two-factor authentication prompts, the contractor eventually accepted one, allowing the attacker to log in. The contractor had not left the company, but the incident demonstrates why credentials used outside the company's direct control need careful management.

Breaches are common enough that small businesses cannot assume they will be unaffected. The UK's Cyber Security Breaches Survey 2025, based on a probability survey of 2,180 businesses, found that 43% had experienced a breach or attack during the previous 12 months. Across the EU, Eurostat reported that 21.54% of enterprises with at least ten employees experienced an ICT security incident in 2024. The UK survey also found that only 14% of businesses reviewed cyber risks from their immediate suppliers. Among micro businesses, the figure fell to 11%. Contractors can easily fall into this overlooked area.

The financial consequences can also be significant. IBM's research with the Ponemon Institute puts the global average cost of a data breach at $4.99 million. A small company is unlikely to face a bill of that size, but the underlying risk still matters. The cost of investigating an incident, dealing with customers, restoring systems, and losing productive time can be substantial. The more systems a compromised contractor credential can reach, the greater the potential impact.

There is another cost that does not require a breach. Unused accounts can continue generating software bills after a contractor has left. Google, for example, charges for suspended Google Workspace users at the same rate as active accounts. Other SaaS platforms can also continue billing for unused seats. Poor offboarding therefore leaves small teams with both unnecessary costs and accounts that could still provide a route into company systems.

There is no reliable figure for how many breaches are caused by access that should already have been revoked. Some vendor reports claim that a significant proportion of former employees retain access, but these figures often lack enough methodological detail to verify them. This article therefore focuses on something more concrete: what the platforms themselves say happens when an account is removed, suspended, or revoked.

Why is a contractor's access harder to revoke than an employee's?

A contractor's access can be harder to revoke because disabling their main account does not necessarily disable every credential they have used. Personal access tokens, SSH keys, cloud access keys, OAuth grants, and active sessions can each have their own lifecycle. Depending on the platform, removing the account may leave some of these credentials in place.

GitHub is a good example because contractors may use it to access source code. If an organisation uses SAML single sign-on, an administrator can revoke a member's authorised credentials. However, GitHub explains that revoking a credential removes the SAML authorisation without deleting the underlying token or SSH key. The credential still exists, even though it can no longer use that specific SAML authorisation to access the organisation.

There can also be other routes to access. A contractor may have been added directly to a repository or may hold credentials used elsewhere. Revoking SAML access is therefore only one part of the offboarding process.

Removing someone from a GitHub organisation also has limitations. GitHub says that removed members lose access to private forks of the organisation's private repositories, but they may still have local copies. GitHub also retains membership data for three months, allowing the organisation to restore that membership if necessary.

The same issue applies to outside collaborators. GitHub makes clear that removing a collaborator does not remove local clones of a repository. Someone who previously downloaded the code may still have that copy on their computer. No account removal process can remotely take back code or confidential files that have already been copied. Managing those copies depends on the contractor agreement, confidentiality obligations, and the relationship between the contractor and the company.

Cloud credentials can create an even more serious problem because some are designed to remain valid for long periods. AWS describes access keys as long-term credentials and warns that exposing them can give someone ongoing access to an account. AWS recommends using temporary security credentials, such as IAM roles, instead of creating long-term access keys.

In practice, however, a small team may give a contractor an IAM user and an access key to help them start work quickly. That key can remain on the contractor's computer after the contract ends unless someone specifically deactivates or deletes it. Disabling another account does not automatically solve that problem.

Google Workspace presents a more subtle example. Changing a user's password can revoke many OAuth 2.0 tokens, according to Google's documentation. However, there are exceptions. Some Apps Script applications are not included in the token revocation process. OAuth tokens used for account sync on an Android device may also remain active after a password change. App passwords are another exception.

A password change is therefore an important step, but it should not be treated as a complete offboarding process. Administrators still need to check other credentials, connected applications, and active access methods.

The importance of checking these separate forms of access becomes clearer when looking at what attackers target. During the August 2026 npm compromise, Aikido reported that the malware collected npm tokens, GitHub credentials, AWS keys, Kubernetes secrets, and Stripe and Slack tokens. Those are also the types of credentials a contractor may accumulate while working across a small company's systems.

The central problem is that access is rarely controlled through a single account. A contractor may have several credentials connected to different platforms, and each one may need to be revoked separately.

What should you record when a contractor starts?

Create an access inventory on the contractor's first day. Record every system they are given access to, the type of account they use, and any credentials issued outside your single sign-on system. It takes only a few minutes to create and removes much of the guesswork when the contractor leaves.

NIST's account-management control AC-2(3) requires organisations to disable accounts that are no longer associated with a user or individual. You cannot reliably disable access that you never recorded. The inventory should therefore be treated as part of the security process, not as optional administration. Keep it alongside the rest of the contractor's engagement information, such as in a shared document or contractor tracker. Update it whenever new access is granted.

A useful inventory should cover five areas:

• System.

Record every system the contractor can access. This could include GitHub, AWS or another cloud provider, Google Workspace or Microsoft 365, Slack, your password manager, CI platform, production database, and other SaaS tools.

• Account type.

Note whether the account is managed through SSO, is a direct account, uses a shared login, or is a guest account.

• Credentials issued outside SSO.

Record personal access tokens, deploy keys, IAM access keys, API keys for third-party services, VPN profiles, and other credentials.

• Secrets they could read.

Include CI variables, environment files, and secrets stored in shared vault folders. A contractor does not need to possess a secret permanently for it to matter. If they have seen it, it may need to be rotated when they leave.

• Devices.

Record whether the contractor uses their own computer and whether company data is downloaded or synchronised to it.

Two decisions made when the contractor starts can make the eventual offboarding process much simpler. First, use credentials that expire whenever possible. AWS recommends temporary credentials such as IAM roles instead of long-term access keys, and many modern platforms provide scoped or expiring tokens.

Second, avoid giving contractors personal or shared secrets when a separate, restricted credential will work. The fewer long-lived credentials a contractor uses, the fewer credentials you need to track and revoke when their contract ends.

It is also worth scanning repositories for exposed secrets before the contractor leaves rather than waiting until after they have gone. Open-source tools such as Gitleaks and TruffleHog can help identify credentials that have been committed to code. A secret committed to a branch several months ago does not stop being a valid secret just because the contractor has stopped working on the project.

What does the offboarding checklist look like, system by system?

For a software team, most contractor offboarding can be organised around four areas: source control, cloud infrastructure, workspace accounts, and the secrets that connect these systems. Each requires a specific removal step. Each can also leave behind access, credentials, sessions, or data that needs to be dealt with separately.

Work through the checklist in this order on the contractor's last day. Where possible, have the contractor on a call for any steps that require their involvement.

• Transfer ownership before removing access.

Documents, repositories, cloud resources, and calendar events owned by the contractor should first be transferred to a named person. Google allows administrators to suspend users while retaining their data, but suspended accounts are still charged at the same rate as active accounts. Suspension should therefore be treated as a temporary holding state, not the final step.

• Kill active sessions.

In Google Workspace, administrators can reset a user's sign-in cookies. This signs the user out of their Google Account, including Google Workspace applications, across their devices and browsers. Also revoke application-specific passwords and remove access to third-party applications.

• Remove the contractor from source control and check their tokens.

Remove them from the organisation and from any repositories where they were added directly. If you use SSO, revoke their credential authorisations as well. Remember that revoking a SAML authorisation does not necessarily delete the underlying token or SSH key.

• Remove cloud identities and keys.

Delete or disable IAM users and deactivate their access keys. If the contractor accessed your cloud environment through a role managed by your identity provider, remove their access there as well.

• Rotate anything they could read.

This includes CI variables, production database passwords, third-party API keys stored in shared vaults, and other secrets listed in the access inventory. If a contractor has seen a secret, simply removing their account does not make that secret unknown to them. Rotation is what closes that gap.

• Confirm and record everything.

Work through every row of the access inventory. Record what was revoked, when it happened, and who completed the step. If an access problem appears later, you will then have a clear record of what was removed and when.

How do you end a contractor engagement without burning the relationship?

Agree on the offboarding process when the contractor starts and use the same process for everyone, including employees. Revoking access does not have to feel like an accusation. It is much less likely to create tension when the contractor already knows that access will be removed as part of the normal end-of-engagement process.

The process should also cover contractors who come through an agency or another third-party provider. NIST's PS-7 control expects external providers to notify organisations when their personnel are transferred or terminated. Ask the provider to make this notification part of the engagement from the beginning. If they cannot commit to telling you when someone leaves the project, that is useful information about how they manage access.

Tell the contractor on their first day that you keep an access inventory and that their final day will include a short access close-out. This makes the process predictable. It also gives the contractor an opportunity to confirm that they have returned or deleted anything belonging to the company.

Use the close-out call to ask the contractor to delete local repository clones, downloaded files, and other company data stored on their devices. GitHub makes clear that local copies remain with the person after repository access is removed, so the practical solution is a direct request backed by the confidentiality and data-handling terms in the contract.

Rotate shared credentials afterwards without making it personal. Changing secrets that a departing contractor could access is routine security maintenance. It should be treated in the same way as changing access after any other change in who knows a credential.

Finally, be direct when an engagement is ending because the arrangement is no longer working. A clear and documented close is better for both sides than allowing the relationship to fade while the contractor's access remains active. If work also needs to be transferred between people on a distributed team, the handover process is covered in RocketDevs' guide to handover on a distributed team.

Where we fit, and it’s a narrow point

If you run a team, contractor offboarding is ultimately your responsibility, regardless of where the contractor came from. The important thing is to know what access they have, when that access should end, and how you will revoke it.

RocketDevs engagements are set up with a defined start and end date. Screenshots every 3 minutes provide visibility while the work is taking place. A 14-day risk-free trial also gives teams a way to end an engagement early if it is not working. The broader point is simple: offboarding is easier when the end of the engagement is planned from the beginning.

For the contract side of working with contractors, see our guide to the contractor classification rules that changed in 2026. For the identity side of the engagement, see our guide to verifying a remote developer's identity.

Conclusion

Contractor offboarding is not an administrative task to deal with after the real work is finished. It is part of access management. The moment a contractor receives access to your code, cloud infrastructure, documents, secrets, or production systems, you need a clear answer to one question: how will that access end?

The safest approach is also the simplest. Record access when the contractor starts. Use scoped and temporary credentials wherever possible. When the engagement ends, transfer ownership first, then revoke accounts, terminate sessions, remove credentials, and rotate anything the contractor could still know. Finally, record what was done.

Small teams do not need a large security department to do this well. They need a repeatable process that does not depend on someone remembering what a contractor was given six months earlier. A ten-minute access inventory at the beginning can save hours of investigation at the end.

The goal is not to make contractors feel distrusted. It is to make access predictable. When everyone knows that access is granted for the duration of the work and removed when the work ends, offboarding becomes routine rather than confrontational. The cleanest contractor relationship is one where both sides know exactly where the engagement starts, what access is required, and how it ends.

Frequently asked questions

How quickly should you revoke a contractor's access?

Revoke access on the contractor's last working day, ideally within the same hour that the engagement ends. NIST's PS-4 control expects system access to be disabled and credentials revoked at termination, within a timeframe defined by the organisation. For a small team where production access may be concentrated among only a few people, same-day revocation is a sensible standard.

Does removing someone from a GitHub organisation revoke their tokens?

Not completely. GitHub says that revoking a member's SAML authorisation removes the authorisation but does not delete the underlying token or SSH key. A removed member may also still have local copies of your code. Remove the person from any repositories where they were added directly, then check the tokens and keys they created to make sure they can no longer be used.

Should you rotate shared secrets when a contractor leaves?

Yes. Rotate every shared secret the contractor could access. Removing their account does not remove information they have already seen. Rotating CI variables, database passwords, and third-party API keys closes this remaining gap. It should be treated as routine security maintenance rather than a sign of distrust.

What should a contractor offboarding checklist include?

Start with an access inventory created when the contractor joined. On their last day, transfer ownership of anything they manage. End active sessions and remove them from source control. Remove cloud identities and access keys. Rotate shared secrets they could access. Finally, record what was removed and when it happened.

James Hitch, COO at RocketDevs.LinkedIn

Sources

• NIST SP 800-53 Rev. 5 control catalogue, OSCAL, controls PS-4, PS-7 and AC-2(3)

• GitHub Docs, Removing an outside collaborator from an organization repository

• GitHub Docs, Removing a member from your organization

• GitHub Docs, Viewing and managing a member's SAML access to your organization

• AWS IAM User Guide, Manage access keys for IAM users

• Google Workspace Admin Help, Suspend a user temporarily

• Google Workspace Admin Help, Automatic OAuth 2.0 token revocation upon password change

• Google Workspace Admin Help, Manage a user's security settings

• Uber Newsroom, Security update, September 2022

• UK DSIT, Cyber Security Breaches Survey 2025

• Eurostat, ICT security incidents in enterprises, isoc_cisce_ic

• Stack Overflow Developer Survey 2025, Work

• Aikido Security, Keyv and friends compromised in npm supply chain attack

• GitHub API, gitleaks repository