Retire GitHub deploy keys separately from the employee account that created them

Repository-attached deployment credentials can remain active after their creator no longer has access.

Source facts

A GitHub deploy key grants SSH access to one repository and is attached to the repository rather than a personal account. Deploy keys are read-only by default, can be given write access and have no expiry date. GitHub states that removing the creating user from the repository does not deactivate the key. Multiple repositories require separate deploy keys.

Source: GitHub — Managing deploy keys.

Applicability

This concerns repository deploy keys, not personal SSH keys or GitHub App installation tokens. The appropriate automation identity depends on the actual integration and required permissions.

DSE recommendation

DSE recommends including deploy keys in both service retirement and employee offboarding reviews. Record the server, repository, purpose, permission level and current service owner for each key. Reassess any write grant explicitly and protect the server-side private key. Consider the documented GitHub App alternative when the integration needs managed permissions across repositories rather than accumulating unidentified deployment credentials. Include the key’s repository attachment in the offboarding handoff so removal of a person is not accepted as credential retirement evidence. Assign a current service owner and a separate revocation check to each automation that still depends on a deploy key.

Verification

Proposed verification: inspect repository deploy-key inventory and compare it with the servers that still use each credential. In an approved test integration, verify the intended read or write scope and confirm revocation stops access. Retain public identifiers and outcomes only; never copy private keys into tickets or publication evidence.

Official reference

GitHub — Managing deploy keys. Reviewed October 20, 2026.