Enterprise Managed Users usually enters the conversation as a security upgrade. Someone says “we already have SSO, this is just SSO done properly,” and the room nods. That framing is wrong in a way that costs teams months.
EMU is not an authentication setting. It is a decision to move the entire identity lifecycle of your developers out of GitHub and into your identity provider, and to accept a materially different GitHub in return. Made deliberately, it is the right call for a lot of regulated organizations. Made casually, it produces a platform your developers quietly resent and an unwind project nobody budgeted for.
What EMU actually does
The first thing worth knowing is that this is a decision you make before you have an enterprise. GitHub is explicit: “Before you create your enterprise account, you must choose an enterprise type” — an enterprise with personal accounts, or an enterprise with managed users (GitHub docs).
With managed users, your IdP provisions the accounts and stays the source of truth for them. Users authenticate through the IdP to reach anything in your enterprise. Usernames, profile names, email addresses, organization membership and repository access are all controlled upstream, and managed users cannot change them on GitHub. If you use OIDC SSO, GitHub also evaluates your IdP's Conditional Access Policy on requests (GitHub docs).
The restrictions people don't read until later
Managed user accounts can contribute only to private and internal repositories inside your enterprise, plus their own private repositories. On GitHub.com they get read-only access to everything else — and that applies to API requests too, not just the web UI (GitHub docs).
Concretely, a managed user cannot push code, open issues or pull requests, comment or react anywhere outside the enterprise. They cannot star, watch or fork an external repository, or follow users outside the enterprise. They cannot create gists of any visibility, build a personalized profile, or create public repositories or externally visible GitHub Pages sites. They cannot sign up for Copilot Pro or Copilot Free — Copilot access has to come from a Business or Enterprise subscription you grant them. Codespaces are enterprise-owned only, and GitHub-hosted runners aren't available for repositories owned by managed user accounts, which also rules out Copilot cloud agent in those repositories.
Read that list as a developer rather than as an administrator. Every engineer who files an upstream bug against a dependency, maintains a side project, or has a conference talk repo now needs a second, personal account.
GitHub names the risk itself: a managed user who needs to collaborate outside the enterprise must maintain a separate personal account, and “the complexity of regularly switching between accounts can increase the risk of mistakenly leaking internal code to the public.”
That is a manageable policy question. It is a bad surprise.
Settle the IdP question first
GitHub names three partner IdPs with a supported end-to-end integration — Entra ID, Okta and PingFederate — and its guidance is to use a single partner IdP for both authentication and provisioning. Provisioning runs on SCIM; authentication on SAML or OIDC.
That guidance is not a style preference. The combination of Okta and Entra ID for SSO and SCIM, in either direction, is explicitly unsupported: GitHub's SCIM API returns an error to the identity provider on provisioning attempts when that pairing is configured (GitHub docs). We have seen organizations design a split-IdP architecture on a whiteboard, get several sprints in, and find this the hard way. If you run both Okta and Entra — and plenty of enterprises do, mid-consolidation — decide which one owns GitHub before anyone opens a configuration screen.
You can use non-partner systems, provided they follow GitHub's integration guidelines, do SAML 2.0 for authentication and SCIM 2.0 for lifecycle. But GitHub does not test every identity system, and its support team may not be able to help when something breaks. For a regulated client, “our IdP integration sits outside vendor support” is a sentence with audit consequences.
The part that makes it a one-way door
If you already run an enterprise with personal accounts, you cannot convert it. GitHub states plainly that “adoption of Enterprise Managed Users requires migration to a new enterprise account” (GitHub docs), arranged through GitHub Sales.
This is why EMU belongs in the assessment phase of a migration rather than in a hardening backlog afterwards. Deciding it late means doing the move twice.
Who EMU is genuinely right for
EMU earns its constraints when centralized identity control is a requirement rather than a preference. Public sector and regulated financial clients are the clearest fit: joiner-mover-leaver has to be provable, offboarding has to be immediate and auditable, and “a developer kept access through a personal account” is an audit finding.
There is also one case where the decision is made for you. If you adopt GitHub Enterprise Cloud with data residency, GitHub requires Enterprise Managed Users — the two ship together. If residency is driving your architecture, read Cloud vs Server and the Canadian data residency problem first, because in Canada that chain leads somewhere specific.
It fits poorly where open-source contribution is part of the engineering culture or the recruiting pitch, where a large contractor population also works for other clients, or where you cannot yet name a single IdP that owns GitHub.
What to settle before you turn it on
Four things, in this order. Which single IdP owns GitHub, decided and written down. What your developers do about upstream and personal work, decided as policy rather than left to improvisation. How organization and team membership maps to IdP groups, because doing that by hand at scale reintroduces the drift you adopted EMU to eliminate. And what your repository baseline looks like on day one — EMU governs who your users are, not what your repositories enforce. Those are separate problems, and Safe Settings solves the second one.
Identity design is part of the assessment in every GitHub Enterprise migration we run — and if you're still mapping the platform, start with what GitHub Enterprise actually includes.