Instiq
Chapter 1 · Manage GitHub Identities and Access·v1.0.0·Updated 6/14/2026·~16 min

What's changed: New GH-100 Chapter 1 (user identities & auth = managed users (EMU) vs personal accounts, SAML SSO/2FA, SCIM and team sync, identity providers, auth model; access & permissions = org/repo roles [Read/Triage/Write/Maintain/Admin/custom], enterprise teams and nested inheritance, team-based least privilege, access auditing and audit log, policies and ruleset enforcement)

1.1User Identities and Authentication

Key points

Understand the difference between managed users and personal accounts, configuring/enforcing SAML SSO and 2FA, SCIM and team synchronization (implementation and differences), choosing/configuring identity providers, and GitHub’s authentication/authorization model.

For a GitHub Enterprise admin, the first duty is governing "who logs in, how, and what they can access." GH-100 first covers identity types and authentication. The key fork is between managed users (EMU), fully controlled by the company’s identity provider (IdP), and inviting members’ own personal accounts into the org.

1.1.1Managed users vs personal accounts

A personal account is a GitHub account the user creates and owns, invited into the org (the normal GitHub.com model). With Enterprise Managed Users (EMU), user accounts are centrally provisioned and managed by the company IdP, and users sign in only via the IdP. EMU accounts are under company control, isolated from external public activity, and revoking them in the IdP at offboarding immediately cuts access. The essence is "bring your own account (personal)" vs "use a company-issued account (EMU)."

1.1.2SAML SSO and 2FA

Configuring SAML SSO (single sign-on) makes org/enterprise members authenticate at the IdP (Entra ID, Okta, etc.) before accessing GitHub, applying corporate auth policies (e.g., conditional access) and cutting departed users’ access centrally. Two-factor authentication (2FA) requires a second factor beyond a password and can be enforced org-wide (when enforced, members without it are restricted until they set it up). SAML SSO and 2FA are baseline defenses against impersonation and credential leaks.

1.1.3SCIM and team synchronization

While authentication (SAML SSO) handles "login," SCIM handles account provisioning/deprovisioning (syncing IdP create/update/delete to GitHub). With SCIM, a user disabled in the IdP is automatically removed from GitHub, preventing leftover access at offboarding. Team synchronization maps IdP groups to GitHub team membership, auto-reflecting group changes into teams. Summarize: "SAML = authentication," "SCIM = automated account management," "team sync = group→team auto-reflection."

MechanismRole
SAML SSOAuthentication (login via IdP)
2FAMulti-factor to prevent impersonation
SCIMAuto provisioning/deprovisioning of accounts
Team syncIdP groups → GitHub teams
EMUCompany-fully-managed users
Exam point

Common: (1) Personal accounts (invited, user-owned) vs EMU (fully managed by the company IdP, login only via IdP). (2) SAML SSO = authentication (login via IdP); 2FA = multi-factor (enforceable). (3) SCIM = automated account provisioning/deprovisioning (auto-removal at offboarding); team sync = IdP groups → GitHub teams. SAML/SCIM/team sync have distinct roles.

Warning

Watch out: (1) SAML SSO (authentication) and SCIM (provisioning) differ—SAML alone doesn’t auto-remove accounts (use SCIM for offboarding). (2) EMU and personal accounts are different models—EMU environments don’t directly admit personal accounts. (3) 2FA "enforcement" rolls out gradually; non-compliant members are restricted. (4) Team sync is IdP-group-driven—it can conflict with manually added GitHub members.

Diagram of EMU/personal, SAML SSO, SCIM, and team sync/2FA.
SAML=auth, SCIM=account mgmt

1.1.4Section summary

  • Personal accounts (invited, user-owned) vs EMU (fully company-managed, IdP-only login)
  • SAML SSO = authentication; 2FA = multi-factor (enforceable)
  • SCIM = auto provisioning/deprovisioning; team sync = IdP groups → GitHub teams
  • SAML alone doesn’t auto-remove—use SCIM for offboarding

Sign in to track progress — Log in.

Quick check

(just a quick review)

Q1. In which GitHub model does the company fully manage user accounts via an IdP, and users log in only via the IdP?

Q2. You want users disabled in the IdP to be auto-removed from GitHub to prevent leftover access at offboarding. What do you configure?

Q3. Which correctly distinguishes the roles of SAML SSO and SCIM?

Q4. You want IdP group changes auto-reflected into GitHub team membership. What do you use?

Q5. To strengthen org security, you want to require a second authentication factor beyond passwords. What do you enforce?

Q6. Which correctly distinguishes personal accounts from EMU?

Check your understandingPractice questions for Chapter 1: Manage GitHub Identities and Access