Choose a GitHub Enterprise Cloud user access model
GitHub Enterprise Cloud (GHEC) supports two distinct user access models: Both give you access to the same great features and ease of hosting, but each is designed to facilitate different types of workflows and security guardrails.
You’ll need to select the one that best fits your business needs during your initial enterprise account creation, so it’s important to understand both. As we’ll soon see, each model uses a different type of user account that isn’t mutually interchangeable. Switching from one to the other later is not simple and requires both migration tools and an additional process to migrate user history.
We want to make your adoption process with GHEC seamless, so let’s explore the pros and cons of each access model to help you choose the right one for your needs from the beginning. Along the way, we’ll hear what tipped the scales toward standard users for Philips, and why Travelport went with EMUs instead.
In this guide, you will learn:
The two types of user models available in GHEC: Enterprise Managed Users (EMU) and standard
The tradeoffs of using each model
Guidance for selecting the model that best fits your business requirements
The standard GHEC model, or “Bring your own account”
The standard model emphasizes connection with the public, open source parts of GitHub.com. As the name suggests, users bring their own personal accounts to work in much the same way they might use their personal phone, laptop, or other device. They own the account and it follows them as they join, contribute, and leave organizations and participate in the GitHub community, not just during their employment at a company or work on a certain project.
Enterprises and their organizations then link these accounts and use SAML identities to authenticate access to their private resources. Then, with a supported identity provider (IdP) and GitHub configuration, you can use System for Cross-domain Identity Management (SCIM) to further use linked workplace identity associations to grant or terminate access to those protected resources automatically.
The standard model also allows you to add external users as outside collaborators to specific repositories with certain permissions for only those repositories. These external users who use their personal GitHub accounts are exempted from any SAML authentication requirements imposed on normal members.
There are also some tradeoffs when using the standard model. Enterprises cannot enforce or standardize account-related requirements, like mandating username formats, emails, or display names. In other words, instead of a common corporate format for usernames, employees will use whatever GitHub username they choose for themselves, possibly many years before they joined your organization. The enterprise can only control policy-related behavior for their member and collaborator users in this model, and even then, only the behavior that occurs within the context of the enterprise account and its organizations. What the user does in the context of their own account or other non-enterprise organizations and repositories is not subject to the enterprise’s controls.
The standard model also permits both private and public repositories to be hosted within the same enterprise organization, unless explicitly disabled by policy. This flexibility can be key for open source participation, but some companies choose to disallow their users from hosting public repositories to keep a more clear boundary between private and public.
The standard model may be a good fit if you meet some or all of these criteria:
You require developers to interface seamlessly with GitHub’s public and open source communities as part of their day-to-day work.
You need to easily add outside collaborators to their repositories without being subject to SAML authentication requirements or needing to be part of a centralized IdP directory.
You make heavy use of public repositories or similar features, like GitHub Gists, or public Pages and Discussions.
We chose to use GitHub Enterprise standard users because we wanted to make external collaboration as easy as possible. We had considered using EMUs, but open source is also important to us, and our developers would need to use separate accounts for their open source activities.
The Enterprise Managed User (EMU) model
The enterprise managed user (EMU) model prioritizes centralized enterprise control of a standardized work account from a corporate IdP. The EMU model uses company-owned, work-only GitHub accounts that operate exclusively within the confines of an enterprise account.
When a user joins your company and is given GHEC access, they get an EMU work account that only operates and is visible in your company’s enterprise account. When they leave your company or otherwise lose their GHEC access, that EMU work account is also suspended. The full lifecycle of these accounts, including authentication and provisioning, is managed by a supported IdP, such as Microsoft Entra ID (formerly Azure Active Directory or Azure AD), Okta, or PingFederate. The enterprise can standardize EMU account information, including username formatting, email addresses, and display names, which supports improved transparency and reporting. With the strict IdP account backing requirement for work accounts, outside collaborators cannot be invited in the same way as with the standard user model. All users, even guests, need to be brought in using IdP directory provisioning.
Beyond providing more standardization, the EMU model also adds guardrails against making private content publicly visible, such as accidentally pushing to public GitHub.com repositories. Not only do EMU enterprises prevent public repository creation, but EMU users cannot perform write-type actions such as pushing, starring, or creating issues or pull requests in repositories outside of their enterprise account. EMU users have full read access to view and clone GitHub.com’s public repositories, however. While EMU accounts cannot be used for open source write-type activities, the tradeoff of these additional guardrails is a more stringent divide between enterprise and open source.
The EMU model may be a good fit if you meet some or all of these criteria:
Your security requirements prioritize a separation between the public GitHub.com community and your enterprise content over a connection to open source.
The EMU model supports your IdP (Microsoft Entra ID, Okta, PingFederate) and you want to centrally standardize and manage your users’ GitHub accounts as specialized work accounts only for use in the enterprise context.
You don’t require (or want) collaborators outside your IdP to be able to be added directly to specific repositories, and will instead provision these users as normal or guest accounts in their IdP directory.
You don’t require public repositories or other public-facing features, like GitHub Gists, or public Pages or Discussions.
If your developers will be regularly building and maintaining open source code as a part of their daily work, the standard user model may be best. However, if you need full control of your developers’ accounts and a firm separation between the open source community and your company’s code, EMUs will be a better user model fit.
We went private a few years ago, and cyberattacks on our platform rocketed from 1.6 billion per quarter to nearly 200 billion once we began marketing our innovations for travel, so security was a big driver for us to choose the EMU user model.
We wanted to shift security left, and we chose GHEC with EMUs, because it lets us sync with Microsoft Entra ID to automate onboarding, offboarding, and permissions across our 1,600 users. Those users aren’t just developers, they’re operations teams and other people who need access, and the ability to manage all of that directly from our identity management provider was crucial. We have more than 8,000 repositories across more than 60 organizations, so we use 260 teams to provide the fine-grained permissions needed to promote innersource while also meeting our strict security requirements.
Up next: Strategies for using organizations in GitHub Enterprise Cloud
In the first step of this learning pathway, we learned all about the structural components of GHEC and made the simple recommendation that you limit yourself to a single organization to reduce administrative overhead, but we understand that this isn’t a one-size-fits-all scenario. For large enterprises and companies with certain business requirements, a multiple organization set-up can be necessary. In the next step, we’ll explore the considerations involved and lay out a few strategies for using multiple organizations within your enterprise account.