IAM loses sight of the identities that actually create production access. Orphaned tokens, service accounts, and shadow admins can persist in repositories even when the central directory looks clean, so governance must extend to code platforms to avoid a false sense of control.
When GitHub identities sit outside IAM, what stops working?
The first failure is not just admin inconvenience, it is control-plane blindness. If GitHub users, bots, tokens, and service accounts are governed only inside the platform, IAM can no longer answer a basic question: who can create, modify, or ship production code right now. That gap turns repository access into an ungoverned pathway into production systems.
Why repository identities become a governance gap, not just an access gap
GitHub is often where credentials and permissions become operational. A developer may leave, a bot may remain active, or a token may still authenticate long after the central directory has been cleaned up. When those identities are not part of the iam programme, access reviews, joiner-mover-leaver controls, and ownership records stop at the directory boundary instead of following the actual path to production change.
That is why repository identity must be treated as part of the broader identity lifecycle. The control problem is not only “can someone log in”, it is “can an identity still act in a way that changes code, workflows, releases, or deploy pipelines after the business believes it has been removed”.
What breaks in practice when GitHub identities are excluded
Three things usually fail together: visibility, recertification, and revocation. IAM teams lose inventory of non-human actors, security teams miss shadow administrators and stale tokens, and repository owners inherit access decisions without a governance model. The result is a false clean bill of health, because the directory looks compliant while the actual production path still contains active credentials and delegated access.
Cross-platform governance also weakens. If GitHub is not in scope, secrets tied to repos, workflows, and automations can outlive their owners, and access inheritance through teams, apps, or linked integrations may never be reviewed. In large engineering environments, that creates a second identity plane that behaves like IAM but is never measured like IAM.
Risk and Threat Considerations
When GitHub identities are outside the IAM programme, the main risk is persistent, under-reviewed access to source code and delivery systems. That creates a control gap where orphaned tokens, overprivileged bots, or hidden admins can continue to make production-impacting changes even after central identity records appear clean.
Failure mechanism: Identity lifecycle events do not reach the code platform, so offboarding, access review, and privilege reduction fail to remove the real actor that can still authenticate or act in GitHub.
Impact: Attackers, ex-employees, or unauthorised automation can preserve access to repositories, workflows, and deployment paths, increasing the chance of code tampering, secret exposure, or release compromise.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
CIS Controls v8 and NIST SP 800-53 Rev 5 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | CIS-5 — Account Management | GitHub identities and tokens require account inventory and offboarding control. |
| Recommendation — Inventory GitHub identities and revoke stale access as part of account management. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | GitHub tokens and secrets are authenticators that need lifecycle control. |
| AC-2 — Account Management | Repository users, bots, and admins must be governed as accounts with owners and reviews. | |
| AC-6 — Least Privilege | Shadow admins and overprivileged repo roles are a least-privilege failure. | |
| Recommendation — Manage GitHub tokens and secrets with defined issuance, rotation, and revocation rules. Include GitHub accounts in account lifecycle tracking, review, and removal workflows. Restrict GitHub roles and app permissions to the minimum required access. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | GitHub access is part of organisational access control across platforms. |
| Recommendation — Extend access control policy to code-hosting platforms and privileged integrations. | ||
Practitioner Guidance
What to prioritise: Bring GitHub users, service accounts, apps, tokens, and privileged repo roles into the same ownership model as the rest of IAM. If a GitHub identity can change production code or pipeline behaviour, it needs an explicit owner, review cadence, and revocation path.
What to verify: Check that offboarding removes GitHub access within the same operational window as directory deprovisioning, and that dormant tokens, app grants, and repo admins are visible in the access review process. A clean directory without a clean code platform is not a clean identity estate.
Practitioner takeaway: The decisive question is not whether GitHub has local controls, but whether IAM can still answer who has production-changing authority end to end.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 7, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org