GitHub Enterprise Cloud now supports automated SSO authorization for existing classic personal access tokens (PATs) and verified, user-owned SSH authentication keys. Enterprise-installed GitHub Apps can authorize one of these credentials across up to 50 selected organizations in a single request, reducing the manual work involved in onboarding, credential rotation, and organization-set changes.
The feature is available for GitHub Enterprise Cloud accounts as of September 16, 2026, according to GitHub’s announcement. The supplied documentation does not establish availability for GitHub Enterprise Server or other GitHub products.
What changed
Previously, administrators and credential owners needed to manage SSO authorization across organizations through individual workflows. The new enterprise API flow allows an appropriately configured GitHub App to authorize an existing classic PAT or SSH key for multiple organizations at once.
The operation is exposed through:
POST https://api.github.com/enterprises/ENTERPRISE/credential-authorizationsThe request uses three documented fields:
credential_id, containing the classic PAT token ID or the SSH key’s SHA-256 fingerprint;credential_type, set toclassic_patorssh_key; andorganizations, containing the target organization slugs.
Each request can include no more than 50 selected organizations. Active authorizations are skipped, which supports repeatable automation without requiring a separate check before every request.
The API uses credential identifiers rather than credential secrets. A PAT or SSH private key is not passed to the GitHub App. This distinction is important for automation design: the application needs access to the supported identifier, but the authorization request does not transmit the underlying secret.
Requirements for the GitHub App flow
This is an enterprise-level administrative capability, not a general-purpose authorization endpoint for any GitHub token. The enterprise must use enterprise-level SSO, and the owner of the credential must belong to every organization included in the request.
The GitHub App must meet all of the following requirements:
- It must be owned by the enterprise or by an organization within the enterprise.
- It must be installed on the enterprise.
- It must have write access to the Enterprise credentials permission.
- An administrator must enable Allow GitHub Apps to authorize credentials in the enterprise’s authentication security settings.
- API requests must use an enterprise installation access token.
The required token type is a significant implementation detail. Organization installation tokens, user access tokens, and personal access tokens are not supported for this flow. The GitHub App authorization guide states that an enterprise installation access token inherits the enterprise permissions granted to the app, cannot be scoped down, and expires after one hour.
Administrators should therefore review the app’s enterprise permissions carefully and account for token renewal in any automation that runs longer than the token lifetime.
Request headers and identifiers
The documented example uses GitHub’s JSON media type and API version 2026-03-10:
Accept: application/vnd.github+json
X-GitHub-Api-Version: 2026-03-10
Authorization: Bearer ENTERPRISE_INSTALLATION_TOKENA classic PAT uses its token ID as credential_id. An SSH authorization uses the key’s SHA-256 fingerprint. The operation is limited to classic PATs and verified, user-owned SSH authentication keys; the supplied documentation does not identify fine-grained PATs, OAuth tokens, GitHub App user tokens, or other credential categories as supported by this bulk authorization operation.
Administrators should also distinguish between identifiers used when creating an authorization and identifiers returned when inspecting an organization’s existing authorizations. For an existing classic PAT authorization, the organization authorization listing uses authorized_credential_id; for an SSH key, it uses the fingerprint. The documentation cautions that these lookup values should not be substituted for the request’s credential_id without understanding the context.
Why this matters for enterprise workflows
The main benefit is reduced administrative friction for credentials used across multiple SSO-protected organizations. A platform team managing a service account or other automation credential can use a repeatable enterprise workflow rather than handling each organization separately.
The 50-organization limit means larger enterprise environments will need to divide organization sets into multiple requests. Because already active authorizations are skipped, the same workflow can be rerun as organization membership or target sets change. The feature can also support credential rotation scenarios where a replacement classic PAT or verified SSH key needs authorization across several organizations.
However, the API’s documented behavior does not answer every operational question. The supplied sources do not document rate limits, retry guidance, response codes, response schemas, detailed error behavior, propagation timing, or whether the operation is synchronous or asynchronous. Teams should validate those details in their own Enterprise Cloud environment before treating the workflow as production-ready automation.
Security and administrative considerations
The flow avoids sending PAT or SSH key secrets to the GitHub App and restricts authorization to organizations in the enterprise where the credential owner has membership. Those properties reduce the amount of sensitive credential material handled by the automation, but the feature should not be presented as a general security mitigation.
The enterprise installation token deserves particular attention because it inherits the app’s enterprise permissions and cannot be scoped down. Grant only the required Enterprise credentials access, review ownership and installation boundaries, and protect the short-lived token used by the automation.
Disabling Allow GitHub Apps to authorize credentials prevents apps from creating new credential authorizations. It does not revoke authorizations that already exist. Existing authorizations remain active until they are revoked, the credential is revoked or deleted, or the credential owner loses membership in the organization.
The supplied credential documentation describes audit logging for some user- and administrator-initiated de-authorization and revocation actions, but it does not establish audit-log behavior specifically for successful or failed bulk authorization requests.
What you should do
- Confirm that the organization operates in GitHub Enterprise Cloud with enterprise-level SSO.
- Create or select a GitHub App owned by the enterprise or an organization within it.
- Grant the app write access to the Enterprise credentials permission and install it on the enterprise.
- Have an authorized administrator enable Allow GitHub Apps to authorize credentials under the enterprise’s authentication security settings.
- Generate an enterprise installation access token for the app. Do not substitute an organization installation token, user token, or personal access token.
- Collect the supported non-secret identifier: the classic PAT token ID or the verified, user-owned SSH key’s SHA-256 fingerprint.
- Verify that the credential owner belongs to every target organization.
- Send requests containing no more than 50 organization slugs, using
classic_patorssh_keyas the credential type. - Test response handling, retries, rate-limit behavior, and authorization propagation before relying on the workflow for time-sensitive deployments or onboarding.
Availability and limits
GitHub announced the capability as available for GitHub Enterprise Cloud on September 16, 2026. The supplied sources do not independently establish availability for GitHub Enterprise Server, additional product plans, or other GitHub offerings.
The feature supports classic PATs and verified, user-owned SSH authentication keys only. It allows up to 50 organizations per request, requires an enterprise installation access token, and skips authorizations that are already active. Other operational details, including rate limits and response behavior, remain undocumented in the supplied material.
