When you need it
Developers work in GitHub with personal accounts the company does not own. When someone leaves, their account keeps access until someone remembers to remove it, code can end up in a public repository, and nobody can say who has access to what. Auditors ask for proof that access follows your identity provider, and you have none.
What sets the quote
- Foundation, 2–3 weeks: a new enterprise with managed users, one identity provider, up to 3 organisations and up to 500 users.
- Foundation + migration, 4–6 weeks: Foundation plus up to 200 repositories moved from GitHub.com, GitHub Enterprise Server, Azure DevOps or Bitbucket Server with GitHub Enterprise Importer.
- Identity providers: Microsoft Entra ID (OIDC with Conditional Access, or SAML), Okta or PingFederate (SAML), each with SCIM provisioning.
- Hosting: GitHub.com, or GHE.com with data residency in the EU region.
- Organisations, teams, repositories and rules are defined in YAML and applied with Terraform.
- Larger estates are quoted after the call.
What changes
- Every developer signs in with a company account that your identity provider creates, changes and removes, so leaving the company ends GitHub access too.
- Team membership and repository access follow groups in your identity provider, so access reviews happen in one place.
- Code cannot be made public or shared outside the enterprise by mistake, because managed accounts cannot create public content.
- Organisations, teams and rules change only through reviewed pull requests, and every change leaves an audit trail.
- With GHE.com, your enterprise is hosted in the EU region.
What you get
- A new enterprise with managed users on GitHub.com or GHE.com, with the setup account secured by two-factor authentication and its recovery codes stored with you
- Single sign-on and SCIM provisioning from your identity provider
- Teams linked to identity provider groups for organisation and repository access, and guest collaborator access for contractors
- Terraform with YAML definitions for organisations, teams, group links, repositories, rulesets and GitHub Actions policies, run from a pipeline that authenticates as a GitHub App, not a personal token
- Enterprise policies: repository visibility and forking, base permissions, personal access token rules, allowed actions pinned to full commit SHAs, runner groups, and secret push protection where you license it
- Audit log streaming to your SIEM or storage, for example Splunk, Datadog, Azure Event Hubs, Amazon S3 or Google Cloud Storage
- Foundation + migration: repositories, history and pull requests moved in tested waves with GitHub Enterprise Importer, and past contributions reattributed to the new accounts
- Runbooks for joiners, leavers, emergency access and an identity provider outage, and a handover session
Identity providers
| Identity provider | Sign-in | Provisioning | Access policies |
|---|---|---|---|
| Microsoft Entra ID | OIDC or SAML | SCIM | At sign-in; with OIDC, GitHub also checks the Conditional Access IP conditions on web, API and Git requests |
| Okta | SAML | SCIM | At sign-in, by Okta policies |
| PingFederate | SAML | SCIM | At sign-in, by PingFederate policies |
| Other SAML 2.0 and SCIM 2.0 systems | SAML | SCIM | At sign-in; assessed first, because GitHub’s support for them is limited |
One identity provider handles both sign-in and provisioning. GitHub does not support combining Okta and Entra ID for these.
Foundation suits a company that is starting on GitHub, or that wants developer access to follow its identity provider from day one. Foundation + migration suits teams moving from organisations of personal accounts, GitHub Enterprise Server, Azure DevOps or Bitbucket. It combines well with the secure CI/CD pipeline and keyless pipelines and secrets cleanup, and a DevSecOps gap check is often the first step.
Not included
- GitHub and identity provider licences, including GitHub Advanced Security products and Copilot
- Changes to personal GitHub accounts. They stay personal, and each developer gets a new managed account.
- Moving CI/CD pipelines from Jenkins, Azure Pipelines or GitLab CI to GitHub Actions (see secure CI/CD pipeline)
- Work items, boards and wikis from Azure DevOps or Jira
- Running the enterprise after handover (available as a care plan)
What we need from you
- An enterprise owner who can start the GitHub Enterprise Cloud trial or contract with managed users and set up billing.
- Identity provider admin rights, time-limited: in Entra ID, Application Administrator and someone who can grant admin consent; in Okta or PingFederate, an administrator for the GitHub app.
- The groups that should become teams, and an owner for each organisation.
- For migration: admin access to the source organisations or servers, and a repository owner to test each wave.
- A named approver for changes to enterprise policies.
How it works
Free 30-minute call, then a written fixed quote based on your users, organisations, repositories and migration source.
Design session: GitHub.com or GHE.com, the enterprise shortcode, sign-in method, organisation and team model, and policies.
Build as code with Terraform and YAML in your repository; you review every change as a pull request.
Pilot with one team, then onboard the rest in waves; with migration, repositories move in tested waves with a rollback plan.
Handover session, runbooks and decision records.
At a glance
- Duration
- 2–6 weeks
- Price
- Fixed quote after a free 30-minute call
- Delivered by
- Our lead architect
Related services
DevSecOps gap check
In 1–2 weeks, a check of how your teams build and ship software, scored against OWASP SAMM and NIST SSDF, ending in a gap list and a 90-day plan.
Pipeline security check
A one-week review of one CI/CD platform, from organisation settings to runners and secrets, with findings mapped to the OWASP Top 10 CI/CD Security Risks and SLSA.
Keyless pipelines and secrets cleanup
Your pipelines move from long-lived cloud keys to short-lived federated tokens, with secret scanning and dependency gates that stop new leaks and risky dependencies before merge.