Yes, for teams willing to run a small signing service. With an SSH certificate authority added to your GitHub organization, contractors authenticate Git over SSH with certificates that expire by themselves, so a lost laptop or a forgotten key stops working without anyone remembering to revoke it.
The idea in plain words
A normal SSH key is valid until someone deletes it from the account. An SSH certificate is a mechanism for one key to sign another. GitHub's documentation explains that if you use an SSH certificate authority (CA) to give organization members and outside collaborators signed certificates, you can add that CA to your organization or enterprise and let those contributors use the certificates to reach your resources.
GitHub validates the certificate's signature and fields, including its validity period, against the trusted CA you configured. GitHub's own example is an internal system that issues each developer a new certificate every morning, which expires at day end, protecting repositories if the certificate is later compromised.
Why it suits contractors
| Property | Personal SSH key | Signed short lived certificate |
|---|---|---|
| Expires on its own | No | Yes, at the validity period you set |
| Offboarding action | Someone must remove the key | Stop issuing, it lapses |
| Works with SAML SSO enforced | Needs authorization step | GitHub says no authorization needed |
| Covers outside collaborators | Yes | Yes |
| Setup cost | Low | Higher, you run a CA and issuer |
GitHub also notes that certificates added at the enterprise level grant access to all organizations owned by the enterprise account, so scope the CA carefully if you use one enterprise wide.
What it does not do
Two limits stand out from the documentation:
- Unless you make certificates a requirement, members and outside collaborators can keep using other ways to authenticate with Git, including their own SSH keys and tokens. A CA you do not enforce is a convenience, not a control.
- Certificates cover Git over SSH. They do not control web sign in or API tokens, so your token policy and two-factor rules still apply.
How to try it
- Choose where the CA private key lives. Protect it like a root credential, ideally in a hardware backed or managed key store.
- Build or adopt an issuer that signs a contractor's public key after checking their identity and approval. Tie issuing to your access register.
- Add the CA's public key in the organization settings.
- Pilot with one staff member, then one contractor.
- Set a short validity, such as a working day or a week, and measure how often people hit expiry.
- When ready, require certificates for the repositories that matter most, then phase out standing keys.
Decide whether it is worth it
Certificates make sense when you have many contractors over time, a regulated codebase, or an audit trail requirement that favors time bound access. They are overkill for a single freelancer on a three week task, where a fork workflow, narrow role and tidy offboarding work well. See forks or branches.
Operations to plan for
- Who is on call when the issuer is down and a contractor cannot push?
- How do contractors request a new certificate, and how fast?
- How do you log issuance for your evidence file?
- How do you rotate the CA key itself?
The simpler alternative
If you cannot run a CA, you can still shorten exposure with a periodic review of SSH keys on contractor accounts, the monthly audit log routine, and strict removal at exit.
Safeguard's compliance and evidence automation can record issuance and review evidence, and its policies and gates add checks on each pull request. Try the free scan.
Quick check
Do contractors have to use certificates once a CA is added?
Only if you make them a requirement. Otherwise GitHub says people can keep using other authentication methods.
Does a certificate work with SAML SSO?
GitHub says signed certificates can be used even when SAML single sign-on is enforced, without authorizing them separately.
Sources
Last reviewed: 19 October 2026.
