Can You Use a GitHub EMU Account Alongside Your Personal GitHub Account Under the ToS? — Reading ToS B.3's 'One Free Account' Rule Against the Contract Structure and the Official Docs

Once a company starts rolling out Enterprise Managed Users (EMU) on GitHub Enterprise Cloud through Microsoft Entra ID, one question keeps coming back: is the same human allowed to hold the new EMU account and their existing personal GitHub account at the same time?

On a first read of GitHub Terms of Service, B.3’s “One person or legal entity may maintain no more than one free Account” looks like it collides head-on with that setup. Read in isolation, the clause leads to a conclusion that is the opposite of what GitHub itself documents in several places. This post reads the ToS, the Customer Agreement, the GitHub Enterprise Cloud Product Specific Terms, and GitHub Docs side by side to see how far the EMU-plus-personal pattern actually is from the rule.

The short answer is that it is allowed, conditionally. The conditions are: only one personal account, EMU usage within the employer’s policy, and no work code pushed to the personal account.

ToS B.3 restricts “free Accounts,” not all accounts

Under GitHub Terms of Service, Section B.3 “Account Requirements” says:

One person or legal entity may maintain no more than one free Account (if you choose to control a machine account as well, that’s fine, but it can only be used for running a machine).

You may maintain no more than one free machine account in addition to your free Personal Account.

The subject of the limit is free Account. Section A of the ToS defines Personal Account as “an individual User’s authorization to log in to and use the Service,” and B.3 itself explicitly permits one free Personal Account together with one free machine account. Section B.3 is not a global cap of “one account per human” across all types; it is a cap on free-tier accounts.

An EMU account is not a free account

Next, what kind of account is an EMU account? GitHub Docs “Types of GitHub accounts” separates user accounts into Personal accounts and Managed user accounts, and says:

If your account was created for you by an enterprise on GitHub Enterprise Cloud, you are using a managed user account.

An EMU account is not something a human signs up for. The employer’s IdP (Microsoft Entra ID in this case) provisions it over SCIM, and the enterprise controls the username, profile fields, organization membership, and repository access. On the licensing side, GitHub Customer Agreement §1.3 Accounts says:

Customer may assign each Subscription License to one individual End User … End User accounts may not be shared by individuals. For GitHub’s cloud-based offerings, a Subscription License provides access to only one (1) cloud service at a time, such as to GitHub.com or to an enterprise-managed environment in GitHub Enterprise Cloud.

The EMU account is an End User account that consumes a Subscription License the customer purchased, and it is governed by the contract between the customer and GitHub. That is a different contract, a different license posture, and a different owner from the free Personal Account the individual signs up for.

Reading these two together: the “one free Account” clause in ToS B.3 restricts free Personal Accounts; an EMU account is neither free nor a Personal Account in the ToS sense. One caveat worth flagging: no official document states “the one-free-account clause does not apply to managed user accounts” in so many words. The reading above is an interpretation of the text and the contract structure, not an explicit carve-out.

The official documentation assumes the two accounts coexist

The strongest support for the interpretation above is not textual gymnastics on ToS B.3 but the fact that GitHub’s own documentation treats EMU-plus-personal as a supported setup in multiple pages.

Choosing an enterprise type for GitHub Enterprise Cloud says:

Managed user accounts can only contribute to repositories within your enterprise.

For a managed user to collaborate outside your enterprise, they must also maintain a separate, personal account. The complexity of regularly switching between accounts can increase the risk of mistakenly leaking internal code to the public.

That is “must also maintain,” not “may.” Getting started with Enterprise Managed Users adds:

Developers may need to maintain separate, personal accounts for their work outside of your enterprise with managed users. You can help them manage multiple accounts by providing the following resources

It then points at the Managing multiple accounts Git setup page and the Switching between accounts web-UI account switcher. The account switcher page is just as direct:

You can use the account switcher … if you need to switch between your personal account and managed user accounts in an enterprise that uses Enterprise Managed Users.

GitHub CLI’s multi-account guidance then explains how gh auth login and gh auth switch work across accounts. For SSH and HTTPS, the Managing multiple accounts page linked above has the steps. Because the same SSH key cannot be attached to two accounts, it recommends defining an aliased host under ~/.ssh/config with git config --global url."[email protected]:octocat-emu/".insteadOf ..., or on the HTTPS side setting credential.https://github.com.useHttpPath true and issuing a per-account PAT.

