Beyond the News
Sign in
Updated 22 Sep 2026: Sep 22: GitHub Enterprise Cloud adds credential inventory export/API, giving responders the discovery half of the selective-revocation workflow covered by this dossier.
Web DevelopmentCloud & InfrastructureDeployment & DevOpsDeveloper Tools Active dossier

GitHub adds credential inventory to its selective incident-response kill switches

GitHub Enterprise Cloud can now inventory every credential that can access an enterprise, then use the platform’s existing token-type controls to revoke the affected credential class with a narrower incident-response blast radius.

Reviewed and published by Lars Jansen Updated 4 min read
Comment
First published

Key details

  1. Credential inventory export was announced September 21, 2026 for GitHub Enterprise Cloud.
  2. Inventory types include SSH keys, classic and fine-grained PATs, OAuth App access tokens, and GitHub App user-to-server and installation tokens.
  3. The inventory is available as CSV and through paginated REST API endpoints.
  4. Records expose owners, permissions/scopes, creation and expiration dates, last-used dates, and target organizations or repositories.
  5. Access can be delegated with the fine-grained `View enterprise credentials` permission.
  6. GitHub’s existing selective revocation controls can target credential classes rather than every credential a user holds.
  7. GitHub Enterprise Server support for the inventory is planned for upcoming releases.

What builders should take away

  1. Export a baseline credential inventory before an incident so responders are not discovering the enterprise authentication surface under pressure.
  2. Automate periodic inventory retrieval and flag stale, unexpectedly broad or non-expiring credentials using the metadata GitHub now exposes.
  3. Correlate last-use and target metadata with audit logs before choosing a revocation scope.
  4. Update incident-response runbooks so discovery through credential inventory feeds directly into token-type-specific containment.
  5. Keep GHES runbooks separate until the credential inventory feature lands in the server release you operate.

What changed

GitHub added token-type-specific credential revocation on August 18, 2026. On September 21 it added a complementary enterprise credential inventory for GitHub Enterprise Cloud. Enterprise owners and members with the fine-grained `View enterprise credentials` permission can export or query credentials across the enterprise, including SSH keys, classic and fine-grained personal access tokens, OAuth App access tokens, and GitHub App user-to-server and installation tokens. The inventory includes owners, scopes/permissions, creation and expiration dates, last-used dates and target organizations or repositories, and can be correlated with audit-log activity. Together, the two changes let responders identify the exposed credential set before choosing a narrower revocation action.

Why it matters

Selective revocation is most useful when responders can quickly establish which credentials exist, who owns them and where they can reach. The new inventory closes that operational gap: security teams can build an enterprise-wide credential map before or during an incident, filter it by user, app, type or organization, and then use GitHub’s existing credential-class kill switches rather than defaulting to broad account disruption.

Enterprise owners can inventory the credential attack surface

GitHub Enterprise Cloud now exposes a complete credential inventory through CSV export and paginated REST API endpoints. GitHub says the inventory covers SSH keys, classic and fine-grained PATs, OAuth App access tokens, and GitHub App user-to-server and installation tokens.

The metadata is designed for incident triage

Inventory records include credential owner, scopes and permissions, creation and expiration dates, last-used dates, and target organizations or repositories. Teams can filter by user, app, credential type or organization and correlate the results with audit-log activity to identify credentials that plausibly participated in an incident.

Selective revocation remains the containment layer

GitHub’s August controls let responders revoke or deauthorize a specific credential class rather than every credential associated with a user. The September inventory makes that capability easier to use safely because teams can first determine the actual credential population and exposure.

Enterprise Server support is coming later

GitHub says the inventory is available now for GitHub Enterprise Cloud and will be supported in upcoming GitHub Enterprise Server releases. Self-hosted enterprises should not assume the new inventory API is available until their GHES release includes it.

What to watch next

  • Which GitHub Enterprise Server release first includes credential inventory exports and API access.
  • Whether GitHub adds finer-grained revocation based on inventory attributes such as age, scope, owner or target repository.
  • Whether inventory endpoints gain event-driven hooks or native policy enforcement for stale and overprivileged credentials.

Still unclear

  • GitHub does not quantify propagation time for credential revocation across all services.
  • The September announcement describes inventory visibility and metadata but not an automatic policy engine that revokes credentials based on those fields.
  • GitHub Enterprise Server support is promised for upcoming releases but the announcement does not name a specific version.

Sources

Direct reading behind this dossier.

2 sources

Discussion

Discussion is reader-contributed. Comments are not part of the BTN dossier or its editorial evidence.

0 visible comments

Join the discussion

Keep comments useful and relevant. Reader contributions may be moderated and are not BTN editorial evidence.

Sign in to comment
Continue reading
Web Development

GitHub Actions makes cache access a least-privilege workflow permission

The change turns cache poisoning from mostly a workflow-design warning into an enforceable permission boundary. Teams can let untrusted jobs restore caches without writing them, prevent reusable workflows from escalating cache access and isolate jobs that only need to publish cache entries.