Who is accountable for revoking GitHub app authorisations after compromise?

The identity or platform team should own the control, but accountability must be shared with the application owner and incident response lead. If authorisations are not revocable within the containment process, the organisation has delegated too much trust to a session that no longer has a valid business purpose.

Why This Matters for Security Teams

GitHub app authorisations are not just another access grant. They are durable trust relationships that can keep reading repositories, triggering workflows, or calling APIs long after the original compromise is contained. That makes revocation a governance issue, not only an incident task. The practical problem is that ownership is often split across identity, platform, and application teams, so no single group is prepared to cut off access quickly enough.

The risk is amplified when authorisations are treated like ordinary user sessions instead of non-human identity assets. NHIMG research shows that only 20% of organisations have formal processes for offboarding and revoking API keys, and 91.6% of secrets remain valid five days after notification. That delay is exactly how compromised integrations continue to operate. The control objective aligns with the OWASP Non-Human Identity Top 10 and NHIMG’s Ultimate Guide to NHIs – Lifecycle Processes for Managing NHIs, both of which stress that non-human access must be lifecycle-managed, not simply issued and forgotten. In practice, many security teams discover the revocation gap only after a compromised app has already continued exfiltrating data or replaying build actions.

How It Works in Practice

Accountability should be assigned before an incident occurs. The identity or platform team usually owns the revocation control because it manages the GitHub organisation, app registrations, and integration settings. The application owner remains accountable for business justification and for confirming that the app should be disabled. Incident response owns timing and containment, since revocation must happen inside the broader blast-radius reduction workflow. Current guidance suggests treating this as a shared operational duty with a single decision path, not a consensus meeting during an active compromise.

In practice, the workflow should be documented as an incident runbook with explicit triggers, approvers, and fallback actions. When compromise is suspected, responders should:

• Identify the affected GitHub App, installation, or token chain.
• Revoke the app authorisation and any related secrets or tokens.
• Invalidate downstream credentials that were minted from that trust relationship.
• Confirm whether automation, CI/CD, or release pipelines depend on the app.
• Record the owner, timestamp, and verification evidence for auditability.

This is where non-human identity governance matters. NHIMG’s NHI Lifecycle Management Guide frames revocation as a mandatory offboarding step, while NIST’s SP 800-53 Rev. 5 Security and Privacy Controls supports the need for access removal, audit logging, and incident handling. Organisations that can automate revocation through platform APIs generally recover faster than those relying on manual ticket queues. These controls tend to break down in federated GitHub Enterprise environments where multiple business units administer apps independently because no single team has complete visibility into which installations still have active reach.

Common Variations and Edge Cases

Tighter revocation control often increases operational overhead, requiring organisations to balance fast containment against application downtime and developer disruption. That tradeoff is especially visible when a GitHub App supports multiple repositories or critical release automation. In those cases, immediate revocation may stop the incident but also halt deployment pipelines, so the revocation plan should include a business continuity path and a pre-approved emergency rollback process.

Best practice is evolving for delegated app ownership. Some organisations let the platform team execute revocation unilaterally during declared incidents, while others require application owner confirmation for non-emergency changes. There is no universal standard for this yet, but the safest model gives incident response authority to act first and notify second. This avoids delay when compromise is active.

Edge cases include third-party GitHub Apps, inherited enterprise installations, and apps that authenticate through chained secrets in CI/CD. Those environments create hidden dependencies, so revocation of one authorisation may not fully contain the breach if cached tokens, workflow secrets, or service account credentials remain live. NHIMG’s Guide to the Secret Sprawl Challenge is a useful reminder that revoked access must be paired with secret cleanup. Where apps are deeply embedded in automation, the real control is not simply “who clicks revoke,” but whether the organisation can prove every dependent credential has also been retired.

Related resources from NHI Mgmt Group

• What should teams do in the first 24 to 72 hours after a connected app compromise?
• Who is accountable when a workload secret remains active after compromise?
• How should security teams recover GitHub environments after a compromise?
• Who is accountable when a SaaS app remains active after it should have been retired?