What GitHub App enterprise installs mean for PATs

On October 23, 2026, GitHub announced that installing GitHub Apps on an entire enterprise account is now generally available, according to the GitHub Blog changelog. GitHub also expanded the API permissions those apps can request. The new permissions focus on enterprise governance, security and administrative settings, and two gaps at the organization level are now closed. The practical result: more of the enterprise automation that has had to run on a classic personal access token can now run as a GitHub App instead.

The background you need

Every script, bot or CI job that calls the GitHub API has to prove who it is. There are a few common ways to do that. The differences between them are the whole story here.

Classic personal access tokens (PATs). A classic PAT is a token you generate under your own user account. When a script uses it, GitHub treats every request as coming from you. Its permissions are set with scopes, which are broad buckets. A single scope can cover every repository you can reach. Classic PATs can also live a long time if nobody sets an expiry. This causes two familiar problems. If the person who created the token leaves or loses admin rights, the automation breaks. If the token leaks, whoever holds it gets that person’s access.

Fine-grained PATs. These are a newer kind of personal token with narrower, per-resource permissions. They are an improvement, but they are still tied to a human account.

GitHub Apps. A GitHub App is an identity of its own, separate from any person. You register the app once, choose exactly which permissions it needs (for example, read-only on one area and write on another), and then install it on an account. At runtime, the app proves its identity with a private key. It exchanges that proof for short-lived installation tokens and uses those to call the API. In logs, the actions show up as the app rather than as a colleague.

Enterprise accounts. On GitHub Enterprise Cloud, an enterprise account sits above your organizations. Policies, security settings and administrative controls that span every organization live there. Until now, apps have commonly been installed on organizations or repositories. An enterprise installation lets an app work at that top layer.

GHES. GitHub Enterprise Server is the self-hosted version of GitHub. It ships in numbered releases, and features from the cloud service arrive in a specific release.

Generally available (GA). This is GitHub’s label for a feature it supports for production use, as opposed to a preview.

Here is an analogy. A classic PAT is like handing a contractor a copy of your own master key. It opens every door you can open, and the building log says you walked in. A GitHub App is like issuing the contractor a badge for a defined role. The badge is programmed for specific doors, and the readers log the badge. The analogy breaks down in one important place. Someone still has to guard the app’s private key, because anyone holding it can mint new tokens. And someone with the right enterprise role still has to approve the installation. Apps move the risk around. They do not remove it.

What actually changed

According to GitHub, three things are new in this announcement:

1. Enterprise installations are GA. You can install a GitHub App on your enterprise account as a supported, production feature.
2. New and expanded enterprise permissions. GitHub says these focus on governance, security and administrative settings for the enterprise. The stated goal is to let you replace classic PATs with GitHub Apps in more of your enterprise and organization automation.
3. Two organization-level gaps closed. GitHub says some APIs and objects had gaps in their support for GitHub Apps, and that “These fixes should unblock more automation scenarios with those permissions.”

GitHub also says these updates will be available in GHES 3.24. It points readers to its documentation on managing an enterprise account with GraphQL and on installing a GitHub App on an enterprise.

What was already true: GitHub Apps already existed, and they were already a common choice for organization and repository automation. The new part is coverage. Enterprise-level admin work is often exactly where teams fell back on a classic PAT, because an app could not do the job. GitHub is narrowing that gap.

What the announcement does not say: it does not say classic PATs are deprecated, restricted or scheduled for removal. Your existing tokens keep working as before. This change gives you an alternative. It does not set a deadline.

What it means for you

You may not administer an enterprise yourself. But you have probably written or inherited a script that does: a nightly job that exports settings, a bot that enforces policy across organizations, or a CI step that calls an admin endpoint. Many of these run on a classic PAT created years ago by someone who may no longer be on the team.

The expanded permissions matter because they decide whether a given script can move at all. A GitHub App can only call an endpoint if a matching permission exists. Before this change, some enterprise endpoints had no app path, so the PAT stayed. Now more of them do.

Concretely, you can:

• Inventory your PATs. Search your CI secrets and config for tokens used against enterprise or organization admin APIs. Note which endpoints each script calls.
• Match endpoints to permissions. Check each endpoint against the permission list in GitHub’s changelog and documentation. Do not assume coverage. Verify it.
• Create a narrowly scoped app. Pick only the permissions each workflow needs. GitHub’s own getting-started advice is to choose permissions for the workflows you want to migrate.
• Swap the authentication code. Your script stops reading a static token. Instead, it signs a request with the app’s private key and fetches an installation token. Common API client libraries can handle this flow for you.
• Store the private key carefully. It now plays the role your PAT used to play.

The payoff is a smaller blast radius if something leaks, tokens that expire on their own, and automation that does not break when one person changes roles.

If you run GHES, check your version. According to GitHub, these updates arrive in GHES 3.24, so plan any migration around your upgrade schedule.

What we don’t know yet

• The exact endpoint list. The announcement text we worked from summarizes the new permissions by theme: governance, security and administrative settings. To confirm your endpoints are covered, check the changelog and GitHub’s docs directly.
• What still requires a PAT. GitHub says it is enabling replacement in more of your automation, which implies not all of it. The announcement does not list what remains unsupported.
• The future of classic PATs. Nothing here signals a deprecation timeline. Whether one follows is an open question.
• When GHES 3.24 ships. The announcement names the release but not a date.