Restrict GitHub access to a specific IP address using Conditional Access

This article provides step-by-step guidance on restricting access to GitHub Enterprise based on trusted IP addresses using Microsoft Entra ID Conditional Access.  

By enforcing location-based access controls, organizations can ensure that only users connecting from approved networks—such as corporate offices or secure VPNs—are able to authenticate and interact with repositories. This adds an important layer of security on top of existing authentication methods.

Why restricting GitHub access is important

Restricting GitHub access by IP address is a critical security control for organizations that manage sensitive source code and intellectual property.

Key benefits include:

• Reduced risk of unauthorized access
  Prevent sign-ins from untrusted or unknown networks, limiting exposure to compromised credentials.
• Protection against code exfiltration
  Ensure repositories are only accessible from controlled environments, such as corporate networks.
• Enforcement of Zero Trust principles
  Combine identity and location-based controls to strengthen access policies.
• Improved compliance posture
  Many security frameworks require restricting access to sensitive systems based on network location.
• Minimized attack surface
  Even if credentials are leaked, attackers cannot authenticate from outside approved IP ranges.
  ‍

As noted in the document, this approach ensures GitHub is only accessible from trusted locations, significantly reducing the likelihood of unauthorized repository access or data leakage.

Step-by-step: Restrict GitHub access to a specific IP address using Conditional Access

The approach uses two components working together:

• Named Locations — a saved list of trusted IP addresses or CIDR ranges defined in Entra ID.
• Conditional Access policy — a policy that blocks GitHub Enterprise sign-ins originating from any IP not on the trusted list.

SAML vs OIDC: Choose the right approach first
GitHub Enterprise supports two authentication methods with Entra ID, and the correct IP restriction approach depends on which one your organization uses. Confirm your setup before proceeding.

This article covers the SAML SSO path. If your organization uses Enterprise Managed Users (EMU) with OIDC, GitHub will automatically enforce Entra ID Conditional Access IP conditions natively. Follow the OIDC configuration in GitHub's documentation and configure your IP-based Named Locations in Entra ID, and no additional CA policy is required.

NOTE: This configuration requires GitHub Enterprise Cloud to be integrated with Microsoft Entra ID via SAML SSO at either the organization or enterprise account level. If SSO is not yet configured, complete that setup first before proceeding. Refer to the GitHub Enterprise SSO KB article for setup instructions.

IMPORTANT: GitHub SAML SSO does not replace GitHub's own authentication. Members continue to sign in to their personal GitHub accounts and are redirected to Entra ID for SAML authentication when accessing organization resources. This means that while the CA policy blocks SSO authentication from untrusted IPs, users with a cached GitHub session or personal access tokens (PATs) authorized outside of SSO may still be able to access some resources. For full enforcement, also configure IP allow lists in GitHub at the organization or enterprise level.

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 enterprise app (SAML SSO) registered in your Entra ID tenant with SSO enforced at the organization or enterprise account level.
• 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: If your approved IP address is dynamic, this approach will not work reliably. You must use a static IP before implementing IP-based Conditional Access.

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:

7. Click Create.

Step 2: Create the Conditional Access policy

Create a policy that blocks GitHub Enterprise 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 - Outside Trusted IPs

Assignments: Users

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

Assignments: Target Resources

1. Under Target Resources, select Cloud apps > Select apps.
2. Search for and select GitHub Enterprise Cloud - Organization or GitHub Enterprise Cloud - Enterprise Account, depending on how your SSO is configured.

NOTE: If your SSO is configured at the organization level, select GitHub Enterprise Cloud - Organization. If SSO is configured at the enterprise account level to cover all organizations, select GitHub Enterprise Cloud - Enterprise Account. Target the app that matches your existing SSO enterprise application.  

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 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 block all users from authenticating to GitHub Enterprise instantly. 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 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 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 organization resources.

NOTE: This policy blocks SAML-based authentication from untrusted IPs. For complete coverage, also configure GitHub's native IP allow list at the organization or enterprise level to block personal access tokens and other non-SSO access methods from untrusted IPs. This setting is available in GitHub under Organization Settings > Security > IP allow list.

Summary

The following summarizes the full configuration process:

Prerequisites

Confirm license, GitHub Enterprise SAML SSO configured, 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 GitHub Enterprise Cloud, 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

Does this block all access to GitHub from untrusted IPs?
‍It blocks SAML-based authentication through Entra ID. However, users with existing sessions or personal access tokens (PATs) may still access some resources unless GitHub’s native IP allowlist is also configured.

What happens if we use OIDC instead of SAML?
‍If you're using GitHub Enterprise Managed Users (EMU) with OIDC, GitHub automatically enforces Entra ID Conditional Access policies. You do not need to create a separate Conditional Access policy.

Can this work with dynamic IP addresses?
‍No. This configuration requires static IP addresses. Dynamic IPs will cause inconsistent enforcement and are not supported.

What is a Named Location?
‍A Named Location is a defined list of trusted IP addresses or ranges in Microsoft Entra ID. It is used as a condition within Conditional Access policies.

Why should I use Report-only mode first?
‍Report-only mode allows you to validate how the policy will behave without actually blocking users. This helps prevent accidental lockouts due to misconfiguration.

Do I need to exclude any accounts?
‍Yes. Always exclude a break-glass (emergency) admin account and any service accounts that may authenticate from dynamic or external IPs to avoid lockouts.

Will this affect existing GitHub sessions?
Not immediately. Existing sessions may persist until reauthentication is required. Enforcement occurs during new authentication attempts.

Is restricting access by IP address enough on its own for full protection?
‍No. For complete coverage, you should also configure GitHub’s native IP allow list to block non-SSO access methods like PATs from untrusted IPs.