Deploy keys survive because they are tied to a repository, not to a user. GitHub documents that if the person who added a key is removed, the key stays active. Anyone holding the private key can still read, or write if allowed, until you delete it from the repository.
What GitHub says about deploy keys
GitHub's documentation lists several properties that matter for offboarding:
- A deploy key grants access to a single repository.
- Deploy keys are read only by default, but can be given write access when added.
- They are usually not protected by a passphrase, so anyone with the file can use it.
- They are credentials without an expiry date.
- They are not linked to organization membership. If the user who created the key is removed from the repository, the key remains active, because it belongs to the repository.
The roles documentation repeats the point as a warning: when someone adds a deploy key, any user who has the private key can read or write (depending on settings) even if they are later removed from the organization.
Why contractors create them
Contractors set up build servers, staging hosts and scripts. A deploy key is the quickest way to let a server pull code. It works, nobody reviews it, and months later nobody remembers who owns the private half.
The exit sweep
- List the deploy keys on every repository the contractor worked in, under the repository settings, and on any repository where they asked an administrator to add one.
- For each key, record the title, the date added, whether it has write access, and the server that uses it.
- Identify which keys the contractor generated and which are still needed.
- Generate replacement keys on your own infrastructure for anything still needed, deploy them, and then delete the old key.
- Delete keys that nothing uses.
- Check the audit log for key additions and removals around the engagement dates. GitHub retains audit log events for the last 180 days, so run this review promptly rather than a year later.
Prefer designs that avoid shared long lived keys
| Approach | Tied to a person | Expiry | Offboarding effort |
|---|---|---|---|
| Deploy key | No, tied to a repo | None | Manual review each time |
| Personal access token | Yes | Policy can limit lifetime | Revoked when the account loses access |
| Short lived credentials issued by your pipeline | No | Minutes or hours | Little to do |
Where your platform supports it, short lived credentials issued at run time remove the whole class of problem. If you must keep deploy keys, name them with an owner and an end date, such as the system name plus a review date, and add them to a register you check each quarter.
A note on machine accounts
Some teams create a shared machine user for contractors. GitHub's guidance on managing deploy keys lists machine users as one option, but a shared account hides who did what and its password or token outlives any one person. If you use one, treat every departure as a reason to rotate its credentials.
Keep it from recurring
- Make deploy key creation an exception that needs a ticket.
- Keep the Admin role rare, since it covers sensitive repository settings.
- Run the quarterly review described in contractor access never expires.
- Add the sweep to your offboarding checklist.
Safeguard's asset discovery helps you see repositories and pipelines you may have forgotten, and its compliance and evidence automation can record that the review happened. See the free scan.
Quick check
Do deploy keys expire?
No. GitHub documents deploy keys as credentials that do not have an expiry date, so you must remove them yourself.
Does removing a user remove their deploy keys?
No. The key is tied to the repository, so it stays active until someone deletes it from the repository settings.
Sources
- Managing deploy keys
- Repository roles for an organization
- Reviewing the audit log for your organization
Last reviewed: 19 October 2026.
