Many organisations want to adopt GitHub Copilot but face a common set of constraints: source code is hosted on Azure DevOps (or another non-GitHub repo), SSO is a requirement, and data residency requirements must be met. This post documents how all three can be addressed — delivering GitHub Copilot without migrating repositories or compromising on compliance.

What this post covers:

  • How to set up GitHub Enterprise solely as a licensing layer, not a code host
  • How to configure OIDC-based SSO between GitHub Enterprise and Microsoft Entra ID
  • How SCIM provisioning automates account lifecycle management
  • Step-by-step IDE setup for Visual Studio and VS Code
  • Important pitfalls around licensing, costs, and cloud agent limitations

The Requirements

The following are requirements that are frequently encountered among organizations considering the adoption of AI-assisted coding:

  1. AI coding assistance directly in the IDE and CLI — developers should have Copilot available in Visual Studio, VS Code, and via the command line without additional tooling.
  2. No disruption to existing workflows — source code remains on existing GitRepos (such as Azure DevOps). Developers should not need to adopt a new platform or change their day-to-day processes.
  3. EU data residency — all organisational data including inference processing and metadata must be stored and processed within the European Union, in line with internal compliance policies.
  4. Single sign-on with existing credentials — developers authenticate with their corporate Entra ID accounts. No separate GitHub passwords, no additional accounts for IT to manage.
  5. Enterprise controls and usage visibility — administrators need the ability to control which AI models are available, configure content exclusion policies, and monitor usage across teams to understand adoption and cost.

The Architecture: GitHub Enterprise as a Copilot Delivery Layer

The solution is to provision a GitHub Enterprise (GHE) instance with a focused purpose: serve as the identity and licensing layer for Copilot, without hosting any source code.

GitHub Enterprise can be configured with EU data residency from the outset, satisfying the compliance requirement. Developers authenticate using their existing corporate credentials via OIDC-based Single Sign-On (SSO) connected to Microsoft Entra ID — no new accounts or passwords required.

This approach satisfies all five requirements: Copilot is delivered through the IDE and CLI, Azure DevOps remains the code host, data stays in the EU, authentication uses existing credentials, and enterprise administrators retain full control over policies and usage.

Keeping AI Within Your Region: GitHub Copilot Data Residency

Reference: GitHub Copilot with data residency

When enabled, a GitHub Copilot policy ensures that all Copilot inference processing — your code, prompts, and responses — stays within a designated geographic region. Currently, the supported regions are the United States and the European Union, with more planned.

How Enforcement Works

The controls help ensure that Copilot data remains within the selected region:

Authentication and routing — Users connect only to services in their assigned region. Model availability — Only approved AI models for that region are available. Logs and telemetry — Logs and telemetry are stored within the same region.

All generally available Copilot features continue to work under this enforcement. However, certain preview features may not be available.

Enabling the Policy

The policy is called “Restrict Copilot to data residency compliant models” and is found in the Features section of your enterprise’s Copilot policies. It is off by default and must be explicitly enabled.

One consideration: requests processed under this enforcement carry a 10% premium request multiplier, reflecting the additional infrastructure costs of regional and compliance-certified endpoints.

Developers also need to be running a recent version of the Copilot extension or CLI — generally anything from 2025 onwards. Older clients will prompt users to update before they can continue using Copilot.

Configuration Steps

Step 1: OIDC SSO — Entra ID as the Identity Provider

Reference: Configuring OIDC for Enterprise Managed Users

The foundation of this setup is OpenID Connect (OIDC) between GitHub Enterprise and Microsoft Entra ID. GitHub does not manage passwords or user lifecycles — Entra ID remains the single source of truth.

From the GitHub Enterprise admin console, enabling OIDC redirects to the Entra ID app gallery to install the GitHub Enterprise Managed User (OIDC) enterprise application. Global administrator consent is required during this step.

Important: Immediately after completing the SSO configuration, download and securely store the recovery codes. These are the only mechanism to regain access to the enterprise console if the identity provider is unavailable. They should be treated with the same care as any other break-glass credential.

Step 2: SCIM Provisioning — Automated Account Lifecycle Management

Reference: Configuring SCIM provisioning for users

SSO handles authentication, but SCIM provisioning is required to manage authorisation — ensuring the correct users exist in GitHub Enterprise with the appropriate access.

Generate a SCIM token from the GitHub Enterprise console, then configure the Entra ID provisioning service to sync users and groups automatically. With the provisioning mode set to Automatic:

  • Users added to a designated Entra ID group receive a GitHub managed account automatically.
  • Users removed from the group or deprovisioned in Entra have their GitHub account deactivated.
  • No manual account management is required.

Configure failure notifications so that provisioning errors surface promptly rather than accumulating silently.

Developer Setup

Once the infrastructure is in place, onboarding a developer is straightforward.

