No. A deploy key is attached to a repository, not to a user, so it keeps working after the person who added it leaves the company. Removing someone from the organization does not touch it. You have to list the deploy keys on each repository and remove or replace the ones nobody can account for.
What a deploy key is
GitHub describes a deploy key as an SSH key that grants access to a single repository. The public key is attached to the repository and the private key sits on a server, a build agent or a developer's machine. Its documentation says deploy keys are not linked directly to organization membership.
Three more facts matter at offboarding:
- They are read only by default, but write access can be granted when the key is added.
- A deploy key with write access can perform the same actions as an organization member with admin access on that repository.
- They are usually not protected by a passphrase, and they do not expire.
Put together: a long lived, unattended credential, possibly with write power, that survives every person change. That is exactly what a leaver review must catch.
Why they get forgotten
Deploy keys are created once, for a quick integration, and then never appear in anyone's access review because access reviews look at people. The key was added by someone who has since moved teams or left. Nobody remembers which server holds the private half.
A review you can run in an afternoon
- List repositories. Start with those the departing person administered, then widen to the whole organization.
- For each, open the deploy keys page and note the title, whether it has write access, and the date added.
- Match each key to a system. Ask the owner of the server or pipeline to confirm it is theirs.
- For unmatched keys, disable by removing them in a quiet window and watch for failures. A broken job is a clear sign of an owner.
- For matched keys with write access, ask whether read only would do. Often it will.
- For keys that must stay, rotate them: generate a new pair on the target system, add it, switch the job, then remove the old key.
- Record the owner and the rotation date in a register.
Alternatives that outlive staff changes
GitHub also documents machine users, which are accounts created for automation rather than people, added to repositories as collaborators or team members. In organizations they can be limited to read only. They do carry the same weakness of a typically unprotected SSH key, and GitHub notes that automated account creation is against its terms, though a single machine user for automation is allowed.
Whichever you choose, give the credential an owner role, not a person. A team mailbox or a service owner group should be named in your register so the next reorganization does not orphan it.
Make the check recurring
Add deploy keys to your quarterly access review. A short query or script that lists keys per repository, with age and write status, turns this from an archaeology exercise into a routine.
Quick check
Does removing a user from the org remove their deploy keys?
No. Deploy keys belong to the repository, so they remain until someone removes them on that repository.
Is a read only deploy key still a risk?
Less so, but it still exposes source code, which can include sensitive logic or configuration. Treat it as a credential and keep it in your register.
How often should deploy keys be rotated?
There is no universal figure. Rotate on staff change and after any suspected exposure, and set a regular interval your team can keep.
Safeguard's asset discovery and policy features can help you keep a living inventory of repositories and credentials, so these keys are not invisible. A free scan is available at gold.safeguard.sh/scan.
Sources
Last reviewed: 19 October 2026.
