Removing a developer from a GitHub repository does not remove the repository's deploy keys. GitHub documents that deploy keys remain active after their creator loses repository access. They are attached to the repository, rather than the person's membership, and have no expiry date. The documentation was reviewed September 18, 2026.
That distinction matters when someone set up deployments and could access the private key. Their company account can be disabled while a separate credential they possessed remains usable. This does not mean the former employee retained a copy. It means deleting their membership is insufficient evidence that every route available to them has closed.
An offboarding review needs to follow the credentials the person could use, including credentials assigned to a service. Start with the systems they administered and establish who owns each remaining connection.
Work through one deployment before closing the ticket
Consider a hypothetical startup whose contractor configured a server to pull a private repository. The contractor's personal GitHub access is removed at the end of the engagement. The server continues deploying with a repository deploy key whose private half the contractor could read.
The company needs the deployment to keep working. It also needs a basis for concluding that the old credential no longer grants access. For this example, the handoff record should look like this:
| Record | What the engineer enters |
|---|---|
| Credential identity | The deploy key's label and public fingerprint, never its private value |
| Consumer | The server and deployment process that use it |
| Access | The specific repository and whether write access is enabled |
| Replacement owner | A current employee responsible for the deployment |
| Change evidence | When the replacement was installed and the old key removed |
| Verification | A successful deployment using the replacement and a failed authorized check using the retired key |
For a planned handoff without signs of compromise, stage and verify the replacement before retiring the old credential. If compromise is suspected, immediate revocation may take precedence over keeping deployments available. Write down that decision rather than allowing an undocumented dependency to delay it.
Use a harmless repository access check for verification. There is no reason to push a production change simply to prove that a retired credential no longer authenticates. Keep secret values out of the offboarding ticket and its screenshots.
Token revocation has a specific scope
GitHub provides another useful example of why credential types need separate treatment. Its organization token-review documentation, reviewed September 18, 2026, says that revoking a fine-grained personal access token's organization access does not stop SSH keys created by that token from working. It also distinguishes that review interface from personal access tokens of the classic type.
Read the result of a revocation operation narrowly. If the operation removed one token's access to one organization, record exactly that. Do not turn it into an assertion that every credential the person created has been invalidated.
This is also why a generic checklist item such as “GitHub removed” is difficult to review later. Replace it with the actual membership change and a separate decision for any service credentials the departing person could retrieve or administer. The reviewer should be able to identify the remaining access without reconstructing the whole deployment.
Shared credentials need a handoff, even when the service stays
For cloud workloads, AWS recommends temporary credentials through IAM roles and regular review of unused access. Its guidance, reviewed September 18, 2026, also addresses the cases where long-term credentials remain necessary. A useful review distinguishes the workload's ongoing need from the departing person's ability to reuse a credential.
Apply that distinction to the systems in the example. If the contractor only used a personal, revocable identity, review that identity's removal. If they could read a shared deployment secret, establish whether it needs replacement and which consumers must change. Do not rotate unrelated credentials merely because they appear in the same account.
A machine identity can be the appropriate owner of an automated process. Assign a human maintainer to it anyway. In the handoff, that maintainer accepts responsibility for its permissions and knows how to revoke it. Naming a replacement owner without verifying that they can administer the integration leaves the next departure with the same problem.
Keep the failed access check with the handoff
For a startup preparing evidence for an access review, the example record supports a precise claim: this deployment was transferred, this old key was removed, and these checks were performed. It does not establish that every account across the company was found, or settle the requirements of a particular audit.
Keep uncertainty visible. If nobody can determine whether the departing person had access to a shared secret, record that gap and the decision made about replacement. A completed checkbox should not erase an unresolved dependency.
Take the most recent engineering departure and follow one production deployment they maintained. Confirm its current owner and identify how it authenticates. If the only evidence is that the person's account was removed, reopen the credential portion of the handoff and finish it.