Visual Studio

Visual Studio does not show GitHub Enterprise accounts by default. The following steps are required:

  1. Enable Enterprise accounts: Tools → Options → Environment → Accounts → check “Include GitHub Enterprise Cloud and GitHub Enterprise Server accounts.”
  2. Add the account: File → Account Settings → Add → GitHub → GitHub Enterprise → enter your organisation’s GHE URL and complete the browser-based sign-in.
  3. Verify: Click the Copilot icon → Copilot Usage — the correct plan should be confirmed.

Premium models (that are enabled in GitHub AI Controls) such as Claude Sonnet and Opus are available immediately in the Copilot Chat panel.

Note: Visual Studio 2026 is recommended where your solution supports it.

VS Code

  1. Consider signing out of any existing GitHub accounts in VS Code if these are not required.
  2. Click the GitHub Copilot icon in the status bar → Sign in to use AI Features.
  3. Select Continue with GHE.com, enter your organisation’s GHE slug, and complete the browser-based sign-in.
  4. Authorise the github-enterprise application when prompted.

Confirming Access

Developers can verify their Copilot entitlement by signing in to their organisation’s GitHub Enterprise portal and navigating to /copilot to confirm the subscription is active before using the IDE.

Pitfalls to Be Aware Of

This architecture works well, but there are several important considerations that may influence your decisions.

Creating an Organisation Requires Purchasing GitHub Enterprise User Licenses

Setting up GitHub Enterprise with managed users and SSO requires purchasing GitHub Enterprise user licenses — this is separate from the Copilot subscription itself. Each provisioned user consumes an Enterprise seat, even if GitHub is only being used as the Copilot access layer. Factor this into your cost planning.

Cloud-Based Coding Agents Require Code on GitHub

If you intend to use GitHub Copilot’s cloud-based coding agents (which can work autonomously on issues, pull requests, and code changes), be aware that these agents only operate on repositories hosted on GitHub. If your source code remains on Azure DevOps, cloud agents will not be available. This is an important consideration for organisations evaluating the full Copilot feature set.

GitHub Enterprise Pricing Has Long-Term Implications

Once you commit to GitHub Enterprise for SSO and Copilot licensing, moving your repositories to GitHub later means paying Enterprise-tier pricing for both hosting and Copilot — which is significantly more expensive than GitHub Team pricing. If you anticipate eventually needing cloud agents and want to keep costs lower, consider whether GitHub Team (without SSO) paired with repositories hosted on GitHub might be a more cost-effective long-term path. The trade-off is losing SSO and managed user capabilities (together with some other enterprise features).

Understand the GitHub Copilot Licensing Tiers

GitHub Copilot is available in Business and Enterprise tiers. The primary difference is the number of premium model requests (which is changing to AI credits in June 2026) included per developer per month.

Summary

This architecture demonstrates that GitHub Copilot can be adopted by organisations on Azure DevOps, with existing Entra ID infrastructure, and with EU data residency requirements — without migrating a single repository. The key components are:

  • GitHub Enterprise configured with EU data residency, used solely as the Copilot access layer
  • OIDC SSO connecting GitHub Enterprise to Microsoft Entra ID
  • SCIM provisioning for automated, group-based account management

Before committing to this approach, evaluate the pitfalls above — particularly around cloud agent limitations and the long-term pricing implications of the Enterprise tier. For many organisations, this architecture is the right balance of speed, compliance, and pragmatism.

If your organisation is in a similar position, this pattern provides a practical path to delivering AI coding assistance without rearchitecting your development platform.

A Note on Billing Changes

GitHub Copilot’s billing model is changing. From 1 June 2026, Copilot is moving to usage-based billing with GitHub AI Credits. Under the new model, features like Copilot Chat, the CLI, cloud agents, and Copilot Spaces consume AI credits, while code completions and next edit suggestions remain unlimited on all paid plans. Frontier models will consume more credits per interaction than lighter models, so model choice will have a more direct impact on cost.

The architectural approach in this post — GitHub Enterprise as a licensing and identity layer, with SSO and SCIM — should remain valid under the new billing model. What will change is how you think about and track consumption per developer.

GitHub provides tooling to help you prepare: you can preview your estimated bill under the new model from the premium request analytics page, and download a detailed usage report to understand the breakdown before the transition takes effect.

Disclaimer

Licensing, pricing, and enterprise configuration details in this post reflect the state of GitHub Copilot as of the time of writing. Both the product and its billing model are evolving — particularly with the move to usage-based billing in June 2026 — so some specifics may have changed by the time you read this.

This post is intended as a practical guide based on real-world experience, not official documentation. Before making architectural or commercial decisions, always validate the current licensing terms, tier comparisons, and enterprise requirements. Your own organisation’s compliance/procurement/legal teams should be involved in such enterprise rollouts.