Not just flightless birds: How EMUs secure and scale identity and access management for your GitHub Enterprise

From consumer tool to managed enterprise platform

GitHub started in 2008 as a fast way for developers to share code publicly. As organizations adopted the platform, they asked for what any business would want: identity provider integration, cleaner separation between company and personal content, and enterprise-grade controls. GitHub Enterprise launched over a decade ago to answer that call.

Today GitHub Enterprise Cloud (GHEC) serves more than 90 million developers. Enterprise owners are responsible for identity and data isolation, and security, observability, and compliance are central concerns. The default GHEC model has long let developers use their single personal GitHub.com account everywhere—for open source, personal projects, and work, with SAML linking when an administrator sets it up. That “bring your own account” approach gives developers a seamless transition between contexts, and it gives owners a way to organize users. But it also leaves administrators with a harder job: tracking exactly who their users are, while corporate security teams push for guardrails against accidental exposure of private content.

What Enterprise Managed Users change

In 2021, GHEC introduced the Enterprise Managed Users (EMU) model to address those needs. With EMU, the enterprise provisions standardized accounts for its users directly from the identity provider. Usernames, display names, and email addresses are set by the IdP, making it the single source of truth for user access and account management. Administrators can also scale access and role management by linking IdP groups to GitHub teams.

The guardrails go further. EMU users cannot create public repositories, write content outside the enterprise, or collaborate with other users and enterprises on GitHub while logged into their managed account. They contribute only to the enterprise’s own organizations and repositories, which enforces separation between work and personal/open-source activity. That extra boundary addresses a common security concern: preventing sensitive internal code from leaking into public parts of GitHub.com.

Is the EMU model right for you?

The EMU model is worth considering if your organization has any of these needs:

• You want the identity provider to be the single source of truth for managing GitHub user access.
• You want full end-to-end ownership of the accounts your users use in your enterprise.
• You want IdP-synced display names and email addresses, with usernames standardized to an enterprise attribute.
• You need stricter separation between the GitHub accounts users use at work and for personal/open-source projects.
• You need additional guardrails and policies to prevent accidental leaks of sensitive content into publicly visible areas of GitHub.com.

The “bring your own account” model remains the right fit for many GHEC customers, particularly teams whose developers regularly contribute to open source at work and require write access to public parts of GitHub.com.

Keep in mind that moving existing GitHub usage of any implementation or plan type to the EMU model requires a migration process. Full details on EMU capabilities and restrictions are covered in the documentation.

Ultimately, the EMU model simplifies user management in an enterprise context and gives both administrators and end users more confidence, with better security and clearer separation between work and personal accounts. If you think it could fit your organization, the next step is to talk to your GitHub account team.