If ToS B.3 forbade the EMU-plus-personal pattern, it would be unusual for the same vendor to ship UI, CLI, and configuration guidance that assumes exactly that pattern. Personal account management is explicit about it too: it describes “a personal account for open source contributions” alongside “a user account for you within an enterprise,” and notes that managed user accounts cannot contribute to public projects on GitHub.com, so the personal account is the one used for that.

The EMU-side restrictions are what create the need for a personal account

The reason GitHub documents this pattern at all is that EMU accounts come with real functional restrictions. Abilities and restrictions of managed user accounts covers them in depth; the summary that matters for this discussion:

Area	EMU account restriction (summarized from official docs)
Contribution scope	Can contribute only to private and internal repositories within the enterprise and to its own private repositories. Read-only elsewhere on GitHub.com
External repositories	Cannot push, open issues or PRs, comment, react, star, watch, or fork outside the enterprise
Public content	Cannot create public repositories, cannot create gists at any visibility, cannot publish Pages sites visible outside the enterprise
Invitations and visibility	Cannot be invited to orgs or repos outside the enterprise, nor to other enterprises. Not visible to users outside the enterprise and cannot be mentioned by them
Other	Cannot follow users outside the enterprise, cannot create a personal profile, cannot sign up for Copilot Pro or Free, cannot take GitHub Certifications

Everything a developer typically does outside of their employer’s repositories (contribute to OSS, write a public gist, publish a personal library, keep a personal profile) is out of scope for the EMU account. For anyone who wants to do any of that, a personal account is not optional.

What the contract-side documents actually say

The ToS governs the Personal Account. The customer-side contracts govern the EMU side, and they are structured to match.

GitHub General Terms, Version March 2025

§1.3 Accounts: “Customer may assign each Subscription License to one individual End User … End User accounts may not be shared by individuals.”
§1.4 End Users: “Customer controls access to and use of the Products by End Users. Customer is responsible for its End Users’ use.”

GitHub Enterprise Cloud Product Specific Terms, Version October 2024

§7: “If you use GitHub Enterprise Cloud with the ‘Enterprise Managed Users’ feature, the portions of these terms that relate to Public Repositories do not apply to you.”
Definition: “‘Enterprise Managed Users’ means the product functionality in GitHub Enterprise where the Customer manages the lifecycle and authentication of Customer’s End Users.”
§1.C: “Customer’s End Users must comply with the Acceptable Use Policies.”

The important thing is that the contracting party and the responsibility are different. The personal account is governed by the ToS between the individual and GitHub. The EMU account is governed by the contract between the customer and GitHub, with the customer responsible for its End Users and their content. Neither the GCA nor the GHEC Product Specific Terms forbid the same person from also holding a separate personal GitHub account.

For customers who purchase GitHub Enterprise through a Microsoft agreement (EA, MCA, CSP), the GitHub GCA does not apply; the Microsoft Product Terms for GitHub Offerings do. Those public terms also do not forbid an EMU Licensed User from holding a personal GitHub account. Individual Order Form or Enterprise Agreement amendments can of course add their own constraints, so a final contract check through the company’s procurement or legal contact is still the safe move.

Microsoft Entra ID provisioning details to watch

The Microsoft Entra ID tutorial for EMU covers both the SAML and OIDC variants. Entra provisions users into GitHub EMU through SCIM: create, deactivate, attribute sync, group provisioning, and SSO. There is no flow that merges an existing personal GitHub account into an EMU account; the EMU account is a fresh managed user account.

About Enterprise Managed Users lists the constraints on the EMU side:

Profile name and email come from the IdP; the user cannot change them on GitHub.
The IdP can supply exactly one email address.
If the IdP changes the email, contribution history tied to the old address loses the link.
GitHub generates the username automatically by normalizing an identifier from the IdP. Per Username considerations for external authentication, on GitHub.com an underscore and the enterprise shortcode are appended, giving the shape IDP-USERNAME_SHORT-CODE (for example mona-cat_octo). This is a separate namespace from personal accounts, so there is no collision.

