A Verified badge means the commit was signed and GitHub could verify the signature against a key tied to the committer. It helps show where a change came from. It does not show the code was reviewed, that the author agreed to it, or that it is safe.
The three statuses
GitHub's documentation defines them:
- Verified: signed, and the signature checked out.
- Unverified: signed, but the signature could not be verified.
- No status: not signed.
Signing methods are GPG, SSH and S/MIME. SSH is described as the simplest, since you can reuse an existing authentication key. It needs Git 2.34 or later. S/MIME needs Git 2.19 or later and uses an organization issued certificate.
What it proves
Someone with access to the signing key made, or at least committed, this change. That is useful when someone fakes an author name. Git lets anyone set any author email, and a signature makes that impersonation visible.
What it does not prove
- That the code is good. A signed commit can still contain a bug or a backdoor.
- That someone reviewed it. Review is a separate control.
- That the author consented. GitHub's vigilant mode exists for this gap. In it, a commit can show Partially verified when the signature is valid but an author who is not the committer has vigilant mode on. The docs say the signature then does not guarantee the author's consent.
- That the key was safe today. Verification is persistent. Once verified, the record stays even if the key later expires or is revoked.
Requiring signatures
Repository administrators can require signed commits on a branch, which blocks unsigned or unverifiable commits. See branch protection options.
A catch: rebase and merge creates new commits that GitHub cannot sign for the author, so they will not show as verified. GitHub suggests rebasing locally and pushing. Commits made in the web interface are signed by GitHub with its own key. Test your merge method before you turn the rule on, or your team will be blocked on day one.
When it is worth the effort
Signing is cheap in a small team and a good habit where you need an audit trail. It matters more when:
- contributors use many machines or bots,
- you want to detect spoofed authors,
- an auditor asks how you attribute changes.
It matters less than review requirements, status checks and protected branches. If you must choose, do those first.
A short rollout plan
- Pick SSH signing for simplicity.
- Have each developer upload a signing key.
- Check the merge method used in your repositories.
- Enable the requirement on one low risk repository.
- Expand once the friction is understood.
For a hands on setup guide, see how to set up signed commits with GPG.
Safeguard compliance and evidence automation can help record these controls for audits. The free scan is at gold.safeguard.sh/scan.
Quick check
Does a Verified badge mean the code was reviewed?
No. It only concerns the signature on the commit.
Why are my rebased commits unverified?
Rebase and merge on GitHub creates new commits it cannot sign for the author. Rebase locally and push instead.
Sources
Last reviewed: 19 October 2026.
