Yes. GitHub records a commit's verification at push time and does not re-verify it when keys change, so commits stay Verified after the author's key is rotated, revoked or expires, or after they leave the organization. A Verified badge proves a past signature check, not that the author is still trusted.
What the badge means
GitHub supports commit and tag signing with GPG, SSH and S/MIME. A commit shows Verified when it is signed and the signature checks out, Unverified when it is signed but cannot be verified, and no status when it is unsigned. Commits made in the GitHub web interface are signed by GitHub and show as verified.
Two things follow for offboarding.
First, the record is permanent. GitHub states that previously verified commits keep their status even if the contributor leaves the organization, and that the record cannot be edited. The verification timestamp is visible on hover and in the API field verified_at.
Second, GitHub does not re-verify old commits in response to key changes. Organizations with strict policies may need to manage key states themselves.
Why this matters after someone leaves
Imagine a developer's laptop is compromised a month after they leave, and their signing key is used elsewhere. New commits signed with that key could appear as verified if the key still sits on their account. Removing the key from the account is what changes new verification results. Past commits will not change either way.
So treat the badge as an input to investigation, not a verdict. When you review history after an incident, check the author, the verification time and whether the key was valid at that moment.
Offboarding steps that cover signing
- Remove the person's signing keys and SSH keys from the account if the account is one you control, such as a managed account.
- For GPG keys, revoke them. GitHub notes GPG keys can expire or be revoked and signatures can reflect that, a feature SSH signing lacks.
- Remove the person's access so they cannot push new signed commits to protected branches.
- Keep the verification data. Record the date access ended, so reviewers can compare it with commit timestamps.
- If your branch rules require signed commits, confirm they still do after the person's group changes.
- For any commit made after the leave date under that identity, investigate.
Practical differences between signing methods
| Method | Notes from GitHub documentation |
|---|---|
| SSH | Simplest to set up, needs Git 2.34 or later, no revocation status |
| GPG | Keys can expire or be revoked, signatures can reflect status |
| S/MIME | Usually used in larger organizations with an X.509 key from the organization, needs Git 2.19 or later |
If you need revocation to be visible, GPG or S/MIME gives you more to work with. Many teams choose SSH signing for simplicity and rely on removing keys and access instead.
A related gotcha
Rebase and merge creates new commits that GitHub cannot sign on your behalf, so they are not verified. A merge strategy change can make your history look less trusted without any security event. Know your strategy before reading the badges.
Quick check
Does Verified mean the author is still employed?
No. It means the signature checked out when the commit was pushed.
Can I make GitHub re-verify old commits after revoking a key?
Not per the documentation. Old verification records are not updated when keys change.
Safeguard's policies and gates can enforce rules on pull requests and help you evidence them for audits. A free scan is available at gold.safeguard.sh/scan.
Sources
Last reviewed: 19 October 2026.
