Summary and recommendation
GitHub user management can be run manually, but complexity usually increases with role models, licensing gates, and offboarding dependencies. This guide gives the exact mechanics and where automation has the biggest impact.
GitHub's permission model is layered: enterprise roles sit above org roles, which sit above team roles, which sit above repository roles. Teams are the primary mechanism for granting repository access at scale. Custom repository roles (30+ toggleable permissions) are available on GitHub Team and Enterprise Cloud plans.
For every app in your stack, the access boundary is only as clean as the role structure beneath it. In GitHub, that means understanding that Enterprise Owners are not automatically org members, Outside Collaborators on private repos consume billable seats, and Team Maintainer is a sub-role that requires existing org membership.
Quick facts
| Admin console path | Organization: Settings → Members / People. Enterprise: Enterprise account → People → Members or Administrators. |
| Admin console URL | Official docs |
| SCIM available | Yes |
| SCIM tier required | Enterprise Cloud (EMU) |
| SSO prerequisite | Yes |
User types and roles
| Role | Permissions | Cannot do | Plan required | Seat cost | Watch out for |
|---|---|---|---|---|---|
| Enterprise Owner | Full administrative control over the enterprise account: manage all organizations, billing, policies, SSO/SCIM, and enterprise administrators. | Cannot directly push code to repositories unless also added as an org/repo member. | GitHub Enterprise Cloud or Enterprise Server | Consumes a licensed seat | Enterprise owners can see all org members and repos but are not automatically org members; they must be added separately to interact with repo content. |
| Enterprise Billing Manager | View and manage billing information for the enterprise account only. | Cannot access organization settings, repositories, or member management. | GitHub Enterprise Cloud | Does not consume a licensed seat | Billing managers have no visibility into code or org membership; role is billing-only. |
| Organization Owner | Full admin over a single organization: manage members, teams, repos, billing (org-level), integrations, and org-level security settings. | Cannot manage enterprise-level policies or other organizations within the enterprise unless also an Enterprise Owner. | All plans (Free, Team, Enterprise) | Consumes a licensed seat | At least one owner must exist per organization; GitHub will not allow removal of the last owner. |
| Organization Member | Default role. Can create repos (if permitted by org policy), create teams, and be added to teams. Access to private repos is granted explicitly by team or direct assignment. | Cannot manage org settings, billing, or other members. | All plans | Consumes a licensed seat | Members can see other members' usernames and public activity within the org by default; this can be restricted via member privilege settings. |
| Outside Collaborator | Access to specific repositories only, as granted. Not a full org member. | Cannot access org-level settings, teams, or any repo not explicitly shared. Cannot use org-level SSO-protected resources without authorizing their PAT/SSH key. | All plans; on Enterprise, org owners can restrict who can invite outside collaborators | Consumes a licensed seat on paid plans (Team and Enterprise) | Outside collaborators on private repos count as billable seats. Converting an outside collaborator to a member (or vice versa) changes seat consumption immediately. |
| Team Maintainer | Can add/remove team members, change team settings, and manage team-level repo access within their team. | Cannot manage org-level settings or members outside their team. | All plans | Counted under their existing org member seat | Team maintainer is a sub-role layered on top of org membership; the user must already be an org member. |
| Repository Role: Read / Triage / Write / Maintain / Admin | Graduated repository-level permissions. Read: view/clone. Triage: manage issues/PRs without write. Write: push code. Maintain: manage repo settings (no destructive actions). Admin: full repo control including deletion. | Repository roles do not grant org-level permissions. | All plans; custom repository roles require Team or Enterprise | Counted under existing org member or outside collaborator seat | Repository Admin role allows a user to delete or transfer the repository; grant with caution. |
| Custom Repository Role | Org owners define a named role inheriting from one of the five base roles, with additional granular permissions toggled on (e.g., manage webhooks, edit repo metadata, bypass branch protection). | Cannot exceed the permissions of the base role they inherit from in terms of code access; additional permissions are additive from a curated list only. | GitHub Team or GitHub Enterprise Cloud | Counted under existing member or collaborator seat | Custom roles are org-scoped; they must be recreated in each organization. Maximum of 3 custom roles per organization on Team plan. |
Permission model
- Model type: hybrid
- Description: GitHub uses a layered permission model: enterprise-level roles (Enterprise Owner, Billing Manager) sit above organization-level roles (Owner, Member, Outside Collaborator), which sit above team-level roles (Team Maintainer, Team Member), which sit above repository-level roles (Read, Triage, Write, Maintain, Admin, and custom roles). Access to a repository is the union of all applicable role grants. Teams are the primary mechanism for granting repository access to groups of users.
- Custom roles: Yes
- Custom roles plan: GitHub Team or GitHub Enterprise Cloud
- Granularity: Repository-level granularity with ~30+ toggleable fine-grained permissions available when creating custom repository roles. Organization-level roles are fixed (Owner or Member). Enterprise-level roles are fixed (Enterprise Owner or Billing Manager). Fine-grained personal access tokens (PATs) also support per-repository, per-permission scoping.
How to add users
- Navigate to github.com/orgs/{org}/people (Organization level) or github.com/enterprises/{enterprise}/people (Enterprise level).
- Click 'Invite member' (org) or 'Invite admin' / manage membership (enterprise).
- Enter the user's GitHub username or verified email address.
- Select the role to assign (Member or Owner for org; Owner or Billing Manager for enterprise).
- Optionally select one or more teams to add the user to immediately.
- Click 'Send invitation'. The user receives an email and must accept within 7 days.
- For Enterprise Managed Users (EMU): users are provisioned exclusively via SCIM through the IdP; manual invitation is not available. Assign the user to the GitHub app in the IdP to trigger provisioning.
Required fields: GitHub username or verified email address of the invitee, Role selection (Member or Owner)
Watch out for:
- Invitations expire after 7 days; a new invitation must be sent if not accepted in time.
- The invitee must already have a GitHub account (or create one) to accept. GitHub does not create accounts on behalf of admins for standard orgs.
- On Enterprise Managed Users (EMU), all accounts are created and managed by the IdP via SCIM; org owners cannot manually invite external GitHub accounts.
- If SAML SSO is enforced, the invited user must authorize their account with SSO before accessing org resources, even after accepting the invitation.
- Pending invitations count against the org's licensed seat total on paid plans.
- Organization owners can restrict who can send invitations (e.g., only owners, not members).
- Adding a user to a private repo as an outside collaborator on a paid plan immediately consumes a seat.
| Bulk option | Availability | Notes |
|---|---|---|
| CSV import | No | Not documented |
| Domain whitelisting | No | Automatic domain-based user add |
| IdP provisioning | Yes | GitHub Enterprise Cloud with Enterprise Managed Users (EMU); SAML SSO with SCIM also available for standard Enterprise Cloud orgs via Okta or Entra ID, but only provisions org membership, not account creation |
How to remove or deactivate users
- Can delete users: No
- Delete/deactivate behavior: GitHub does not allow admins to delete another user's GitHub account. Admins can remove a user from an organization or enterprise (revoking access), or-for EMU only-suspend/deprovision the managed user account via the IdP/SCIM, which disables the account but does not delete it. The GitHub account itself (for standard users) persists and is owned by the individual. For EMU accounts, deprovisioning via SCIM suspends the managed account; the account cannot be reactivated outside the IdP.
- Standard org removal: Navigate to github.com/orgs/{org}/people → locate the member → click the gear icon or 'Remove from organization' → confirm removal.
- Enterprise removal: Navigate to github.com/enterprises/{enterprise}/people → locate the member → click the dropdown → 'Remove from enterprise' → confirm.
- EMU suspension via IdP: Unassign the user from the GitHub EMU application in Okta/Entra ID; SCIM will suspend the managed user account automatically.
- To remove an outside collaborator: Navigate to org Settings → 'Outside collaborators' → click 'Remove' next to the user.
| Data impact | Behavior |
|---|---|
| Owned records | Repositories, issues, pull requests, comments, commits, and gists created by the user remain intact and attributed to their username. Removing a user from an org does not delete their contributions. For EMU, suspended accounts retain all contribution history. |
| Shared content | The removed user loses access to all private org repositories and team discussions immediately upon removal. Public repositories they forked remain in their personal account. Private repo forks are deleted when the user is removed from the org. |
| Integrations | OAuth app authorizations and GitHub App installations granted by the user at the org level are not automatically revoked; org owners should audit and revoke separately. Personal access tokens (PATs) the user created for org resources will stop working for private resources upon removal. |
| License freed | The seat is freed immediately upon removal from the org or enterprise. Billing adjusts at the next billing cycle (for monthly billing) or is credited proportionally (varies by plan). Pending invitations that are cancelled also free the reserved seat. |
Watch out for:
- Removing a user from an org does not remove them from the enterprise; enterprise-level removal must be done separately.
- Private repository forks owned by the removed member are deleted immediately upon org removal-this is irreversible.
- If the removed user is the sole owner of a repository with no other admins, that repository may become inaccessible to the org; ensure repo ownership/admin is transferred before removal.
- For SAML SSO orgs, revoking the user's IdP access does not automatically remove them from the GitHub org; org removal must be performed manually in GitHub or via SCIM if configured.
- EMU accounts suspended via SCIM cannot log in but their username and profile remain visible in contribution history.
- Removing an org owner when they are the last owner is blocked by GitHub; another owner must be designated first.
License and seat management
| Seat type | Includes | Cost |
|---|---|---|
| GitHub Free (org) | Unlimited public repos, limited private repo features, 2,000 Actions minutes/month, 500 MB Packages storage. No per-seat cost. | $0 |
| GitHub Team | All Free features plus protected branches, required reviewers, code owners, draft PRs, 3,000 Actions minutes/month, 2 GB Packages storage, custom repository roles. | $4/user/month (billed annually) or $4.80/user/month (billed monthly) |
| GitHub Enterprise Cloud | All Team features plus SAML SSO, audit log API, SCIM (EMU), enterprise policies, 50,000 Actions minutes/month, 50 GB Packages storage, advanced security add-ons available. | $21/user/month (billed annually) |
| GitHub Enterprise Server | Self-hosted deployment with enterprise features. Licensed per active user on the instance. | $21/user/month (billed annually, via volume licensing) |
| GitHub Advanced Security (GHAS) - Code Security add-on | Code scanning (CodeQL), secret scanning, dependency review, security overview for active committers. | $30/active committer/month |
| GitHub Advanced Security - Secret Protection add-on | Secret scanning push protection, validity checks, and secret scanning alerts. | $19/active committer/month |
- Where to check usage: Enterprise account: github.com/enterprises/{enterprise}/settings/billing - shows licensed seats, seats used, and seats available. Organization level: github.com/orgs/{org}/settings/billing. Enterprise People view (github.com/enterprises/{enterprise}/people) allows filtering by role and shows all members consuming seats.
- How to identify unused seats: Navigate to github.com/enterprises/{enterprise}/people and filter by 'Dormant' to see users who have not performed any activity (commits, PR reviews, issue comments, etc.) within the past 90 days. Org-level dormant users can be viewed at github.com/orgs/{org}/people?type=none (no activity filter) or via the enterprise audit log. GitHub does not provide a built-in automated license reclamation workflow; admins must manually review and remove dormant users.
- Billing notes: Billing is per unique user across the enterprise; a user who is a member of multiple orgs within the same enterprise counts as one seat. Outside collaborators on private repos count as seats on Team and Enterprise plans. Pending (unaccepted) invitations consume a seat reservation. Seats are released immediately upon member removal but billing credit timing depends on plan type (monthly vs. annual). GitHub Enterprise Cloud requires an annual commitment with upfront or invoiced billing for most enterprise customers. The 2026 Actions pricing changes introduce a $0.002/minute cloud platform charge and reduce hosted runner per-minute rates by up to 39%.
The cost of manual management
Manual provisioning in GitHub requires sending individual invitations that expire after 7 days and must be accepted by the recipient before the user appears as an active member. There is no native CSV bulk-import for org membership; adding users at scale without IdP/SCIM means sending invitations one at a time.
Dormant user identification requires navigating to the enterprise People view and filtering by 'Dormant' (90-day inactivity threshold). GitHub provides no automated license reclamation or scheduled cleanup workflow, so seat audits are a recurring manual task.
Removing a user from an org immediately and permanently deletes their private repository forks with no recovery option. Org-level removal also does not cascade to the enterprise level; both must be handled separately.
The decision
Choose the manual path if your org is on GitHub Team or standard Enterprise Cloud, your team size is small enough to manage invitations individually, and you do not need automated account lifecycle management. The manual flow is straightforward for day-to-day role changes and team assignments.
Escalate to IdP-connected SCIM (EMU) if you need automated provisioning and deprovisioning tied to your identity provider, are on GitHub Enterprise Cloud, and can commit to Okta or Entra ID as your IdP. EMU is an enterprise-wide architectural decision, not a configuration toggle.
If your org uses an unsupported IdP (e.g., Google Workspace, OneLogin), full SCIM lifecycle management is not available regardless of plan tier.
Bottom line
GitHub's manual user management is reliable for small-to-mid-sized orgs but does not scale cleanly: no bulk import, no automated dormant-user cleanup, and a fork-deletion risk on every removal.
For every app that touches your developer identity layer, GitHub's access model demands deliberate role design upfront - particularly the distinction between org membership, team assignment, and repository-level grants.
Orgs that need automated lifecycle management must evaluate EMU carefully, as it is an irreversible migration with hard IdP constraints.
Automate GitHub workflows without one-off scripts
Stitchflow builds and maintains end-to-end IT automation across your SaaS stack, including apps without APIs. Built for exactly how your company works, with human approvals where they matter.
Every app coverage, including apps without APIs
60+ app integrations plus browser automation for apps without APIs
IT graph reconciliation across apps and your IdP
Less than a week to launch, maintained as APIs and admin consoles change
SOC 2 Type II. ~2 hours of your team's time
