BACK TO BLOGS Back to Press Releases

How to restrict GitHub Enterprise Cloud access to a specific IP address using Conditional Access

Written by:

GitHub Enterprise Cloud is a managed, cloud-based GitHub deployment option designed for large organizations. It includes advanced GitHub features such as SAML authentication, restriction of email notifications to verified domains, repositories, and managed user accounts.

It is also a target for attackers and is frequently accessed through compromised credentials or exposed tokens.  

To reduce these risks, you can restrict access to specific IP addresses using Conditional Access policies, ensuring only trusted users on trusted devices can sign in and access your repositories, code, and resources.  

In this article, we’ll provide a step-by-step guide on how to restrict access and maintain tighter control.

Why you should restrict GitHub Enterprise Cloud access by IP address

Restricting access based on IP address is an effective way to guard against credential theft and protect sensitive code.

Other benefits include:

  • Protect your source code and intellectual property
  • Prevent unauthorized access from unknown locations
  • Support compliance and regulatory requirements
  • Strengthen security posture alongside MFA, least privilege, and Zero Trust controls

Step-by-step: Restrict access to GitHub Enterprise Cloud to specific IP addresses

GitHub Enterprise Cloud has two distinct account models, and the correct IP restriction approach depends on which one your organization uses. Before proceeding, identify our enterprise type:

Standard Enterprise Cloud (personal accounts)

  • Authentication method: SAML SSO via Entra ID. Users retain personal GitHub accounts; SSO links them to your enterprise.
  • IP restriction approach: Follow this article. Use the GitHub Enterprise Cloud - Enterprise Account app in Entra ID.

Enterprise Managed Users (EMU) + OIDC

  • Authentication method: OIDC via Entra ID. Users are fully managed by Entra ID with no personal GitHub identity.
  • IP restriction approach: GitHub natively enforces Entra ID Conditional Access IP conditions. Configure Named Locations in Entra ID — no separate CA policy is required.

Enterprise Managed Users (EMU) + SAML

  • Authentication method: SAML SSO via Entra ID. Users are fully managed by Entra ID.
  • IP restriction approach: Follow this article. Use the GitHub Enterprise Managed User app in Entra ID instead of the Enterprise Account app.

To confirm which type your enterprise uses, sign in to GitHub and check the header bar at the top of your enterprise view. If it reads "Users managed by [your organization name]", you are using Enterprise Managed Users. If it shows standard organization navigation, you are using standard Enterprise Cloud with personal accounts.

NOTE: This article covers Standard Enterprise Cloud (SAML) and EMU + SAML. If your organization uses EMU with OIDC, you do not need to follow this guide—simply configure your IP-based Named Locations in Entra ID and GitHub will enforce them natively through its Conditional Access Policy (CAP) support.

Prerequisites

Before proceeding, confirm the following are in place:

  • Microsoft Entra ID P1 or P2 license — required for Conditional Access.
  • Conditional Access Administrator role or higher in Microsoft Entra ID.
  • GitHub Enterprise Cloud plan — SSO is not available on Free or Team plans. Enterprise Cloud is required.
  • must be registered in your Entra ID tenant with SSO active at the enterprise account  level.  
  • SAML SSO configured and enforced — the appropriate GitHub enterprise app  
  • Security Defaults disabled — Security Defaults and Conditional Access cannot run simultaneously.
  • Known static IP address — the public IP address or CIDR range of each approved location.
  • Break-glass admin account — must be excluded from this policy to prevent administrative lockout.

IMPORTANT: GitHub Enterprise Cloud SAML SSO does not replace GitHub's own sign-in. Members still authenticate with personal GitHub accounts and are redirected to Entra ID for SAML when accessing organization resources. This means the CA policy blocks SSO-based access from untrusted IPs, but personal access tokens (PATs) and SSH keys authorized for SSO may still allow some access. For full enforcement, configure GitHub's native IP allow list alongside this policy.

Step 1: Create a Named Location for your trusted IP(s)

A Named Location defines the trusted IP addresses that Entra ID will reference as a condition in the policy.

  1. Sign in to the Microsoft Entra admin center at entra.microsoft.com.
  2. Navigate to Protection > Conditional Access > Named locations.
  3. Select + IP ranges location.
  4. Name the location — for example: Trusted - Corporate Office
  5. Check the Mark as trusted location checkbox.
  6. Click + and enter your approved IP address or CIDR range. Examples:
    • Single IP address: 203.0.113.10/32
    • IP range (CIDR): 203.0.113.0/24
    • Multiple sites: Create a separate Named Location for each site, then reference all of them in the policy.
  7. Click Create.

Step 2: Create the conditional access policy

