GitHub Enterprise Cloud now gives enterprise owners a single inventory of credentials that can access the enterprise. The export covers personal access tokens, SSH keys, OAuth App tokens, GitHub App tokens, installations, and other supported credential types. GitHub’s announcement positions it as a tool for incident response, risk review, and compliance work. GitHub also documents the workflow in Reviewing credentials in your enterprise.
The useful change is not another token settings page. It is an enterprise-wide view. Security teams can now answer basic questions without asking every organization and repository owner to produce a separate spreadsheet: which credentials exist, who owns them, what they can access, when they expire, and when they were last used.
What the inventory contains
The inventory is broader than a list of personal access tokens. It can include classic and fine-grained PATs, SSH keys, OAuth App user tokens, GitHub App user-to-server tokens, GitHub App installation tokens, and federated credentials. The export includes metadata such as the owner, credential type, scopes or permissions, creation and expiration dates, last-used dates, and target organizations or repositories.
One detail matters when you analyze the CSV: a credential can appear once for each authorizing organization. Do not count rows as credentials without grouping by credential type and its identifier. SSH keys use a fingerprint, while some app and federated credentials do not have the same kind of per-row identifier.
Start in the GitHub UI
For a one-off review, open your enterprise settings and go to Authentication security, then Credentials. In the Overview section, choose Export CSV. Access is limited to enterprise owners and members with the fine-grained View enterprise credentials permission.
Treat the CSV as sensitive security data. It contains ownership, access, and usage metadata even though it does not contain the secret value of a token. Store it in an approved location, restrict access, and set a retention period. Do not attach it to a ticket or send it through ordinary email unless your incident process explicitly allows that.
Automate it with the REST API
For recurring reviews, use the credential inventory REST API. Creating an export is asynchronous: the API returns an export ID, then you poll that ID until GitHub provides the CSV download. The API supports filters such as owner, organization, and application, which is useful when an incident is limited to one account or integration.
# Start an enterprise-wide CSV export
curl -L -X POST \
-H "Accept: application/vnd.github+json" \
-H "Authorization: Bearer $ENTERPRISE_ADMIN_TOKEN" \
-H "X-GitHub-Api-Version: 2026-03-10" \
https://api.github.com/enterprises/ENTERPRISE/credentials/exports
# Poll the export using the returned export_id
curl -L \
-H "Accept: application/vnd.github+json" \
-H "Authorization: Bearer $ENTERPRISE_ADMIN_TOKEN" \
-H "X-GitHub-Api-Version: 2026-03-10" \
https://api.github.com/enterprises/ENTERPRISE/credentials/exports/EXPORT_IDUse an environment variable or your secret manager for the authorization token. Never replace it with a literal token in a script, shell history, CI log, or issue. The API documentation notes that the export endpoint is paginated for inventory reads, and export creation is rate-limited, so schedule collection rather than starting exports continuously.
How to prioritize cleanup
A large inventory is not automatically a problem. Start with the credentials that combine broad access with weak lifecycle signals:
• credentials that never expire;
• credentials with write or administrative permissions;
• credentials last used by a departed member or unknown application;
• credentials authorized across many organizations;
• credentials with no recent use but an important target;
• credentials created for a migration, incident, or temporary integration that has ended.
Do not revoke everything with an old last-used date without checking ownership and purpose. A dormant break-glass credential may be intentionally unused but still documented and protected. The inventory is a way to find decisions that need an owner, not a license to perform blind bulk revocation.
A repeatable review process
1. Export the inventory on a regular schedule and keep the raw file access-controlled.
2. Normalize credentials by type and stable identifier before counting or comparing runs.
3. Join the inventory with your identity source and enterprise audit log.
4. Assign each high-risk credential an owner, purpose, target, and expiration plan.
5. Revoke or narrow credentials only after confirming the replacement path.
6. Record the decision and keep the next review date with the credential owner.
Use it during an incident
When a token or app is suspected of compromise, export the inventory before changing access if your incident commander approves that order. Preserve the time and scope of the export, identify every credential owned by the affected user or app, and compare the credentials against audit activity. Then revoke or rotate the affected credentials, validate replacement automation, and communicate the impact to the organizations that were authorized.
GitHub says the capability is available now for GitHub Enterprise Cloud and will be supported in upcoming GitHub Enterprise Server releases. Keep the process portable, but check the availability and permission model for the server version you operate.
The short version
Credential inventory is most valuable before an incident. Export it, protect it, group credentials correctly, and use last-used dates and permissions to prioritize human review. A token you cannot see is difficult to rotate; a token with an owner and a documented purpose is much easier to manage.