A Verified badge on GitHub means a commit carries a signature that checked out against a key on the account. It helps show who made a commit. It does not show the code is safe, that the person intended it, or that the account was not taken over.
What signing is
GitHub's documentation says a signed commit or tag has a signature that can be cryptographically checked, which helps others trust that the change came from a trusted source. There are three methods:
- SSH. The simplest. You can upload an existing authentication key as a signing key. It needs Git 2.34 or later.
- GPG. You generate a key yourself. Setup is more involved, but keys can expire or be revoked.
- S/MIME. An X.509 key typically issued by an organization. It needs Git 2.19 or later, and you do not upload the public key to GitHub.
For most small teams SSH signing is the easy path.
What the badge states
By default the badge reads Verified when the signature checked out, Unverified when it was signed but could not be verified, and no status when unsigned. Vigilant mode is a stricter, off by default account setting. With it on, unsigned commits from that author show as Unverified, and a signed commit where a different author enabled vigilant mode can show as Partially verified.
Limits worth knowing
- Records are persistent. Verification is recorded at push time. Later key revocation or expiry does not change a status that was already Verified.
- Web commits. Commits made in the GitHub interface are signed with GitHub's own key and show as verified.
- Rebase and merge. That pull request option creates new commits GitHub cannot sign for the author, so they are not verified.
- Signing is not sign off. The page notes that signing a commit differs from signing off on it, which is a separate policy.
- Bots. Bot signatures verify only when the request is authenticated as the app and carries no custom author or committer data.
The second one matters. A Verified badge on a web commit tells you the commit went through GitHub, not that a particular laptop key signed it.
Requiring signatures
Branch protection can require signed and verified commits on a branch. The protected branches documentation warns that unsigned commits on the head branch can block a pull request even with squash merging, because GitHub checks the commits of the test merge.
Before turning it on, make sure everyone has a signing key set up and your merge method fits.
What it adds to security
Signing protects against someone committing in your name with a stolen or guessed email address. It does not protect against a stolen account with a registered key, a malicious insider, or a compromised dependency. Use it as one layer, with review and required checks. See also dismiss stale approvals.
A free scan of your dependencies is available at gold.safeguard.sh/scan.
Quick check
Does Verified mean the code was reviewed?
No. It only says the signature checked out. Review is a separate control, enforced by approvals and owners.
Sources
Last reviewed: 19 October 2026.
