You lose sight of the effective repository entitlement. Outside collaborators, inherited team permissions, personal access tokens, and workflow rights can still grant real access even when directory records look clean, so certification becomes incomplete and stale access survives longer than the review cycle. Teams need repository evidence, not just IdP membership, to validate access.
Why stopping at the identity provider leaves access reviews incomplete
An identity-provider review tells you who exists in the directory, not what they can actually do inside GitHub. The gap matters because GitHub access is often assembled from multiple layers, including direct repository membership, inherited team access, outside collaborators, token-based access, and workflow permissions. If the review stops at IdP membership, it can miss effective entitlement.
That distinction is operational, not semantic. A clean directory record can coexist with active repository access if access was granted through a team, a shared integration, or a credential that was never tied back to the directory state. In practice, the review must answer, “Can this principal still reach the repository or execute workflows?” not just “Is this person still in the right group?”
This is why repository evidence is the right unit of review. GitHub permission state, team inheritance, and token-bearing access paths are the controls that determine whether access actually exists at review time. A directory-only certification can look complete while still leaving stale entitlements in place.
Where effective repository entitlement hides
Several access paths can survive even when IdP records look correct. Outside collaborators may remain on a repository after their directory membership changes, inherited team permissions can continue to grant access through nested group structure, and personal access tokens or workflow permissions may persist beyond the original approval window. The review has to surface those active rights directly.
The core failure mode is inheritance plus indirection. Directory membership may change, but the repository can still derive access from a team, app, or automation path that is not visible in a basic identity export. That is why GitHub review evidence should include repository-level membership, team-to-repo mappings, and any token or workflow grants that confer real actionability.
When the access model includes automation, the same logic applies to non-interactive rights. A repository may appear clean from a human-identity standpoint while still exposing write paths, workflow dispatch rights, or token-scoped access that can modify code, secrets, or release pipelines. The review scope has to follow the entitlement path, not the directory label.
What good access review evidence looks like in GitHub
A useful review package ties each principal to the exact repository entitlement being certified. That means listing the repository, the access path, the effective role, and the reason the access exists. It should let a reviewer see whether access is direct, inherited, or token-mediated, and whether the entitlement is still needed for current work.
For repository governance, the useful question is not only whether someone should belong to a team, but whether the team membership still translates into the right repository access. GitHub teams, outside collaborators, and workflow permissions should be reviewed as a single access story so that stale access cannot hide behind a clean IdP snapshot.
NHIMG’s Access Reviews and Certification Guide is the right starting point when you want reviews to remove access rather than rubber-stamp membership. For lifecycle context, NHI Lifecycle Management Guide helps frame why access visibility, rotation, and offboarding must stay linked to actual entitlements.
Reviewers should also check whether repository access has become a standing exception. If the same person keeps reappearing with access through different paths, the issue is no longer a one-off review miss, it is an access governance problem that needs ownership and cleanup at the source.
Risk and Threat Considerations
Stopping at the identity provider creates a blind spot that attackers and insiders can exploit. If effective repository access is still granted through inherited teams, outside collaborator status, or long-lived tokens, stale access can survive after an employee leaves, a contractor rolls off, or an account is remediated in the directory.
Failure mechanism: The review certifies directory state instead of actual repository entitlement, so access that is granted through inheritance, tokens, or workflow permissions remains undiscovered and unrevoked.
Impact: Unneeded write access, code visibility, or workflow control can persist past the review cycle, increasing the chance of unauthorized changes, secret exposure, and delayed detection of compromise.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
CSA Cloud Controls Matrix, NIST SP 800-53 Rev 5 and CIS Controls v8 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CSA Cloud Controls Matrix | IAM — Identity and Access Management | GitHub entitlement review depends on effective access governance across identities and repository rights. |
| Recommendation — Review repository entitlements directly and reconcile inherited and token-based access before certifying IAM state. | ||
| NIST SP 800-53 Rev 5 | AC-2 — Account Management | Access review must validate active repository accounts, collaborators, and access paths, not just directory membership. |
| AC-6 — Least Privilege | Repository permissions can exceed what the IdP shows, so least privilege must be checked at the GitHub entitlement layer. | |
| Recommendation — Verify that active repository accounts and related access paths are reviewed and removed when no longer needed. Limit GitHub repository access to the minimum effective privileges required for current work. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | The question is about whether access control reviews reflect actual repository entitlement. |
| Recommendation — Base access reviews on the repository control state, not only on directory membership. | ||
| CIS Controls v8 | CIS-5 — Account Management | The issue is stale access surviving because account and entitlement evidence is not reviewed end to end. |
| Recommendation — Maintain a complete account-to-resource entitlement inventory and remove stale repository access promptly. | ||
Practitioner Guidance
What to verify: Reconcile directory records against repository-level evidence, including direct collaborators, team inheritance, outside collaborators, tokens, and workflow permissions. If the reviewer cannot explain the access path from identity to repository, the certification is incomplete.
Decision rule: If a principal still has repository reach even after IdP membership is removed or changed, treat the repository entitlement as the source of truth for remediation and review the directory record only as supporting evidence.
Practitioner takeaway: The right access review target is the effective permission set, because that is what governs real repository exposure, not the directory view that happens to be easiest to export.