GitHub now lets you automate SSO authorization for classic PATs and SSH keys

If you've ever administered a GitHub Enterprise Cloud account with multiple SSO-protected organizations, you know the pain: every classic token (PAT) or SSH key has to be authorized, organization by organization, by hand, by the credential owner themselves. Multiply that by dozens of orgs and by every token rotation, and you understand why so many people simply create a PAT with no expiration and hope for the best. It's the classic security-versus-operational-friction trade-off resolved, in practice, on the wrong side.

On September 16, 2026, GitHub published the answer to this problem in its changelog: enterprise administrators can now automate SSO authorization of existing classic PATs and SSH keys, via API, for up to 50 organizations in a single request. This applies to GitHub Enterprise Cloud accounts. Let's look at what changes for whoever builds the automation behind it.

What exactly was released

The feature has three pieces that need to fit together:

1. An enterprise (opt-in) setting that enables credential delegation. None of this turns on by itself: the admin has to explicitly enable it.
2. A GitHub App installed at the enterprise level, with the new enterprise_credentials:write permission.
3. A new REST API for enterprise credential authorizations that this App calls to authorize the credential in bulk.

The security logic is the most interesting detail of the announcement. The API does not receive the credential's secret. You identify the PAT by its token ID (the token's non-secret identifier) or the SSH key by its fingerprint. In other words, the App that orchestrates the authorization never touches the token's value or the private key. That's the correct design: credential automation that doesn't need to custody the secret drastically reduces the attack surface.

Before granting authorization, the API runs a set of validations:

• Confirms that each target organization belongs to the enterprise;
• Confirms that the credential owner belongs to each organization;
• Confirms that the enterprise uses enterprise-level SSO;
• Safely skips organizations where an active authorization already exists (the operation is idempotent in that sense, you can reprocess it without duplicating anything).

Why this matters for whoever operates credentials

The point the changelog barely touches on, but which is the heart of the matter: manual friction pushes teams toward long-lived tokens. When authorizing a new credential costs twenty clicks spread across twenty organization screens, the obvious (and terrible) way out is to never rotate. You create a PAT with no expiration, authorize it once across everything, and never touch it again. It's security being sabotaged by ergonomics.

With bulk authorization via API, rotation stops being a traumatic event. The flow I'd design in an enterprise environment would look roughly like this: the system that manages the service account generates a new PAT, gets its token_id, and fires a call to the App, which in turn calls the authorization API passing the list of orgs. The old token is revoked. All without human intervention and without anyone going through twenty SSO screens.

The two scenarios GitHub itself cites as the target:

• Rotating a service account token or automation credential spread across many organizations;
• Onboarding new organizations into the enterprise, when you want existing credentials to become valid for them without redoing the manual work.

The path to setting it up

You can't paste the exact payloads here because the changelog doesn't include them (the REST API reference documentation is the canonical source), but the setup sequence is clear and worth mapping out:

1. Create and install the GitHub App on the enterprise. It needs the enterprise_credentials:write permission. Installing an App at the enterprise level is its own flow, different from installing an App on a standalone org; GitHub has a specific page for this (link at the end).

2. Enable the delegation setting in the enterprise settings. Without this opt-in, the API responds by denying, even with the App installed and permissioned.

3. Collect the credential's non-secret identifier. For a classic PAT, the token_id. For an SSH key, the fingerprint. This is the integration point with your secrets manager or with the process that issues the credentials.

4. Call the bulk authorization API, passing the credential's identifier and the list of orgs (up to 50 per request). If you have more than 50 organizations, partition it into multiple calls.

5. Check the result. Since the API skips already-authorized orgs, a re-run should return consistent results. It's worth logging which orgs were actually authorized versus skipped, to keep an audit trail.

Where I'd tread carefully

A few honest caveats, because automating credential authorization is no joke:

*This is for classic PATs and SSH keys, not for fine-grained tokens. The changelog is explicit: classic* PATs. If your strategy has already migrated to fine-grained tokens, the authorization model is different, and this feature is not what you're looking for. Strictly speaking, the security ideal is still to move toward fine-grained tokens with minimal scope; this API serves whoever, for whatever legacy or tooling reason, still depends on classic PATs and SSH at scale.

Automating authorization doesn't replace governance. The fact that you can authorize a token across 50 orgs with a single call means a compromised App with enterprise_credentials:write can too. Treat this App as a highest-privilege credential: restricted installation, rotation of the App's own private key, and monitoring of its calls. The gain from not passing the PAT's secret through the API is real, but the power of bulk authorization is concentrated.

The opt-in is an architecture decision, not a harmless toggle. By enabling delegation, you're saying that Apps can authorize credentials on behalf of owners, without the dev's manual click. That removes a friction step which, in some threat models, was also a step of explicit consent. Make this choice with the security team in the room.

What remains open

The announcement is lean (a one-minute-read changelog), and there are still questions only the documentation and real-world use can answer: the exact rate-limit behavior in bulk authorization, how the API reports partial failures within a 50-org request, and whether there will be future parity for fine-grained tokens. For whoever administers Enterprise Cloud, though, the core message has already been delivered: the technical excuse for keeping an ever-lasting token is over. Rotating a classic PAT and SSH key now fits into a pipeline.

The official reference lives in two places worth bookmarking: the REST API endpoints for enterprise credential authorizations and the guide on installing a GitHub App on your enterprise, both linked from the original changelog.