Identity is the enterprise decision that is hardest to change later.
Rulesets can be rewritten in an afternoon. Repository structure can be migrated over a quarter. An identity model touches every account, every credential, every integration and every external collaboration relationship, and changing it is a project measured in months.
The short answer
Section titled “The short answer”Three models, in increasing order of control and constraint.
Personal accounts, no SSO. Members use their own GitHub accounts. Membership is managed in GitHub. Nothing connects to the corporate directory.
Personal accounts with SAML SSO. Members still use their own GitHub accounts, but must authenticate with your identity provider to access organisation resources. Optionally with SCIM for provisioning.
Enterprise Managed Users. Accounts are created and controlled by your identity provider. Users cannot create public content or collaborate outside the enterprise.
The choice is a trade between control and openness, and it is not reversible in any convenient sense.
What SAML SSO actually does
Section titled “What SAML SSO actually does”Precision matters here, because SAML is routinely believed to do more than it does.
GitHub’s description: “Single sign-on (SSO) gives organization owners and enterprise owners a way to control and secure access to organization resources like repositories, issues, and pull requests.”
Three states: disabled, enabled but not enforced, or “enabled and enforced.”
Members must periodically re-authenticate. GitHub documents that “Members must periodically authenticate with your IdP to authenticate and gain access to your organization’s resources”, with a login period that “is generally 24 hours.”
What it does not do:
- “SAML SSO does not replace the normal sign-in process for GitHub.” Members still have their own GitHub accounts, sign in to GitHub normally, and additionally authenticate with your IdP for organisation access.
- It does not manage membership. Adding somebody to your IdP does not make them an organisation member; that is SCIM’s job.
- “SSO authentication is not required for outside collaborators.” The collaborator population sits outside SAML entirely.
- It does not gate public repository access. Viewing a public repository’s contents and cloning it do not require IdP authentication.
Supported identity providers for organisation SAML, as documented: Microsoft AD FS, Microsoft Entra ID, Okta, OneLogin, PingOne and Shibboleth, plus “IdPs that implement the SAML 2.0 standard.”
Credentials and SAML
Section titled “Credentials and SAML”The part that generates the most support load.
Personal access tokens (classic) must be authorised after creation before they can access an organisation using SAML SSO. SSH keys likewise.
Fine-grained personal access tokens are authorised during token creation, before access is granted, which is a better model.
A linked external identity is a prerequisite. GitHub documents that “before you can authorize a personal access token or SSH key, you must have a linked external identity”, created by authenticating with the IdP at least once.
Revocation is one-way for SSH keys. If an organisation revokes an SSH key’s authorisation, “you will not be able to reauthorize the same key and will need to create a new SSH key and authorize it.”
Organisation owners can view and revoke a member’s linked identity, active sessions and authorised credentials, in one place. This is the single most useful screen in an incident, because it shows every way a person currently has access.
Prefer fine-grained tokens for exactly this reason: the authorisation is part of creation rather than a separate step people forget, and the permissions are explicit.
Enterprise Managed Users
Section titled “Enterprise Managed Users”The strongest model, with the strongest constraints.
Accounts are created by your identity provider and controlled by it. Usernames are generated from an IdP identifier; profile name and email come from the IdP and the user cannot change them.
The defining constraint, in GitHub’s words: “Managed user accounts cannot create public content or collaborate outside your enterprise.”
Which means, concretely: no public repositories, no gists, no forking repositories from outside the enterprise, no starring or watching or opening issues on external public repositories, no following users outside the enterprise, and no being invited to organisations or repositories outside the enterprise.
Identity provider support is narrower. SAML is supported with Entra ID, Okta and PingFederate; OIDC is supported with Entra ID only. And GitHub is explicit that using “Okta and Entra ID for SSO and SCIM (in either order) is explicitly not supported.”
Deprovisioning suspends the account. A user removed in the IdP is suspended and cannot access the enterprise.
Enterprise Managed Users covers the full constraint set, which is longer than most enterprises expect.
Enterprise-level versus organisation-level SAML
Section titled “Enterprise-level versus organisation-level SAML”A distinction that determines how much of the estate a single configuration covers.
Organisation-level SAML is configured per organisation. Each organisation has its own identity provider connection, its own enforcement state, and its own set of linked identities.
Enterprise-level SAML is configured once for the enterprise and applies across its organisations.
Prefer enterprise-level. One configuration, one certificate to rotate, one enforcement decision, and no possibility of an organisation being missed. With organisation-level SAML across twenty organisations, you have twenty configurations that can drift and twenty certificates with twenty expiry dates.
The migration between them is real work. Moving from organisation-level to enterprise-level SAML re-establishes linked identities, which means every member re-authenticates and every authorised credential is affected. Plan it as a change with a communication plan, not as a settings toggle.
Check what you actually have. Many enterprises that grew from a single organisation still have organisation-level SAML on that original organisation, with enterprise-level SAML added later — and both configured, which is a state worth resolving deliberately.
Certificates, and the outage nobody plans for
Section titled “Certificates, and the outage nobody plans for”The single most common identity incident, and it is entirely preventable.
SAML depends on a signing certificate from your identity provider, and certificates expire.
When it expires, nobody can authenticate. Not gradually — at the moment of expiry, every SAML authentication fails, and with SAML enforced that means nobody can access organisation resources. Existing sessions continue until they lapse, so the failure spreads over the following hours rather than arriving at once, which makes it more confusing rather than less.
Recovery codes are the way back in. Enterprise and organisation owners are given recovery codes when SAML is configured, and they are what allows an owner to sign in and fix the configuration when SAML itself is broken.
Which means the recovery codes must exist, be findable, and be held by more than one person. A single owner holding the only copy, on a laptop, is a single point of failure for the entire enterprise’s access.
Store them in the corporate secret manager, accessible to the people who would need them, and check annually that they still work and that the people who can reach them still work here.
Diary the certificate expiry. Not as a calendar reminder in one person’s calendar — as a monitored expiry with an alert, sixty days ahead, to a team address. This is a five-minute task that prevents a full-enterprise outage.
Choosing
Section titled “Choosing”| Personal, no SSO | Personal + SAML/SCIM | EMU | |
|---|---|---|---|
| Account controlled by | The user | The user | Your IdP |
| Access requires IdP auth | No | Yes | Yes |
| Provisioning from IdP | No | With SCIM | Yes |
| Deprovisioning removes access | No | With SCIM | Yes, suspends |
| Public repositories | Yes | Yes | No |
| External collaboration | Yes | Yes | No |
| Outside collaborators | Yes | Yes, outside SAML | Restricted |
| Contribution to open source | Yes, same account | Yes, same account | Separate account needed |
Choose personal accounts with SAML and SCIM if you need identity control and your people also participate in the wider GitHub ecosystem. This is the right answer for most enterprises.
Choose EMU if the requirement is genuinely that accounts must be fully controlled and isolated — a regulated environment, a government context, or an organisation where account ownership by the employer is a stated requirement.
Do not choose EMU for convenience. The constraints are severe, they surprise people, and moving away from EMU is harder than moving to it.
A sequenced adoption path
Section titled “A sequenced adoption path”For an enterprise starting from personal accounts with nothing connected, this is the order that works.
-
Enforce two-factor authentication across the enterprise. Independent of everything else, immediately valuable, and it does not depend on any integration.
-
Configure SAML at the enterprise level, enabled but not enforced. Members link their identities voluntarily. Watch the link rate.
-
Chase the stragglers. The gap between members and linked identities is the work. Expect some accounts to turn out to be machine accounts, shared accounts, or people who left — all of which are findings.
-
Store and test the recovery codes before enforcing. This is the step people skip and regret.
-
Enforce SAML. Announce it, pick a low-traffic time, and have somebody on hand who holds the recovery codes.
-
Add SCIM. Now that identities are linked, provisioning and deprovisioning can be driven from the directory. This is where the real access control benefit arrives.
-
Map directory groups to teams. Team membership becomes a directory concern, and access reviews become tractable.
-
Then address credentials. Inventory tokens and keys, set expiry policies, move automation to GitHub Apps. This is the longest step and it is the one that closes the biggest gap.
-
Only then consider EMU, if the requirement genuinely calls for it. Steps 1 through 8 deliver most of the control benefit at a fraction of the disruption.
Step 3 is where the value is discovered. Reconciling the member list against the directory is the first time most enterprises find out exactly who has access, and the answer is reliably surprising.
The layers of an identity model
Section titled “The layers of an identity model”Four separate concerns that people conflate, and separating them makes the design tractable.
Authentication — proving who you are. SAML or OIDC, handled by your IdP.
Provisioning — creating and removing accounts. SCIM, or manual.
Authorisation — what you can do once in. Organisation membership, teams, roles, base permissions. Largely not managed by the IdP, even with SCIM — SCIM can drive team membership from groups, but repository permissions are GitHub’s.
Credentials — how machines and scripts authenticate. Tokens, SSH keys, GitHub Apps. This is the layer people forget, and it is where most standing access actually lives. See machine identities.
A control that covers three of the four is not a control. An enterprise with perfect SAML and SCIM, and a hundred long-lived personal access tokens, has an identity model with a large hole in it.
The populations to account for
Section titled “The populations to account for”An identity design that only considers full-time employees is an identity design with gaps. Enumerate the populations explicitly.
Employees. The easy case. Provisioned from the directory, deprovisioned on leaving, subject to SSO.
Contractors and agency staff. In the directory or not, depending on how your organisation handles them. If they are in the directory, they are the same as employees. If they are outside collaborators, they are outside every identity control you have.
Partner and vendor engineers. Almost always outside collaborators, almost always long-lived, and almost never reviewed. This is where stale access concentrates.
Machine accounts. Bots, service accounts, integrations. Covered in machine identities, and worth naming here because they are frequently created as human accounts with a person’s email, which puts them in the directory and then breaks when that person leaves.
Former employees who contributed. Their commits remain, attributed to their account. Nothing to manage, and worth understanding when somebody asks why a departed person’s name appears in a recent view.
Auditors and reviewers. Time-bounded read access, usually granted as outside collaborators, usually never removed.
Emergency and break-glass accounts. If they exist, they need the strongest controls and the most frequent review, and they are the accounts most likely to have been set up once and forgotten.
For each population, four questions: how do they get access, how is that access reviewed, how is it removed, and who is accountable for the answers. Any population where you cannot answer all four is a finding.
Where GitHub identity meets the rest of the estate
Section titled “Where GitHub identity meets the rest of the estate”GitHub is one system among many, and the identity model has to work with the others.
The directory is the source of truth. Joiners, leavers and movers happen there. Every downstream system, including GitHub, should be derived from it rather than maintained alongside it.
Group membership drives team membership, through SCIM. Which means the quality of your directory groups determines the quality of your GitHub teams — and directory groups are frequently maintained to a lower standard than people assume, because until now nothing important depended on them.
Auditing this connection is worthwhile. Compare a GitHub team’s membership to the directory group that supposedly drives it. Differences mean either the synchronisation is not working or somebody has been adding members directly.
Joiner-mover-leaver processes need a GitHub step, and “mover” is the one usually missing. Somebody changing teams keeps their old access unless something removes it, and nothing does unless the directory groups change and synchronisation is in place.
Access certification tooling, where an organisation has it, needs GitHub data to be useful. That means exporting membership, team and permission data on a schedule. See compliance evidence.
And the incident response path needs to include GitHub. When an account is compromised, the response is: revoke sessions, revoke authorised credentials, suspend the account. Knowing where those controls are before an incident is worth a great deal more than knowing during one.
Measuring the identity position
Section titled “Measuring the identity position”Six numbers that describe an enterprise’s identity posture, all obtainable without a project.
Members without a linked external identity. With SAML enforced this should be zero. Any non-zero value is either a machine account, a shared account, or somebody who should not be a member.
Outside collaborators, and their age. The population outside SAML. The age distribution is the interesting part — anything older than a year needs a reason.
Authorised classic personal access tokens, by age. Long-lived tokens are standing access that survives most identity controls. The oldest one is usually older than anybody expects.
Enterprise and organisation owners. Small, powerful, and reliably stale.
Time from directory removal to GitHub access removal. The deprovisioning metric. With SCIM it should be minutes; without it, it is however long the manual process takes, which is frequently never.
Two-factor coverage. Should be 100% and enforced. Anything less is worth fixing before anything more sophisticated.
Publish them quarterly. These numbers change slowly, they are easy to produce once the queries exist, and a trend line is far more persuasive than a snapshot when arguing for the next piece of work.
Common mistakes
Section titled “Common mistakes”Believing SAML manages membership. It manages authentication; SCIM manages membership.
Forgetting outside collaborators. They are outside SAML and outside SCIM.
Choosing EMU without understanding the constraints. No public content, no external collaboration, and no easy way back.
Assuming EMU works with any IdP combination. OIDC is Entra ID only, and Okta with Entra ID is documented as not supported.
Ignoring the credential layer. Tokens and keys are where standing access lives.
Using classic personal access tokens under SAML. Authorisation is a separate step people forget; fine-grained tokens authorise at creation.
Enabling SAML without enforcing it. Enabled-but-not-enforced is a transitional state, not a destination.
Treating identity as a one-time project. Access reviews, credential rotation and offboarding are continuous.
What identity does not solve
Section titled “What identity does not solve”Worth stating, because identity programmes are frequently over-scoped on the assumption that they close more than they do.
It does not tell you who has access to what. SAML says who can sign in. Authorisation — which repositories, at what level — is teams and permissions, and it needs its own review. See access reviews and offboarding.
It does not cover machine access. A GitHub App with an installation on every repository authenticates by private key and knows nothing about your identity provider. See machine identities.
It does not prevent a compromised session being used. SSO reduces the window; it does not eliminate it. Session revocation is the control that matters during an incident.
It does not stop somebody cloning a repository before they leave. Read access means copy access, always, and no identity model changes that. What identity gives you is a record of who had access when.
It does not, by itself, satisfy a compliance control. An auditor asking about access management wants evidence of the process — reviews performed, exceptions approved, removals timely — and the configuration is one input to that, not the answer.
Being clear about the boundaries is what prevents an identity programme from being declared complete while three of its four layers remain uncovered.
Mental model
Section titled “Mental model”Identity has four layers — authentication, provisioning, authorisation and credentials — and GitHub’s identity products cover different subsets of them. SAML is authentication. SCIM is provisioning. EMU is account ownership. None of them covers credentials, and credentials are where the standing access is.
What you learned
Section titled “What you learned”- Three models: personal accounts, personal accounts with SAML SSO and SCIM, and Enterprise Managed Users
- SAML controls access to organisation resources but does not replace GitHub sign-in and does not manage membership
- The SAML login period is generally 24 hours
- Outside collaborators are not subject to SAML SSO
- Classic tokens and SSH keys must be authorised separately; fine-grained tokens authorise at creation
- A revoked SSH key authorisation cannot be reinstated for the same key
- Managed user accounts cannot create public content or collaborate outside the enterprise
- EMU supports SAML with Entra ID, Okta and PingFederate, and OIDC with Entra ID only
- Migrating to EMU is a migration project, not a configuration change
- Identity has four layers, and credentials are the one most often left uncovered
Exercise
Section titled “Exercise”Use an enterprise you have access to.
-
Determine which identity model your enterprise uses today. Predict: could you have named it before checking?
-
If SAML is configured, is it enforced or merely enabled?
-
Count outside collaborators across the enterprise. Predict: how many, and how many are still needed?
-
For one member, open their SAML access view. List their linked identity, active sessions and authorised credentials.
-
Count authorised classic personal access tokens across the enterprise. How old is the oldest?
-
Map your enterprise against the four layers. Which layer is weakest?
-
If you were choosing today, which model would you choose, and what would the migration cost?