GitHub Can Now Authorize One Credential Across 50 Organizations

This removes a real service-account headache. Rotating one credential no longer requires a person to visit every organization and repeat an authorization flow. It also gives the GitHub App performing the operation a new form of delegated power.

The secret is not the only sensitive object

It is good that the API does not receive the token value or private SSH key. But an app with enterprise_credentials:write can expand where an existing credential works. That authorization is valuable even without knowledge of the secret.

I would therefore separate the system that generates or stores credentials from the system that authorizes them. The latter should receive only the identifier, intended organizations, owner, expiration, and change request. Its installation and private key deserve the same controls as other enterprise identity automation.

Bulk authorization needs bulk revocation

A service account should have a declared organization set, not “whatever accepted the last run.” Reconciliation should compare desired and actual authorization, remove organizations that are no longer in scope, and record every change.

Rotation is a transaction: create the replacement, authorize it, verify the real client path, switch consumers, and revoke the old credential. A successful API response at step two is not proof that a deployment host loaded the new key.

Authorization does not create membership

GitHub says the API checks that the target organizations belong to the enterprise, the credential owner belongs to each organization, and enterprise-level SSO is in use. Existing active authorizations are skipped. The limit is 50 organizations per request, not a new grant of membership or unrestricted repository access.

That distinction changes the rotation checklist. Before calling the API, establish the credential’s owner and intended organization set. A rejected organization may indicate an identity or membership problem; retrying the same request will not repair the intended access model.

Verify the consumer before revoking the old credential

I would record rotation as separate steps rather than marking the job complete when authorization succeeds:

1. Inventory the consumers of the old credential: runner secrets, service configuration, scheduled jobs and any manually provisioned host. Record identifiers and owners, not secret values.
2. Create the replacement using the approved credential-management process and authorize its intended organization set.
3. Check the result for each intended organization. Resolve failures before switching the consumers that depend on those organizations.
4. Install the replacement through the normal secret-delivery path. Verify a harmless read from each consumer’s actual runtime, using a repository it is supposed to access.
5. Revoke the old credential once the required consumers are verified, then confirm they continue to work. If it is suspected compromised, follow the incident process instead of preserving it for convenience.

A passing test from the administrator’s laptop leaves the deployment host untested. Likewise, updating a stored secret does not prove that a long-running service reloaded it. The cutover record needs the consumer and the observed result, not just the API request identifier.

Keep a defined recovery action for an unsuccessful cutover. That may mean correcting secret delivery or issuing another replacement; it should not depend on being able to resurrect a revoked credential.

Classic credentials remain the compatibility path

The feature specifically helps classic PATs and SSH keys. Where a GitHub App or fine-grained token can provide narrower repository access and shorter-lived credentials, I would still prefer that design. Some automation, tooling, and multi-organization workflows do not fit it yet; those are the cases where centralized authorization is valuable.

Enterprises must opt in. Before enabling it, I would require an owner, a maximum organization count, an expiration policy, and alerts for authorization changes. Convenience is the point, but convenience should not quietly turn one old token into an enterprise-wide credential.

Source

GitHub: automate SSO authorization for classic PATs and SSH keys.