Who is accountable when GitHub access decisions are approved, modified, or revoked during a certification cycle?

Why This Matters for Security Teams

GitHub certification cycles are not a paperwork exercise. They are the formal point where access can be approved, reduced, or removed, and the question of accountability determines whether the process is auditable after the fact. Security teams often define the control, but the certification owner is the one who must be able to explain why a decision was made, who approved it, and what changed when a reviewer challenged the result. That distinction matters because access review failures frequently become exceptions, not clean revocations.

For non-human and developer-facing identities, weak accountability quickly turns into stale access and over-permissioned repos. NHI Management Group research shows that only 20% of organisations have formal processes for offboarding and revoking API keys, and 97% of NHIs carry excessive privileges. That is why accountability must be explicit, not implied. The practical risk is familiar: a reviewer signs off, a certificate owner assumes someone else handled the exception, and the access remains live long after the review closes. In practice, many security teams encounter the gap only after a permission mismatch or unauthorized repository change has already been investigated.

Current guidance from OWASP Non-Human Identity Top 10 and the Ultimate Guide to NHIs both point to the same operational need: a named owner for decisions, a separate control owner for policy, and a review trail that can survive audit and incident response.

How It Works in Practice

In a mature certification cycle, accountability is split by function but not by outcome. The certification owner is accountable for the process result, including whether reviews were completed, exceptions were recorded, and escalations were closed. Reviewers are accountable for the specific access decision they make on each account, repository, or team membership. Security and compliance usually own the policy, evidence requirements, and cadence, but they should not be the default owner of each decision unless they are explicitly acting as the certifier.

That model becomes more reliable when the workflow records who approved, modified, or revoked access, plus the justification at the time of action. A good design also distinguishes between recommendation and execution. For example, a reviewer may approve removal, while a GitHub admin or identity platform enforces the change. The accountability chain must still point back to the certification owner for closure, because the review is not complete until the access state matches the decision.

• Assign one named certification owner per review campaign, with authority to close exceptions.
• Require each reviewer to log approve, modify, or revoke decisions with a reason code.
• Separate policy ownership from decision ownership so control design does not blur accountability.
• Preserve evidence in the ticketing or identity system, not only in email or chat.
• Escalate unresolved or disputed items before the cycle closes.

This aligns with NIST SP 800-53 Rev. 5 Security and Privacy Controls, which expects clear access governance and traceable authorization decisions, and with NHI Lifecycle Management Guide, which treats revocation and ownership transfer as lifecycle events, not ad hoc cleanup. These controls tend to break down when GitHub access is managed through informal admin overrides because the decision trail disappears and no single owner can prove completion.

Common Variations and Edge Cases

Tighter certification rules often increase operational overhead, requiring organisations to balance auditability against review speed. That tradeoff becomes sharper in engineering environments where repository access changes rapidly, teams are distributed, and temporary privileges are common.

There is no universal standard for this yet, but current guidance suggests a few common patterns. When a team lead is the reviewer, they are accountable for that review decision, while the certification owner still owns cycle completion. When access is modified rather than fully approved or revoked, the reviewer should be accountable for the revised scope, not just the final checkbox. When a control exception is granted, the exception owner should be explicitly named, because “approved by the process” is not the same as “owned by the outcome.”

Edge cases often show up when access is inherited through GitHub teams, service accounts, or automated provisioning. In those cases, the reviewer may not see the full downstream effect, so the certification owner must confirm that the decision actually changed effective access. NHI Management Group’s Top 10 NHI Issues and the Guide to the Secret Sprawl Challenge both reinforce a practical point: hidden entitlements and stale credentials make ownership meaningless unless revocation is verified end to end.

Related resources from NHI Mgmt Group

• Who is accountable when workflow access reviews and source-of-truth decisions are inconsistent?
• Who is accountable when contractor access is not revoked on time?
• Who is accountable when physical access decisions do not match HR status or security policy?
• Who should be accountable for secure access decisions across systems, networks, and communications?