The exact steps to remove a departing employee from GitHub — org membership, teams, deploy keys, and PATs. What org removal covers, what it misses, and how to automate it.
Key takeaways
- Removing an ex-employee from a GitHub organization revokes access to all private org repos and teams — but it does not automatically revoke Personal Access Tokens, deploy keys, or outside-collaborator access on individual repos.
- There are seven steps to full removal: org member removal → team verification → outside collaborator check → deploy key audit → PAT revocation → GitHub Apps review → IdP/SAML deprovision (if applicable).
- Steps 4 and 5 — deploy keys and PATs — are the ones most teams skip. They're also the ones that leave repo access open for weeks after the offboarding is otherwise "done."
- If your org enforces SAML SSO through Okta or Microsoft Entra, revoking at the IdP level is the fastest path to full revocation.
- Tools like KINT can run this entire sequence automatically when an HR system fires a termination event.
Removing an ex-employee from GitHub takes seven steps. The first — removing them from the organization — handles the most obvious surface: private repo access and team memberships. The other six close the gaps that persist after that: outside collaborator entries, deploy keys on CI/CD repos, Personal Access Tokens that don't expire on their own, GitHub App authorizations, and (if you use SAML SSO) the identity provider session that everything else depends on.
This guide covers each step in the order a GitHub org owner should work through them, what each step actually removes, and where access quietly stays open if you stop early. For the broader offboarding picture across other SaaS apps — Slack, Jira, Zoom, Salesforce — see the guide to revoking SaaS access for an ex-employee and the full offboarding playbook across every app.
Why GitHub offboarding gets missed
Most offboarding checklists say "remove from GitHub" as a single checkbox. It isn't. An employee removed from the org can still have an active deploy key on a repo they set up for a CI/CD pipeline, or a fine-grained Personal Access Token scoped to a specific service. Both remain valid after org removal — indefinitely, until someone audits and revokes them.
Industry research puts the median time between an employee's last day and full SaaS access revocation at 11 days. GitHub is one of the tools that tends to stay open longest, because it requires owner-level access to audit thoroughly and no HR system triggers the cleanup automatically — unless you've wired one in.
How to remove an ex-employee from GitHub: 7 steps
Step 1: Remove them from your GitHub Organization
Sign in to GitHub as an organization Owner. Go to your organization page, then Settings → Access → Members. Find the employee's account. Open the ⋯ menu next to their name and select Remove from organization. Confirm the prompt.
What this removes:
- Access to all private repos in the organization — immediately
- Membership in all teams within the org
- Private forks they created from private org repos (GitHub deletes these when org membership ends)
What this does not remove: PATs, deploy keys, outside collaborator access, or GitHub App authorizations. Those are Steps 3–6.
Step 2: Verify team membership is cleared
Org removal clears most team memberships automatically. On large orgs with nested teams, a parent-team removal can miss child team assignments. Go to Settings → Teams and check each team the employee was a member of. Confirm they no longer appear.
This takes two minutes and catches the edge case before it becomes a support ticket.
Step 3: Revoke Outside Collaborator access
Outside collaborators are GitHub accounts granted access to specific repos without full org membership. If the employee was added as a collaborator on any repo — even one outside the main org — that access persists after their org removal.
Check in two places:
- Org Settings → Member privileges → Outside collaborators — remove if they appear
- Each repo they worked on: Repo Settings → Collaborators and teams — remove individually
Outside collaborator access is the gap that often remains open on repos that were set up before the main offboarding workflow existed.
Step 4: Remove Deploy Keys
Deploy keys are SSH keys tied to a specific repository, used for read or read/write access in CI/CD pipelines. If the employee created one, it persists after they leave the org — it is not tied to org membership.
For every repo the employee had admin access to: Repo Settings → Security → Deploy keys. Delete any keys associated with them.
On orgs with dozens of active repos, this is the most time-consuming manual step. Prioritize repos that have write-access deploy keys, since those carry higher risk than read-only ones.
Step 5: Audit and revoke Personal Access Tokens (PATs)
GitHub PATs — both classic tokens and fine-grained tokens — don't expire when a user leaves an org. As an org owner, you can audit and revoke them.
For fine-grained PATs (if your org requires approval): Go to org Settings → Personal access tokens. You'll see every active fine-grained PAT with access to your org. Revoke them.
For classic PATs: Go to Settings → Security → Personal access tokens → Active tokens. Revoke any token associated with the departing employee's account.
If your org enforces SAML SSO, revocation at the IdP level (Step 7) effectively neutralizes PATs for org access even before you complete this audit — because every org request will require a valid SAML session that no longer exists.
Step 6: Check GitHub Apps they authorized
GitHub Apps installed on your org may have been authorized by the departing employee. Go to org Settings → GitHub Apps and review installed and authorized apps. Revoke or transfer authorization for any app they set up that should not persist under their name.
This is a quick check — most orgs have fewer than five apps — but it's worth running before closing the offboarding ticket.
Step 7: Deprovision at the IdP level (if using SAML SSO or GitHub Enterprise)
If your org enforces SAML single sign-on through Okta, Microsoft Entra, or another identity provider, revoking the employee's SSO session at the IdP level is the fastest and most complete action available. Once the IdP session is revoked:
- Any active GitHub session ends immediately
- PATs that depend on SAML authentication for org access stop working
- Re-authentication requires a valid SAML session — which no longer exists
On GitHub Enterprise, you can suspend the user account from the enterprise admin panel (Enterprise Settings → People). Suspension blocks all access across every org in the enterprise without deleting the account.
If your HR system triggers SCIM deprovisioning via an IdP or a dedicated tool, this entire sequence — org removal, team removal, PAT revocation — can run automatically on the employee's last day.
What GitHub org removal covers — and what it doesn't
| Action | Covered by org removal alone? |
|---|---|
| Private repo access (org repos) | ✅ Removed immediately |
| Team memberships | ✅ Cleared on removal |
| Private forks of org repos | ✅ Deleted by GitHub |
| Outside Collaborator access on specific repos | ❌ Manual — Step 3 |
| Deploy keys (per repo) | ❌ Manual — Step 4 |
| Personal Access Tokens | ❌ Manual — Step 5 |
| GitHub App authorizations | ❌ Partial — Step 6 |
| SAML SSO / Enterprise session | ❌ Revoke at IdP — Step 7 |
Org removal handles the main surface. Steps 3–7 close the perimeter.
How KINT handles GitHub deprovisioning automatically
KINT (by Kingsley Integrators) is an HR-driven identity lifecycle automation platform for companies with 100–500 employees. It automates onboarding, role changes, and offboarding across SaaS apps — including the apps without APIs, via browser automation — and produces SOC 2 CC6 audit evidence as a byproduct. Pricing is published per employee per month ($3 Starter, $5 Growth). Self-serve signup at kingsleyint.com.
Seven manual steps across five GitHub settings screens is manageable once. It gets missed on the second termination that week, and the third. The 11-day median offboarding lag is not laziness — it is a process that depends on one IT operator remembering every step under time pressure, with no automated trigger.
GitHub is a live target connector in KINT. When an HR event fires — a termination record in BambooHR, Workday, Keka, Greythr, or any of the other connected HR sources — KINT's offboarding workflow triggers automatically: org removal, team removal, and token revocation in the same run, logged with Ed25519-signed audit evidence mapped to SOC 2 CC6.1. The full offboarding across every connected app runs in approximately 47 seconds end-to-end.
KINT currently connects to 50+ live API and SCIM connectors, with 200+ apps mapped in the catalogue. GitHub is live today.
→ See how KINT handles instant offboarding → Full guide: offboarding an employee across every SaaS app in 2026
FAQ
Can an ex-employee still access GitHub repos after being removed from the organization?
After org removal, they lose access to all private repos in that organization immediately. However, two gaps remain: (1) if they have a valid Personal Access Token scoped to your org that hasn't been revoked, it can still function on surfaces where it was authorized; (2) if they were added as an outside collaborator to repos sitting outside the org, that access persists. Step 5 (PAT audit) and Step 3 (outside collaborator check) close both gaps.
Does removing someone from a GitHub org delete their account?
No. Org removal removes access to that org's private repos and teams — it does not delete the personal GitHub account, public repos, or contribution history. On GitHub Enterprise, you can additionally suspend the user account from the enterprise admin panel, which blocks all access across every org in that enterprise without deleting the account.
How do I revoke a GitHub Personal Access Token as an org owner?
Go to org Settings → Personal access tokens. For fine-grained PATs (if your org requires approval), you'll see all active tokens and can revoke individually. For classic PATs, go to Settings → Security → Personal access tokens → Active tokens and revoke any token associated with the departing employee. If your org enforces SAML SSO, revoking the SSO session at the IdP level effectively neutralizes PATs for org access — even before the per-token audit is complete.
How do I remove GitHub access for someone who left without notice?
The same seven steps apply, in the same order. If your org enforces SAML SSO, revoking at the IdP level is the fastest single action: it terminates the active session and blocks future authentication immediately. On GitHub Enterprise, suspending the user from the enterprise admin panel has the same effect. Then work through org removal, deploy key audit, and PAT revocation to close the remaining gaps.
What is the difference between removing an org member and revoking GitHub access completely?
Removing an org member revokes access to all private org repos and teams. Complete revocation also covers: outside collaborator access on specific repos, deploy keys on CI/CD pipelines, Personal Access Tokens scoped to the org, GitHub App authorizations, and (if applicable) the SAML SSO session at the IdP. Org removal is Step 1 of 7 — the most important step, but not the only one.
Get GitHub deprovisioning off your plate
Running seven manual GitHub steps — every time, on the right day, under time pressure — is a process that slips. KINT runs the full sequence automatically when the termination fires in your HR system: GitHub, Slack, Jira, and every other connected app in a single workflow.
Book a 15-minute walkthrough →
14-day trial · No card · Live in under an hour
Last updated: May 2026. GitHub interface elements referenced reflect GitHub.com as of Q2 2026. Org-level token management UI may vary between GitHub Free, GitHub Team, and GitHub Enterprise plans.
Gowtham Palanisamy
Founder of Kingsley Integrators, building KINT in public. Writes about identity lifecycle, SaaS access, and audit evidence.