Create a policy that blocks GitHub Enterprise Cloud access from any location not on your trusted list.

  1. In the Entra admin center, navigate to Protection > Conditional Access > Policies.
  2. Select + New policy.
  3. Name the policy — for example: Block GitHub Enterprise Cloud - Outside Trusted IPs

Assignments: Users

  1. Under Assignments > Users, select All users.
  2. Under Exclude, add your break-glass admin account and any automation or service accounts that authenticate from dynamic IPs.

Assignments: Target resources

  1. Under Target Resources, select Cloud apps > Select apps.
  2. Select the app that matches your enterprise setup:
    • Standard Enterprise Cloud: Select GitHub Enterprise Cloud - Enterprise Account
    • EMU + SAML: Select GitHub Enterprise Managed User

NOTE: If SSO was previously configured at the organization level rather than the enterprise account level, select GitHub Enterprise Cloud - Organization instead. Organization-level SSO means each organization in your enterprise has a separate app registration — you may need a separate policy per organization or migrate to enterprise-level SSO for centralized management.

Conditions: Locations

  1. Under Conditions > Locations, set Configure to Yes.
  2. Under Include, select Any location.
  3. Under Exclude, select Selected locations, then choose your Named Location from Step 1.

TIP: This configuration reads: apply this policy to sign-ins from any location, except the trusted named location. Any GitHub Enterprise Cloud sign-in originating outside the trusted IP will be blocked before Entra ID issues a SAML assertion to GitHub.

Access controls: Grant

  1. Under Access Controls > Grant, select Block access.
  2. Click Select to confirm.

Enable Policy

  1. Set Enable policy to Report-only.
  2. Click Create.

IMPORTANT: Do not set this policy to On immediately. A block policy applied to All users that is misconfigured will prevent all users from authenticating to GitHub Enterprise Cloud. Always validate in Report-only mode first.

Step 3: Validate the policy

Before enabling enforcement, confirm the policy is evaluating sign-ins correctly.

  1. In the Entra admin center, navigate to Identity > Monitoring & health > Sign-in logs.
  2. Filter by the GitHub Enterprise Cloud application.
  3. Open a sign-in from a user on your trusted IP and confirm the Conditional Access tab shows Would succeed.
  4. If available, review a sign-in from an untrusted IP and confirm it shows Would fail with the location condition listed as the reason.
  5. Investigate any unexpected Would fail entries this typically indicates the network is presenting a different egress IP than what is entered in the Named Location.

TIP: Use the What If tool under Protection > Conditional Access to simulate how a specific user signing in from a specific IP would be evaluated without waiting for a real sign-in event.

Step 4: Enable the policy

  1. In the Entra admin center, navigate to Protection > Conditional Access > Policies.
  2. Select the policy created in Step 2.
  3. Change Enable policy from Report-only to On.
  4. Click Save.

From this point forward, any GitHub Enterprise Cloud sign-in attempt from an IP address not included in your Named Location will be blocked. Entra ID will not issue a SAML assertion to GitHub, and the user will be denied access to enterprise resources.

NOTE: For complete IP enforcement, also configure GitHub's native IP allow list under your enterprise or organization settings. This covers access methods that do not go through Entra ID SSO, such as personal access tokens and SSH keys. Navigate to GitHub > Enterprise Settings > Security > IP allow list to enable this.

Summary

The following summarizes the full configuration process:

Prerequisites

  • Confirm enterprise type, license, SAML SSO enforced, Security
  • Defaults disabled, static IP(s) identified

Step 1

  • Create a Named Location with your trusted IP address(es) in Entra ID

Step 2

  • Create a CA policy targeting the correct GitHub Enterprise Cloud app, excluding the Named Location, with Block access

Step 3

  • Validate in Report-only mode using sign-in logs and the What If tool

Step 4

  • Switch Enable policy to On and configure GitHub native IP allow list for full coverage

FAQs

Can GitHub Enterprise Cloud restrict access by IP natively?

Yes, GitHub Enterprise Cloud offers IP restrictions. However, enforcing access restrictions through an identity provider using Conditional Access offers centralized control.

What happens if a user attempts to log in from an unapproved IP address?

Access will be blocked based on the configured policy if the request originates from an unapproved IP address.

Is restricting GitHub access by IP address enough?

No. While it significantly reduces risk, it should still be combined with additional security controls like MFA, least privilege, and Zero Trust enforcement.

Can attackers bypass IP-based restrictions?

Attackers may attempt to use compromised VPNs or proxy services, which is why IP-based restrictions need to be layered with additional Zero Trust controls.

No items found.

Start your path to stronger defenses

Start your trial

Try ThreatLocker free for 30 days and experience full Zero Trust protection in your own environment.

Book a demo

Schedule a customized demo and explore how ThreatLocker aligns with your security goals.

Ask an expert

Just starting to explore our platform? Find out what ThreatLocker is, how it works, and how it’s different.