Enterprise GitHub App installations offer a safer alternative to classic PATs

GitHub has made enterprise-level installations of GitHub Apps generally available. Expanded permissions and API coverage allow organisations to replace classic personal access tokens (PATs) in more governance and security automation spanning multiple organisations.

The new capabilities cover repository policies, rulesets, bypass requests, two-factor authentication requirements, verified domains, IP allowlists and enterprise access restrictions. GitHub Apps can also manage member privileges and repository access settings.

Breachroad’s conclusion: moving from PATs to a GitHub App improves attribution and scope control, but the mechanism’s name does not guarantee least privilege. An app that can change policies, 2FA requirements and IP allowlists is a privileged machine identity that needs oversight comparable to an administrator account.

What GitHub made available

An enterprise can now install an app without building a separate identity model for each organisation. GitHub expanded permissions across three areas.

Governance covers enterprise repository policies and rulesets, as well as reading rule-bypass requests. Automation can control private repository forking, default repository permissions, visibility changes, repository creation and deletion, issue deletion, collaborator invitations, deploy keys and protected-branch updates.

Security covers 2FA requirements and disallowed authentication methods, verified domains, enterprise and organisation IP allowlists, and enterprise access restrictions. Operations can also toggle allowlist enforcement, trust of GitHub Apps and user-level enforcement for Enterprise Managed Users.

Administration allows enterprise-profile changes, member-privilege management and repository access settings. GitHub also closed some coverage gaps in existing people and billing permissions.

The capabilities are scheduled for GitHub Enterprise Server 3.24.

Why classic PATs are problematic in automation

A classic PAT belongs to a human and often carries broad scope derived from that person’s role. When a token enters a script that runs for years, several problems arise:

• its owner changes role or leaves, breaking the automation;
• human actions are difficult to distinguish from scripted activity;
• the token has more authority than the process requires;
• rotation depends on a personal account and one individual’s memory;
• the secret is copied across CI/CD, vaults and documentation;
• incident response must remove access from the person and automation together.

A GitHub App creates a separate integration identity, supports selected permissions and uses short-lived installation tokens. That improves attribution and limits the impact of credential exposure.

It does not mean every workflow should share one “super app”. Compromise of a central app able to alter rules, 2FA and IP allowlists could affect the entire enterprise.

Planning a PAT migration

1. Inventory tokens and their actual jobs

Do not begin with secret names alone. Combine audit logs, CI/CD configuration, secret-manager records and discussions with process owners. For every PAT, record its owner, purpose, APIs used, organisations, environment, last use and failure consequence.

2. Separate automation by impact

Reading reports, managing repository policies, changing 2FA requirements and editing IP allowlists should not automatically share one app. Separation limits blast radius and supports independent approval.

3. Grant minimum permissions

Choose exactly the GitHub App permissions the workflow needs. A process that reads bypass requests does not need to edit rulesets. One that reports 2FA state should not be able to change permitted methods.

4. Protect the private key and token flow

An installation token is short-lived, but it still needs a secure method of issuance. Store the app’s private key in a controlled secret manager, restrict the calling process, log use and establish rotation. Never emit generated tokens into job logs.

5. Test and prepare rollback

Run the new app against a limited scope first. Verify not only that intended tasks succeed but also that out-of-scope operations fail. Automation that changes enterprise settings needs input validation, approval and a safe rollback path.

6. Revoke the old PAT

Migration ends only after the token is invalidated, its copies are removed and no job still depends on it. Keeping a PAT “just in case” preserves the original risk.

Controls for privileged apps

An app that changes rulesets, repository access, 2FA requirements or IP allowlists should have:

• named business and technical owners;
• a documented scope and justification for every write permission;
• alerts for installation, permission changes and unusual operations;
• multiple approvals for policy-weakening changes;
• a separate test environment or controlled pilot scope;
• periodic usage reviews and automated inactivity detection;
• a revocation plan that preserves emergency enterprise access.

Automation becomes particularly risky when it can disable the control that protects the automation itself. If an app edits IP allowlists or rulesets, its pipeline should not approve its own exceptions.

Measuring migration outcomes

The number of replaced PATs alone does not show whether risk declined. Better measures include:

• classic PATs still used by non-human processes;
• apps with unused write permissions;
• average token lifetime in automation;
• apps without a named owner and review date;
• workflows able to alter policy without additional approval;
• time from workflow retirement to revocation of all credentials.

Source facts and Breachroad’s analysis

GitHub confirms general availability of enterprise installations; new permissions for policies, rulesets, bypasses, 2FA, domains, IP allowlists, access restrictions, people and repositories; and availability in GHES 3.24. The vendor says classic PATs can now be replaced in more automation scenarios.

Separation by impact, the migration process, governance controls and metrics are Breachroad recommendations. Connect them to secrets management and rotation and webhook security. Platform owners, developers and security teams can rehearse responsibilities through cybersecurity training for organisations, while an IT security audit can assess app configuration.

Primary source: GitHub Changelog — Enterprise installations for GitHub Apps generally available.