Safeguard
Developer Tools•

Fine-grained or classic GitHub personal access tokens: how to choose

GitHub recommends fine-grained personal access tokens. Here is how they differ from classic ones, where they fall short, and when classic is still needed.

Safeguard Security Team
3 min read

Use a fine-grained personal access token whenever you can. GitHub recommends them because they can be limited to one owner, to selected repositories, and to specific permissions. Classic tokens are the fallback for the cases fine-grained tokens cannot yet handle, and they reach everything you can reach.

The main differences

GitHub's documentation compares the two types on a few points.

  • Resource owner. A fine-grained token belongs to one user or one organization. A classic token spans every organization and your personal account.
  • Repository scope. Fine-grained tokens can be limited to selected repositories. Classic tokens can touch every repository you can access.
  • Permissions. Fine-grained tokens use specific permissions. Classic tokens use broad scopes, such as the repo scope that command line Git commonly needs.
  • Organization control. Owners can require approval for fine-grained tokens, and until approved the token reads only public resources. Owners can restrict or disable classic tokens entirely.

Expiry

Both types are tied to the person who made them and stop working if that person loses access to the resource. For fine-grained tokens, the documentation gives a default lifetime of 30 days, shorter if a policy applies, and allows never expiring tokens unless an organization or enterprise policy blocks that. GitHub removes classic tokens unused for a year and strongly recommends an expiry on every token.

A short expiry turns a forgotten token into a self-limiting problem.

Where fine-grained tokens fall short

GitHub lists gaps. Fine-grained tokens cannot be used to contribute to public repositories you do not belong to, to work where you are an outside collaborator, to reach several organizations at once, to use Packages, to call the Checks API, or to access user-owned Projects. You can also hold at most 50 of them.

If your task hits one of these, classic is the documented fallback. Give that token the fewest scopes and the shortest life you can, and write down why it exists.

When a token is the wrong tool

For automation and higher volume, GitHub points to a GitHub App instead. A personal token is tied to one person, which is a poor fit for a pipeline that should outlive them. See deploy keys, GitHub Apps or machine users.

A short routine

  1. List the tokens you hold and delete any you do not recognise.
  2. Replace classic tokens with fine-grained ones where possible.
  3. Set an expiry on everything.
  4. For organizations, turn on approval so new tokens are reviewed.

Quick check

My fine-grained token cannot push to a public repo I do not own. Why?

GitHub lists contributing to public repositories where you are not a member as a current limitation. Use a classic token or the normal fork workflow.

Do tokens survive when the owner leaves a team?

No. They become inactive when their creator loses access to the resource.

Safeguard gates and guardrails can sit around the pipelines these tokens feed. The free scan at gold.safeguard.sh/scan is a no setup way to see your dependency risk today.

Sources

Last reviewed: 19 October 2026.

Never miss an update

Weekly insights on software supply chain security, delivered to your inbox.

Self-healing security runs on Safeguard.

Your first fix PR is minutes away.

No sales call required, even your agent can complete the purchase over MCP.