Enterprise Managed Users gives an organisation complete control over its GitHub accounts. That sentence sells it, and the second sentence is the one that matters.
Managed accounts cannot create public content, cannot collaborate outside the enterprise, cannot create gists, cannot fork external repositories, and cannot be invited anywhere outside the enterprise. Every one of those is a deliberate property of the model, and every one surprises somebody after the migration.
The short answer
Section titled “The short answer”Accounts are created and controlled by your identity provider. Usernames are generated by normalising an IdP identifier. Profile name and email come from the IdP and the user cannot change them.
The defining statement, in GitHub’s words: “Managed user accounts cannot create public content or collaborate outside your enterprise.”
Only private and internal repositories can be created in enterprise-owned organisations.
Identity provider support is narrower than for standard SAML. SAML is supported with Entra ID, Okta and PingFederate; OIDC is supported with Entra ID only. GitHub states that using “Okta and Entra ID for SSO and SCIM (in either order) is explicitly not supported.”
It is not reversible in any convenient sense. Existing personal accounts are not converted; new managed accounts are created.
The complete constraint list
Section titled “The complete constraint list”Read this before deciding, not after. Each is documented behaviour.
Cannot create public content. No public repositories, in any organisation in the enterprise.
Cannot collaborate outside the enterprise. No participation in repositories owned by other enterprises or by individuals.
Cannot create gists, and cannot comment on gists.
Cannot fork repositories from outside the enterprise. Forking private and internal repositories inside the enterprise is possible, subject to policy.
Cannot follow users outside the enterprise.
On GitHub.com, cannot star, watch, fork, push, open issues or pull requests, or comment on external public repositories.
Cannot be invited to organisations or repositories outside the enterprise, or to other enterprises.
Cannot install GitHub Apps on their user account unless the app is privileged.
Cannot change their own profile name or email, which come from the identity provider.
The two-account reality
Section titled “The two-account reality”Because of the constraint above, engineers who participate in open source end up with two accounts.
Their managed account for work. Controlled by the enterprise, cannot reach outside.
Their personal account for everything else. Their own, with their contribution history, their open-source work, their community identity.
This is workable and it has friction. Two sets of credentials, two Git configurations, switching contexts, and the risk of committing work with the wrong identity or contributing to open source with the wrong one.
Plan for it explicitly. Document how to configure Git for both, using conditional includes so the right identity is used per directory. Do not leave engineers to work it out individually — they will, and inconsistently.
Address contribution attribution. Work done on the managed account is attributed to an account that exists only inside your enterprise. If an engineer’s public contribution record matters to them — and for many it does — say so honestly rather than discovering it as a retention issue.
And be clear about the boundary. Work code on the work account, personal work on the personal account, and never the reverse. That is a policy statement worth making explicit.
Alternatives that get most of the way
Section titled “Alternatives that get most of the way”Before committing to EMU, it is worth knowing what the alternative model achieves, because for many requirements it is close enough.
Personal accounts with enforced SAML and SCIM give you: authentication through your identity provider, provisioning from the directory, deprovisioning on departure, session revocation, credential revocation, and a full audit trail of all of it.
What it does not give you: the guarantee that no account exists outside the directory, and the guarantee that a work account cannot reach outside the enterprise.
For most control objectives, that is sufficient. An auditor asking about access management wants evidence that access is granted through a controlled process and removed promptly. SAML plus SCIM produces that evidence.
The gap that remains is outside collaborators, and it can be narrowed substantially: restrict who may invite them, review the population quarterly, and require a business justification and an expiry date. That is a process control rather than a technical one, and process controls are what most frameworks accept.
And the accidental-public-repository risk can be addressed with an enterprise policy restricting which visibilities members may create, without any of EMU’s other constraints. See visibility and forking policies.
Which suggests a test for the decision: write down the specific requirement EMU satisfies that SAML plus SCIM plus visibility policy does not. If you can write it, EMU is warranted. If the answer is a general preference for control, the alternative is cheaper by a wide margin and constrains nobody.
Identity provider support
Section titled “Identity provider support”Narrower than standard SAML, and the details matter.
SAML: Entra ID, Okta, PingFederate.
OIDC: Entra ID only.
Explicitly unsupported: GitHub states that using “Okta and Entra ID for SSO and SCIM (in either order) is explicitly not supported.” An enterprise running one for authentication and the other for provisioning cannot use that combination under EMU.
Which is a hard constraint on the decision. If your identity estate is a mixture, EMU may not be available to you regardless of whether it is otherwise the right model.
Verify before planning. Provider support changes, and it is precisely the kind of detail that invalidates a project plan late.
OIDC brings additional capabilities where supported, including conditional access policy support — see OIDC for Enterprise Managed Users.
Usernames and profiles
Section titled “Usernames and profiles”Usernames are generated by normalising an IdP identifier, and prefixed by the enterprise’s short code.
Conflicts are possible if the distinguishing part of an identifier is normalised away — two identifiers that differ only in characters the normalisation removes produce the same base username. This is an edge case, and it is worth testing with real directory data rather than sample data before migrating.
Profile name and email come from the IdP. The user cannot change them. Which means your directory’s data quality becomes your GitHub profile data quality, and directory display names are frequently inconsistent.
Fix the directory data before migrating, not after. Correcting it afterwards means every profile changes again.
What EMU actually buys
Section titled “What EMU actually buys”Having listed the costs, the benefits deserve the same precision — because for the organisations EMU fits, they are substantial.
No account exists outside the directory. This is the property that no other model provides. With personal accounts and SCIM, an account can exist, be granted access as an outside collaborator, and never appear in the directory. Under EMU there is no such path.
Deprovisioning is complete. The account suspends. There is no residual identity that persists with some other access, because the account has no existence beyond the enterprise.
The account cannot leak outward. An engineer cannot accidentally push internal code to a public repository from their work account, because their work account cannot create one. This eliminates a whole category of accidental disclosure.
Identity is unambiguous. A commit authored by a managed account was authored by a specific directory identity, verifiably. Under personal accounts, the mapping from GitHub account to employee is a link that can be broken or wrong.
The audit story is simpler. “Every account in this enterprise corresponds to a current directory identity” is a statement you can make and demonstrate. That is a genuinely strong position for an access-management control objective, and it is hard to reach otherwise.
Data residency requires it. If your enterprise needs data held in a specific region, managed accounts come with that decision.
Which is the honest summary: EMU trades openness for completeness. If the requirement is a closed, demonstrable, directory-derived identity boundary, no other model gets there.
Deciding whether EMU fits
Section titled “Deciding whether EMU fits”It fits when:
- Account ownership by the employer is a stated requirement, not a preference
- The regulatory or contractual environment demands demonstrable control over identities
- External collaboration is genuinely not part of how the organisation works
- Your identity provider is one of the supported combinations
- Engineering leadership understands and accepts the two-account reality
It does not fit when:
- The organisation publishes open-source software or wants to
- Engineers are expected to participate upstream in their dependencies
- Substantial work involves external collaborators or partners
- Your identity estate uses an unsupported provider combination
- The driver is “more control” without a specific requirement behind it
Most enterprises should choose personal accounts with SAML and SCIM. That model delivers authentication control, provisioning and deprovisioning, and access review capability, without the constraints. EMU is for the cases where the constraints are the point.
What migration involves
Section titled “What migration involves”Not a settings change. A migration.
-
Establish the enterprise with managed users. This is a distinct enterprise configuration; existing accounts do not become managed.
-
Fix the directory data. Display names, emails, identifiers. Everything flows from here and correcting it later means changing every profile.
-
Test username generation against real directory data, looking for conflicts.
-
Migrate repositories. Content moves; this is a repository migration with all that implies. See GitHub Enterprise Importer.
-
Accept that contribution history does not follow. Commits retain their author information, but the association with the old accounts does not transfer to managed accounts.
-
Re-establish every integration. Apps, tokens, SSH keys, webhooks, CI credentials. Each one, individually.
-
Migrate teams and permissions. These are not carried by a repository migration.
-
Communicate the two-account model well before cutover, with the Git configuration guidance ready.
-
Plan the external collaboration cases explicitly. Every partner, vendor and contractor relationship needs an answer.
Configuring Git for two accounts
Section titled “Configuring Git for two accounts”Since the two-account model is a consequence rather than an option, the configuration guidance is part of the rollout deliverable. Publish it; do not leave people to work it out.
The mechanism is conditional includes. Git can apply different configuration depending on the directory a repository is in.
[includeIf "gitdir:~/work/"] path = ~/.gitconfig-work[includeIf "gitdir:~/personal/"] path = ~/.gitconfig-personal[user] name = Example Name email = example@company.exampleKeep the two trees separate on disk. ~/work/ and ~/personal/, with nothing outside them. The conditional include depends on this, and so does the habit.
Do the same for SSH. Separate keys, with a host alias per account in the SSH configuration, so the right key is offered for the right remote.
Verify rather than assume. git config user.email in a repository, before the first commit, catches the misconfiguration that would otherwise appear in the history.
Set no global default identity. If neither conditional include matches, Git should fail rather than silently using the wrong one. An unset global user.email produces an error on commit, which is exactly the behaviour you want.
Test both paths during rollout. Clone a work repository and a personal one, commit in each, confirm the attribution. Ten minutes, once, per engineer, and it prevents a category of mistake that is embarrassing to correct.
Operating under EMU
Section titled “Operating under EMU”Deprovisioning suspends the account, which is a cleaner outcome than membership removal — the account becomes inert.
All the SCIM disciplines apply, and more so, because SCIM is the only account creation path. See SCIM.
Outside collaborators work differently. External collaboration is constrained by the model, so the mechanisms enterprises use for contractors need to be re-established in whatever form EMU permits. Verify this against current documentation for your configuration — it is one of the most consequential details and one that changes.
Data residency enterprises use managed accounts, so if data residency is in your plan, EMU comes with it and the constraints are not optional.
Machine identities need particular attention. Under EMU, an automation account is a managed account, subject to the same constraints and the same provisioning path. GitHub Apps are the better answer for automation here even more than elsewhere. See machine identities.
Consuming open source under EMU
Section titled “Consuming open source under EMU”Being unable to contribute to open source is one problem. Being unable to interact with it at all is a related and more operational one.
Dependencies still work. Package managers fetch from registries and public repositories; nothing about EMU blocks a build from downloading a library.
Cloning public repositories works. The constraint is on collaboration and account interaction, not on reading public code.
What does not work from a managed account: opening an issue against a dependency, commenting on one, starring a project, watching a repository for releases, or opening a pull request upstream.
Which affects real workflows:
- Reporting a bug in a dependency. The engineer who found it cannot report it from their work account.
- Tracking upstream releases. Watching a repository is how many engineers stay aware of security releases.
- Contributing a fix. The most valuable interaction, and the one that is blocked.
The workarounds, and their honesty:
A designated open-source liaison account — a managed account cannot do it, so this means a personal or organisational account with a defined owner. It works for issue reporting and it is a bottleneck.
Personal accounts for upstream work, with a policy stating when that is appropriate. This is what actually happens, and it is better acknowledged than pretended away.
An organisational open-source presence outside the EMU enterprise, for deliberate contributions. Requires separate governance and a separate enterprise or organisation.
Whatever you choose, decide it before migration. The failure mode is an engineer who finds a bug in a critical dependency, cannot report it, and either does nothing or uses a personal account without guidance — neither of which is what you want.
The vendor and partner question
Section titled “The vendor and partner question”External collaboration is constrained by design, and every enterprise has some. Work through the cases before committing.
Vendors who need read access to a repository. Under other models this is an outside collaborator invitation. Under EMU, external collaboration is restricted, so verify what mechanism is available in your configuration.
Contractors who work as part of a team. If they can be provisioned as managed users through your directory, they are simply members and the question dissolves. If they cannot — because they are not in your directory — this is a genuine constraint requiring a decision.
Partner organisations sharing a codebase. A joint venture or an integration project where both sides contribute. This is the hardest case and it may require a separate enterprise or organisation outside the EMU boundary.
Auditors and assessors needing read access. Time-bounded, usually external, and worth resolving in advance rather than during an audit.
Customer-facing repositories. A support repository where customers open issues is not possible under EMU inside the enterprise, because it requires public visibility.
For each relationship, three questions: can this person be a managed user, if not what access do they actually need, and where must that repository live for them to have it. The answers frequently push toward a structure with an EMU enterprise for internal work and a separate presence for anything external — which is a real architectural consequence, not a detail.
Running EMU day to day
Section titled “Running EMU day to day”Once migrated, the operational shape differs from a standard enterprise in a few specific ways worth knowing.
Account creation is impossible outside SCIM. A new joiner who is not in the directory has no route to access. This is the model working correctly, and it means the directory onboarding process is now on the critical path for engineering productivity — a dependency the identity team may not realise they now own.
Username changes follow the directory. A person whose IdP identifier changes may get a different generated username, which affects mentions, CODEOWNERS entries and anything referencing them by name. Directory identifier changes should be rare, and the ones that happen are worth knowing about in advance.
Suspended accounts are visible. A deprovisioned user’s account remains, suspended, with their history. Their commits still show, their reviews still exist. This is correct — the record is preserved — and it means the member list grows over time with inert accounts.
Support paths change. An engineer who cannot access something has fewer self-service options, because their account cannot be granted anything outside the enterprise. Route these to a team that understands the model rather than a general helpdesk.
Testing is harder. There is no way for an engineer to try something on a personal repository in the same enterprise. Provide a sandbox organisation with permissive settings, or people will improvise.
Documentation must be internal. Public GitHub documentation frequently describes flows that do not apply. An internal page describing what works in your enterprise saves considerable confusion, particularly for new joiners who have used GitHub elsewhere.
Common mistakes
Section titled “Common mistakes”Choosing EMU for “more control” with no specific requirement. The constraints are severe.
Not surveying open-source participation first. It is more common than leadership expects.
Discovering the two-account reality after migration. Plan and document it before.
Assuming any IdP combination works. OIDC is Entra ID only; Okta plus Entra ID is documented as unsupported.
Not fixing directory data first. It becomes your profile data and cannot be user-corrected.
Treating migration as a configuration change. It is a full repository, permission and integration migration.
Not planning external collaboration. Every partner relationship needs an answer.
Underestimating what the importer does not migrate. Secrets, environments, runners, LFS, teams.
What a migration actually costs
Section titled “What a migration actually costs”Because “it is a migration, not a setting” is easy to say and hard to size, here is where the effort goes in practice.
Repository content: the smallest part. Tooling exists, it works, and it is the piece people plan for.
Everything the importer does not carry: the largest part. Actions secrets, variables and environments. Self-hosted runners. Workflow artifacts and run history. Git LFS objects. Teams and team membership when migrating repositories directly. Each is manual, each is per repository or per organisation, and the total scales with the estate.
Integrations: the longest tail. Every app installation, every webhook, every deploy key, every token in a CI system, every service that authenticates to GitHub. These are discovered rather than known, and the discovery is itself work.
Identity data cleanup: the prerequisite. Directory display names and emails, corrected before migration because they cannot be corrected by users afterwards.
Communication and training: consistently underestimated. The two-account model, the Git configuration, the open-source policy, the new URLs. Every engineer needs this, and delivering it late produces the support load.
External relationships: the unbounded part. Every partner, vendor and contractor arrangement needs an individual answer, and some will require structural changes.
Contribution history: an accepted loss. Commits keep their author information; the association with previous accounts does not transfer. Say this clearly in advance — for some engineers it matters.
Plan for the tail, not the headline. The repository migration is the visible milestone and roughly a fifth of the work.
Mental model
Section titled “Mental model”EMU makes GitHub accounts corporate property. Everything follows from that: the account cannot reach outside the enterprise, cannot represent the person publicly, and cannot exist without the directory. It is the right model when that is the requirement, and it is a large cost when it is merely the preference.
What you learned
Section titled “What you learned”- Managed accounts are created and controlled by the identity provider, with usernames generated from a normalised identifier
- Managed user accounts cannot create public content or collaborate outside the enterprise
- The constraint list also covers gists, external forks, following, starring, watching, and invitations outside the enterprise
- Only private and internal repositories can be created in enterprise-owned organisations
- SAML is supported with Entra ID, Okta and PingFederate; OIDC with Entra ID only
- Okta and Entra ID for SSO and SCIM in either order is explicitly not supported
- Profile name and email come from the IdP and cannot be changed by the user
- Engineers who participate in open source will need two accounts, and this must be planned for
- Migration is a full repository, permission and integration migration, not a configuration change
Exercise
Section titled “Exercise”Reason from your own enterprise’s position.
-
Survey how many engineers have contributed to an external open-source repository in the last year. Predict: more or fewer than you expected?
-
List every external collaboration relationship: partners, vendors, contractors. For each, state how it would work under EMU.
-
Check your identity provider combination against the supported matrix.
-
Sample twenty directory display names and email addresses. Predict: how many are inconsistent or wrong?
-
List every integration authenticating to GitHub today. Estimate the work to re-establish each.
-
Count Actions secrets, environments and self-hosted runners across the estate — none of which the importer migrates.
-
Write the two-account policy you would publish, including the Git configuration guidance.
-
State, in one sentence, the requirement that would justify EMU for your organisation. If you cannot, that is the answer.