An organisation with SAML SSO and no SCIM has centralised its logins and not its access.
When somebody leaves, their identity provider account is disabled. Their GitHub account still exists. Their personal access tokens still work. Their SSH keys still authenticate. Nothing about single sign-on addresses any of that, and the belief that it does is the most common identity finding in enterprise GitHub estates.
Start with Enterprise IAMWhat this cluster answers
Section titled “What this cluster answers”Four concerns, four mechanisms
Section titled “Four concerns, four mechanisms”The distinction this entire cluster rests on. These terms are used interchangeably in conversation and they are not interchangeable in practice.
| Concern | Mechanism | Answers |
|---|---|---|
| Authentication | SAML or OIDC SSO | Who are you? |
| Provisioning | SCIM | Should an account exist at all? |
| Membership | IdP groups mapped to teams | Which teams are you in? |
| Authorization | Repository roles | What may you do here? |
Each can be present without the others. An enterprise can have SSO without SCIM (logins centralised, lifecycle manual), SCIM without group mapping (accounts created, teams by hand), or both without a coherent role model (everybody provisioned correctly into admin).
The gaps between them are where findings live. Enterprise IAM covers the architecture as a whole; the individual articles cover each mechanism.
The lifecycle
Section titled “The lifecycle”A vertical chain: an employee joins; the identity provider creates them; SCIM provisions a GitHub identity; IdP group membership maps to teams; teams grant repository access. On departure the IdP account is disabled, SCIM deprovisions, access is removed, and an audit verifies.
Every arrow is a place the chain breaks. An IdP group that nobody mapped to a team. A repository granted to an individual rather than through a team, which no group change ever removes. A token created before SSO was enforced. A deploy key added during an incident.
The last step exists because the first seven are never complete. Access reviews and offboarding is the article about finding what the pipeline missed, and no organisation reaches a point where it stops finding things.
Two enterprise identity architectures
Section titled “Two enterprise identity architectures”GitHub Enterprise Cloud supports two fundamentally different models, and almost every question in this cluster has a different answer depending on which you use.
Personal accounts with SAML. Users have their own GitHub accounts — the same account they might use for open source — and the enterprise requires SAML authentication to access its resources. The person owns the account; the enterprise controls access to its own content.
Enterprise Managed Users. The enterprise owns the accounts. They are provisioned by the identity provider, named by it, and cannot exist outside the enterprise. GitHub’s documentation states plainly that managed user accounts cannot create public content or collaborate outside your enterprise.
The choice constrains everything downstream — how SCIM behaves, whether OIDC is available, what external collaboration looks like, and which audit features you can use. It is the most consequential identity decision an enterprise makes and it is difficult to reverse.
Machine identities are identities
Section titled “Machine identities are identities”The half of IAM that access reviews forget.
A GitHub estate contains far more non-human identities than human ones: GitHub Apps, GITHUB_TOKEN in every workflow run, deploy keys, personal access tokens used by automation, and OIDC trust relationships with cloud providers.
They have different properties from human identities. No IdP lifecycle, no joiner-leaver event, and frequently no owner once the person who created them has left.
A personal access token belonging to a departed engineer is the classic finding. It authenticates as them, it does not appear in any group membership, and disabling their IdP account does not necessarily stop it.
Machine identities covers choosing the right identity for each automation purpose, and why a GitHub App is almost always better than a token belonging to a person.
Where this cluster differs from Pillar 5
Section titled “Where this cluster differs from Pillar 5”Pillar 5’s least-privilege article covers the access model: what the roles mean, how to scope tokens, how to review permissions. Read it first.
This cluster is about the system that assigns access, not the access itself: how identities come into existence, how membership is derived from an authoritative source, what happens automatically when somebody leaves, and how you verify any of it worked.
The relationship in one line: Pillar 5 asks whether this permission is correct; Pillar 8 asks how this person got it and what removes it.
Access should flow through teams
Section titled “Access should flow through teams”The single structural decision that makes identity automation possible.
Grant repository access to teams. Never to individuals.
Why it matters more than it sounds: an individual grant is invisible to every group-based mechanism. SCIM removes somebody from an IdP group, the group is mapped to a team, the team loses its repository access — and an individual collaborator grant on the same repository survives all of it, because nothing in that chain ever knew about it.
The rule extends to outside collaborators. Where a person genuinely needs access outside the team model, that is an exception with an owner and an expiry, not a permanent grant nobody revisits.
The practical consequence for an access review: the list of individual repository collaborators across the estate is a high-value report, because every entry on it is access that no automated process will ever remove. In most organisations that list is longer than anybody expects and contains people who left.
Building it correctly from the start is much cheaper than retrofitting, because unwinding individual grants means finding out whether each one is load-bearing before removing it.
The IdP is the source of truth
Section titled “The IdP is the source of truth”A framing that resolves most design questions in this cluster.
GitHub should not be where you decide who works here. That decision lives in the identity provider, which is fed by whatever HR or contractor system is authoritative. GitHub’s job is to reflect it.
What follows:
Do not create GitHub accounts by hand in an enterprise with provisioning. An account created outside the pipeline is one the pipeline will not remove.
Do not manage team membership in GitHub’s UI where groups are mapped. It works, it drifts, and the next group sync may undo it — or may not, which is worse because now nobody knows which system is authoritative.
Do not treat a GitHub-side removal as offboarding. It removes today’s access and nothing about tokens, keys or the account itself.
Where GitHub does decide things: repository roles and what a team can do once it has access. That is authorisation, it is genuinely GitHub’s domain, and it is the layer Pillar 5 covers.
The test for a healthy setup: if the IdP is the source of truth, then disabling somebody there should — without any human action on GitHub — end their access. Most organisations discover on testing this that something remains, and finding out during a drill is considerably better than during an incident.
Learning objectives
Section titled “Learning objectives”By the end of this cluster you should be able to:
- Distinguish authentication, provisioning, membership and authorisation, and name the mechanism for each
- Explain why SSO alone does not deprovision anybody
- Describe how SAML SSO works for personal-account enterprises and how it differs under managed users
- Configure a mental model of SCIM provisioning including what happens on soft and hard deprovision
- Decide whether Enterprise Managed Users fits an organisation, and articulate what it costs
- Say why OIDC for managed users and OIDC for GitHub Actions are unrelated
- Map identity provider groups to teams, and explain what breaks when access is granted to individuals instead
- Choose the right machine identity for a given automation, and avoid personal tokens in automation
- Run an access review that finds what the provisioning pipeline missed
Enterprise use cases
Section titled “Enterprise use cases”A joiner-leaver audit finding. Fifteen former employees still have organisation membership, and the remediation is a provisioning pipeline rather than a spreadsheet.
A merger. Two identity providers, two GitHub estates, and a need to converge without locking anybody out.
A regulated environment requiring demonstrable access control: who could reach this repository, when, and what removed them.
A contractor population with fixed end dates that must actually take effect.
An EMU evaluation. An organisation deciding whether the control is worth the collaboration cost, needing an honest account of both.
Token sprawl. Hundreds of personal access tokens with unknown scope and unknown owners, needing a migration to Apps and OIDC.
Adoption order
Section titled “Adoption order”Identity work has a natural sequence, and doing it out of order wastes effort.
1. Inventory what exists. Members, outside collaborators, teams, individual repository grants, tokens, deploy keys, Apps. This is uncomfortable and it is the input to everything else.
2. Enforce SSO. Centralises authentication and is the prerequisite for the rest. It does not deprovision anybody, and saying so out loud prevents a false sense of completion.
3. Add SCIM provisioning. The step that actually closes the leaver gap. Test the deprovision path deliberately rather than assuming it works.
4. Map groups to teams. Membership becomes derived rather than maintained.
5. Convert individual grants to team grants. Tedious, and it is what makes steps 3 and 4 effective. Until this is done, group changes do not remove all access.
6. Migrate automation off personal tokens. GitHub Apps and OIDC, covered in machine identities.
7. Establish periodic access review. Because none of the above is ever complete.
Steps 2 and 3 are frequently conflated into one project called “SSO”, and the project is declared finished after step 2. That is the specific failure this cluster exists to prevent — the resulting estate has a centralised login and an uncontrolled leaver population, which is a worse position than before because everybody believes it is handled.