GitHub has added a consolidated credential inventory for Enterprise Cloud, giving enterprise security teams a new way to see the keys, tokens and application credentials associated with their environment.
The capability, announced on 21 September 2026, is designed to answer a deceptively difficult incident-response question: which credentials could be used to access this enterprise, who owns them and where are they authorised?
Enterprise owners can query the inventory through GitHub's REST API or create a CSV export for offline investigation. The inventory covers multiple credential types rather than forcing administrators to assemble the picture from separate areas of the platform.
Key takeaways
- GitHub Enterprise Cloud now provides a consolidated enterprise credential inventory.
- The inventory covers SSH keys, classic and fine-grained personal access tokens, OAuth App user tokens, GitHub App user credentials and installations, and federated credentials documented by GitHub.
- Administrators can filter results by credential type, owner, organisation, application and authorisation state.
- Enterprise owners can start an asynchronous CSV export or work directly with the paginated REST API.
- The feature is especially useful for credential reviews and incident response, but it does not replace credential rotation, least-privilege policies or broader audit-log monitoring.
What GitHub's credential inventory changes
Credential sprawl is a common problem in large development organisations. A single enterprise may have developers using SSH keys, automation relying on personal access tokens, integrations using OAuth credentials and applications operating through GitHub App installations.
When a security incident occurs, administrators need to establish which credentials exist and which of them have effective access. GitHub's new inventory provides that information through a common interface.
GitHub says the list endpoint includes credentials currently authorised to access the enterprise as well as credentials owned by enterprise members that do not currently have enterprise authorisation. That distinction can help investigators separate credentials with present access from member-owned credentials that are not currently authorised.
Which credentials are included?
GitHub's Enterprise Cloud documentation lists personal access tokens, including classic and fine-grained PATs; OAuth App and GitHub App user tokens; SSH keys; GitHub App installations; and federated credentials among the credential types assembled into the inventory.
Individual records can expose useful investigation metadata such as the credential type, owner, state, authorisation state, creation time, last-used time and expiration information where available. Depending on the credential type, records can also include scopes, permissions, repository selection and authorised organisations.
Filters can narrow a large investigation
The API supports filters that can make a large enterprise inventory more manageable. Administrators can narrow results by credential type, owner, organisation, application or authorisation state.
For example, an incident responder investigating a compromised developer account could filter the inventory to credentials owned by that user. A team examining a suspicious integration could instead filter by application. Organisations can also distinguish credentials that are currently authorised from credentials merely owned by enterprise members.
CSV exports provide an offline investigation path
GitHub also provides an endpoint for creating an enterprise token-inventory export. The export is generated asynchronously: the request returns an export identifier that can be polled until the CSV is ready.
According to GitHub's documentation, the generated CSV uses UTF-8 and includes credential and authorisation information suitable for analysis in security tooling or a spreadsheet. The export can use the same kinds of filters available to the inventory, allowing teams to create a more focused dataset rather than exporting everything for every investigation.
GitHub notes that the export endpoint is limited to a small number of exports per enterprise per day, so organisations should not design high-frequency automation around repeated full CSV generation.
Who can access the inventory?
This is an administrative security capability rather than a general developer feature. GitHub's documentation says the REST endpoints require an enterprise owner or a role with the View enterprise credentials permission.
Authentication requirements also vary with the token used to call the endpoint. GitHub documents read:enterprise requirements for OAuth app tokens and classic personal access tokens, while supported fine-grained GitHub App tokens require read access to the Enterprise credentials permission.
Those restrictions matter because an enterprise-wide credential inventory is itself sensitive security information. Organisations should therefore apply least privilege to access to the inventory and protect exported CSV files as security-sensitive data.
How this helps during a security incident
Suppose a developer workstation is suspected of compromise. The response team may need to determine whether the user's SSH key remains active, whether the user owns personal access tokens, whether those credentials are authorised to sensitive organisations and when they were last used.
The credential inventory gives responders a central starting point for that investigation. The results can then be correlated with GitHub audit data and other security telemetry to understand activity and decide which credentials require revocation or rotation.
The same workflow can help after an application credential is exposed. Filtering by application can identify relevant credentials and authorisations, while metadata such as last use and expiration can help investigators prioritise their review.
What the inventory does not do
A credential inventory improves visibility, but visibility is not the same as remediation. Security teams still need processes for revoking compromised credentials, rotating secrets, reducing unnecessary permissions and investigating suspicious activity.
Nor should the inventory be treated as proof that a credential has been compromised. A credential appearing in the inventory simply means it meets the inventory criteria documented by GitHub. Investigators need audit events and other evidence before drawing conclusions about misuse.
Teams should also be careful with exports. CSV files can contain detailed security metadata, so copies should be access-controlled, retained only as long as necessary and handled under the organisation's incident-response and data-retention policies.
Practical steps for enterprise security teams
- Confirm access. Decide which enterprise owners or security roles genuinely need permission to view enterprise credentials.
- Baseline the inventory. Review credential types, owners, authorisation states and expiration information to identify unexpected or long-lived access.
- Use filters during incidents. Narrow investigations by owner, organisation or application instead of manually checking unrelated credentials.
- Correlate with audit evidence. Use credential metadata alongside GitHub audit logs and your organisation's identity and endpoint telemetry.
- Remediate separately. Revoke or rotate credentials when the investigation justifies it, and reduce permissions that are broader than necessary.
- Protect exports. Treat downloaded inventories as sensitive security artefacts.
Why the update matters
Large software organisations rarely have just one kind of GitHub credential. The practical value of this update is therefore consolidation: security teams gain one inventory model spanning several credential families, with filters and export options that can shorten the discovery phase of an investigation.
For GitHub Enterprise Cloud customers, the feature is available through the enterprise credential inventory REST endpoints and export workflow documented by GitHub. Administrators should review GitHub's current documentation before automating around the API because permissions, supported credential types and API versions can evolve.