The email handling is the detail most worth knowing. EMU accounts created after August 1, 2024 no longer have their email auto-verified (documented on Email addresses reference). GitHub Docs “Email addresses” adds:

Once you verify an email with a managed user account, you won’t be able to use the email to sign up for a personal account on GitHub.com.

If the same address really needs to be on both accounts, the documented workaround is to unverify it on the EMU side. In practice, keeping a personal email on the personal account and the work email on the EMU account avoids the whole class of problems. No official document mandates that split; it is just the straightforward way to not collide with provisioning-driven attribute overwrites.

Workplace policy and network controls sit on top

Even if the ToS and the GCA allow the pattern, the employer’s information security policy, the configuration of company devices, and the corporate network can all restrict how it is used in practice. GitHub ships tooling for the employer to enforce those restrictions at the network layer.

Restricting access to GitHub.com using a corporate proxy adds a sec-GitHub-allowed-enterprise header at the corporate proxy so that only traffic from the organization’s EMU enterprise is accepted by github.com. The GitHub Changelog entry from 2025-09-15, “Enterprise access restrictions with corporate proxies is now generally available”, phrases it as “enterprise owners may allow only EMU enterprise traffic to github.com via their existing corporate proxies, while blocking any unapproved traffic.” The 2025-10-06 update “Enterprise access restrictions now supports multiple enterprises” lets the header carry “a comma-separated list of up to 20 valid EMU enterprise IDs.”

On a corporate network with that restriction turned on, personal-account traffic to github.com is blocked at the network layer. The ToS may permit the two accounts, but the employer’s policy is a separate layer that can and does override how the personal account is used on corporate devices or on the corporate network. Side-project and OSS contribution policies belong in the same review.

A practical checklist

Reorganized so that it reads cleanly through in a daily standup or a team meeting:

Confirm the personal side is exactly one account. Running a second personal free account “for work use” collides with ToS B.3 directly. Consolidate down to one personal account before worrying about the EMU side.
Check company policy and the Enterprise access restrictions config. Even under a permissive ToS reading, the workplace may restrict personal-account use on corporate devices or networks; moonlighting and OSS contribution policies belong in the same review.
Separate the email addresses. Personal email on the personal account, work email (Entra ID UPN or email attribute) on the EMU account. Configure per-repository user.email so EMU repositories use the work email and personal repositories use a personal or noreply address.
Separate SSH keys and PATs. The same SSH key cannot be attached to both accounts. Set up ~/.ssh/config with aliased hosts and insteadOf, use useHttpPath for HTTPS with per-account PATs, and lean on gh auth switch for the CLI.
Keep work code off the personal account. GitHub warns directly that “the complexity of regularly switching between accounts can increase the risk of mistakenly leaking internal code to the public.” Directory-scoped includeIf configuration and a habit of checking the remote before every push are the simplest defenses.
Understand the Copilot difference. EMU accounts cannot sign up for Copilot Pro or Free. Use the Copilot Business or Enterprise the employer allocates, and if you want personal Copilot, buy it on the personal account.

What is not spelled out, and how to get it in writing

The reading above rests on one unstated assumption. No official page says in so many words that “the ToS B.3 one-free-account clause does not apply to managed user accounts.” The conclusion is a coherent reading of three things taken together: that ToS B.3 limits free-tier accounts, that EMU accounts are enterprise-owned paid-license accounts, and that multiple GitHub Docs pages ship UI and configuration for the EMU-plus-personal pattern.

GitHub Community Discussion #78043 “Having two free accounts as an enterprise employee” (December 2023) had a moderator flag the question to the EMU PM, and a GitHub staff reply said that EMU plus a personal account is fine, while running two personal free accounts “is not in the spirit of our general terms.” The thread later continued with a secondhand report of a legal escalation and some pushback, so it is not an official legal position, but the distinction is consistent with how the ToS and the Docs read together.

For legal or audit purposes, the way to firm this up is to ask GitHub Enterprise Support or the company’s GitHub account manager for a written statement that EMU accounts are handled as managed user accounts under an Enterprise Subscription License and are not treated as a second free account for ToS B.3 purposes. That statement can then sit in the information security policy or the audit response for the rest of the contract term.

That’s all from a read of ToS B.3 against the EMU contract structure and the official documentation, landing on EMU plus one personal account as conditionally allowed, from the Gemba.

Search