Your GitHub account is not just a place where code lives. For many freelancers and solo founders, it is connected to client repositories, private source code, deployment pipelines, package publishing, API tokens, SSH keys, GitHub Actions secrets, and sometimes production infrastructure.
That makes GitHub a business-critical account. Losing access can block delivery. Losing control can expose client work or let someone change code that later reaches production.
This guide is written for individual developers and small technical operators who need a practical GitHub hardening plan without turning it into an enterprise identity project.
The short version
Start with recovery. Confirm your email address, password manager entry, two-factor authentication, recovery codes, passkeys or security keys, SSH keys, and active sessions before you make aggressive changes.
Then reduce unnecessary access: remove old OAuth apps, stale personal access tokens, unused SSH keys, old deploy keys, inactive collaborators, and broad repository permissions. For GitHub Actions, treat repository secrets like production credentials and remove anything no longer needed.
If you work with clients, separate personal projects from client access as much as GitHub allows. Named accounts, clear organization membership, and least-privilege repository access are safer than shared credentials or one admin account used everywhere.
Who this is for
This is for freelancers, developer-consultants, solo founders, indie hackers, and small teams who manage GitHub without a dedicated security team.
It is especially relevant if your GitHub account has access to private client repositories, deployment workflows, package registries, infrastructure-as-code, production secrets, or code-signing and release processes.
Step 1: Confirm your recovery path first
Before changing security settings, make sure you can recover the account.
Check that your primary GitHub email is current, your password is unique and stored in your password manager, and your recovery codes are saved outside GitHub. If you use a passkey, authenticator app, or security key, make sure you have at least one fallback method before signing out of existing sessions.
GitHub supports several recovery paths, but you should not assume support will immediately restore access. Recovery delays are painful when GitHub controls client work or deployments.
For a broader recovery workflow, read the solo founder account recovery plan and where to store backup codes and recovery keys.
Step 2: Use strong MFA without creating a lockout
Turn on two-factor authentication and add more than one recovery method where possible. A practical setup might include:
| Method | Role |
|---|---|
| Authenticator app | Everyday fallback if passkey or security key is unavailable. |
| Passkey | Convenient phishing-resistant sign-in on supported devices. |
| Hardware security key | Strong backup for high-value accounts and travel/device loss scenarios. |
| Recovery codes | Last-resort access when normal MFA is unavailable. |
Do not rely on one phone with one authenticator app as the only way back in. If that phone is lost, wiped, or unavailable while travelling, a security improvement can become a business outage.
For a safer MFA rollout, use the MFA lockout guide.
Step 3: Review SSH keys
SSH keys often survive longer than the laptops they were created on. Open your GitHub SSH keys page and remove keys you no longer recognize, keys from old machines, keys with unclear names, and keys used for temporary client projects that have ended.
Name active keys clearly. A key called laptop is harder to audit six months later than thinkpad-2026-work.
If you keep multiple machines, each should have its own key. Do not copy one private SSH key across every device. If one machine is compromised or lost, separate keys make cleanup easier.
Step 4: Review personal access tokens
Personal access tokens can be more dangerous than passwords because they are often pasted into command-line tools, CI systems, scripts, and old project folders.
Review fine-grained and classic personal access tokens. Remove tokens you do not recognize, tokens for old experiments, broad tokens with access to many repositories, tokens stored in abandoned tools, and tokens that have no expiration.
Prefer fine-grained tokens with narrow repository access and expiration dates. If a tool only supports broad classic tokens, document why it exists and review it regularly.
Also search your local projects for accidental token storage. Pay special attention to .env files, shell history, deployment scripts, and old README snippets.
Step 5: Remove stale OAuth and GitHub Apps access
OAuth apps and GitHub Apps can read or write repository data depending on their permissions. Over time, a developer account can accumulate access granted to code editors, deployment tools, automation products, AI coding tools, SaaS demos, and one-off experiments.
Review authorized apps and remove anything you do not actively use. If an app still matters, check whether it needs account-wide access or only selected repositories.
This is especially important for client work. Do not leave an old tool connected to a client organization after the project ends.
Step 6: Audit organizations and repositories
Look at the organizations you belong to and the repositories where you have elevated access. Ask a simple question for each one: would it be a problem if this account were compromised tonight?
Remove yourself from old client organizations when work has ended. Downgrade admin access where write access is enough. Remove collaborators who no longer need access to your own repositories. For repositories that trigger deployments, check branch protection, required reviews, and who can push to release branches.
If you manage a small team, avoid using one shared GitHub account. Shared admin accounts make attribution, revocation, and recovery harder.
Step 7: Treat GitHub Actions secrets as production material
GitHub Actions secrets often contain deployment tokens, cloud credentials, API keys, package registry tokens, and webhook secrets. Those deserve the same care as credentials stored in a password manager.
Review repository and organization secrets. Remove unused values, rotate credentials from old projects, scope cloud tokens narrowly, and avoid using one powerful token across many repositories.
If a workflow deploys to production, review who can edit the workflow file. A secret is only as safe as the people and branches allowed to run code that can read it.
Step 8: Secure package and release workflows
If your GitHub account can publish packages, cut releases, update documentation sites, or trigger deployments, the account controls more than source code.
Document which repositories publish artifacts, where package tokens are stored, which accounts can approve releases, and what you would do if a release token leaked. For small projects, this can be a short note in your recovery plan.
Do not store package registry tokens in local notes or chat history. Put them in the appropriate secret store and rotate them when a project changes hands.
A simple monthly GitHub security check
Once a month, review:
| Area | What to check |
|---|---|
| Recovery | Email, MFA methods, recovery codes, trusted devices. |
| Access | Organizations, collaborators, repository roles. |
| Credentials | SSH keys, personal access tokens, deploy keys. |
| Integrations | OAuth apps, GitHub Apps, deployment tools. |
| Automation | Actions secrets, workflows, branch protections. |
This should take 20-30 minutes once the first cleanup is done.
Common mistakes
The most common mistake is enabling MFA but never saving recovery codes. That improves security until the day your phone disappears.
Another common mistake is ignoring tokens and OAuth apps. Developers often secure the login page but leave old automation credentials scattered across tools and repositories.
Client access is another weak spot. If you keep admin access to old client organizations, a compromise of your personal GitHub account can become someone else’s incident.
Good next step
Open your GitHub security settings and do three things: confirm recovery codes, review SSH keys, and remove one unused token or app.
Then read: