Before touching GitHub’s settings screens, it helps to understand the underlying idea in plain terms.

Every device connected to the internet — your laptop, your office network’s router, a cloud server running a build job — is reachable through an IP address, a numeric label a bit like a postal address for data. When your browser or your Git client talks to GitHub, that conversation carries your IP address along with it, whether you think about it or not.

You may likeWhat Is Git Bisect?→

An IP allow list (sometimes called an IP allowlist, and in older material an “IP whitelist”) is a rule set that GitHub checks before it lets a request into an organization’s private resources. GitHub maintains a list of specific IP addresses or ranges that are permitted. If the IP address a request is coming from is not on that list, GitHub refuses the request — even if the username and password, personal access token, or SSH key are completely valid.

This is important to say clearly: an IP allow list is not a replacement for authentication, passwords, SSO, or two-factor authentication. It is an additional, independent layer that narrows down where valid credentials are allowed to be used from, regardless of how strong those credentials are.

Understanding the threat an allow list is designed to reduce makes the rest of the feature far easier to reason about.

Passwords leak. Tokens get pasted into the wrong chat window. A developer’s laptop gets stolen from a coffee shop. Phishing tricks people into typing real credentials into fake login pages. Any organization that has existed for a while has to assume that, sooner or later, some valid credential will end up somewhere it shouldn’t be.

Authentication controls — passwords, two-factor authentication, single sign-on (SSO) — reduce how often that happens, but they do not eliminate the risk entirely. An IP allow list adds a second, largely independent safety net: even if a credential is stolen, it is useless to an attacker unless they are also making the request from an IP address the organization has explicitly trusted, such as the corporate office network, a VPN exit point, or a known set of build-server addresses.

This pattern is not unique to GitHub. Banks restrict certain account actions to known devices and locations. Cloud providers let you restrict management-console access to your office’s IP range. GitHub applies the same idea to source code, issues, pull requests, and the organization’s API surface, because for most companies, source code is one of the most sensitive assets they own.

GitHub’s access control is layered. The allow list is one layer among several, and knowing the layers around it prevents confusion later.

When any request reaches GitHub — a page load in a browser, a git push, or a call to the REST or GraphQL API — it passes through a stack of checks. Simplified, the order looks like this: first, is the request coming from a permitted network location (the IP allow list, if one is configured); second, is the caller who they claim to be (password, SSH key, token, or SSO session); third, does that identity have permission to perform the specific action being requested (repository roles, team permissions, branch protections, and so on).

flowchart TD
    A[Incoming Request] --> B{IP Allow List Enabled?}
    B -- No --> D[Proceed to Authentication]
    B -- Yes --> C{IP Address on the List?}
    C -- No --> X[Request Rejected - 403 Forbidden]
    C -- Yes --> D
    D --> E{Credentials Valid?}
    E -- No --> Y[Authentication Failed]
    E -- Yes --> F{Authorized for This Action?}
    F -- No --> Z[Permission Denied]
    F -- Yes --> G[Request Allowed]
        

Because the IP check happens first, it acts as a coarse, cheap filter: requests from disallowed locations are turned away before GitHub spends any effort verifying who is asking. This has a nice side effect for security — it reduces the attack surface available to someone probing from an unrecognized location, since they cannot even get far enough to test stolen credentials.

The allow list can be configured at two different scopes, and understanding the difference matters:

Each rule in the list is a small, well-defined object. Understanding its parts avoids the most common configuration mistakes.

An individual allow list entry is made up of a small number of fields, each doing one job:

Both IPv4 and IPv6 addresses are supported, which matters increasingly as more networks — including many corporate and mobile carrier networks — move traffic over IPv6. An allow list built only from IPv4 ranges can quietly fail for users whose traffic happens to leave over an IPv6 path.

A closer look at the sequence of events from the moment a request leaves your machine to the moment GitHub responds.

Say a developer runs a Git command against a private repository in a protected organization. The request leaves their machine carrying, among other things, the source IP address assigned to their network connection at that moment — the address their office router, home ISP, or VPN gateway currently has. GitHub’s edge infrastructure receives the request and, before routing it any further, checks whether an allow list is active for the target organization (or its enterprise).

sequenceDiagram
    participant U as Developer's Machine
    participant N as Network (ISP/VPN/Office)
    participant G as GitHub Edge
    participant A as Auth Service
    participant R as Repository Service

    U->>N: git push (repo request)
    N->>G: Request arrives with source IP
    G->>G: Is allow list enabled for this org?
    alt IP not on list
        G-->>U: 403 Forbidden - IP not permitted
    else IP on list or no list configured
        G->>A: Verify credentials (SSH key / token / SSO)
        alt Invalid credentials
            A-->>U: 401 Unauthorized
        else Valid credentials
            A->>R: Check permissions and process request
            R-->>U: Response (success)
        end
    end
        

Notice something deliberate in this sequence: if the IP check fails, GitHub does not proceed to check whether the credentials would have been valid. This ordering is a security best practice in itself — it avoids giving an attacker from an unrecognized location any signal about whether the username or token they tried was close to correct.

The same enforcement point covers three different ways of reaching GitHub: the web interface used in a browser, the REST and GraphQL APIs used by scripts and integrations, and Git operations themselves over HTTPS or SSH. A single allow list therefore protects all three surfaces at once rather than needing to be configured separately for each.

Beyond a single request, it helps to see the whole lifecycle of how an allow list is created, used, and eventually changed.

One data-flow detail worth calling out separately involves GitHub Apps and OAuth Apps. When a third-party integration (a CI/CD service, a deployment tool, a chat-ops bot) calls GitHub’s API on an organization’s behalf, that call also carries a source IP address — the integration’s own server, not the developer’s laptop. If the organization’s allow list does not include that integration’s IP ranges, the integration’s calls fail exactly like a human user’s would.

You may likeWhat Is the Reflog?→

A practical look at how administrators typically roll this feature out without breaking anyone’s access.

Because turning on enforcement too early can lock out legitimate users — including the very administrator trying to configure it — the process is designed to be gradual and reversible at every step. An organization owner navigates to the organization’s security settings, adds every known trusted range first, verifies the list is complete, and only then flips the switch that begins actual enforcement.

Individual entries can be edited, renamed, deactivated, or deleted at any time. Deactivating an entry (rather than deleting it) is often preferred when a range is only needed temporarily, such as a contractor’s office network for the duration of a project — it can be switched back on later without re-typing the CIDR value.

For organizations that belong to an enterprise with many member organizations, administrators can choose to manage allow list entries once at the enterprise level and have those entries apply consistently across every organization underneath it, rather than re-entering the same office and VPN ranges dozens of times.

Third-party tools complicate an otherwise simple story, so GitHub gives organizations a specific mechanism to handle them.

Modern engineering teams rarely interact with GitHub only through a browser and a laptop. CI/CD platforms, deployment tools, security scanners, and chat integrations all call GitHub’s API from their own infrastructure. If an organization’s allow list only contains office and VPN ranges, every one of those integrations would break the moment enforcement is switched on.

To solve this without forcing every organization to manually track and update a third party’s server IPs by hand, GitHub allows an organization to enable a setting that lets installed GitHub Apps’ own published IP allow list entries be automatically trusted. When a reputable integration publishes and maintains its own outbound IP ranges, and an organization installs that app with this inheritance setting turned on, the organization’s allow list effectively grows to include those ranges automatically — and stays in sync as the vendor updates them, without the organization needing to edit anything.

A different way of achieving the same goal, aimed at large enterprises that already centralize identity elsewhere.

Enterprises using Enterprise Managed Users together with OIDC-based single sign-on already define detailed access conditions — including network location conditions — inside their identity provider (their SSO system). For these enterprises, GitHub offers an alternative: instead of keeping a second, separate list of IP ranges inside GitHub, the enterprise can delegate the network-location decision entirely to the identity provider’s own conditional access policies.

Turning on the identity provider allow list has a specific side effect worth understanding clearly: it disables GitHub’s own IP allow list configuration for every organization in that enterprise, and it also disables the GraphQL API endpoints used to manage GitHub’s native allow list entries. In other words, this is an either/or choice at the enterprise level, not something that runs alongside GitHub’s own list — an enterprise uses one mechanism or the other, not both simultaneously.

No security control is free of trade-offs. Weighing them honestly leads to a much healthier rollout.

How this feature fits into a broader, defense-in-depth security posture, and what it deliberately does not protect against.

An IP allow list is best understood as one layer in a stack, not a complete security strategy by itself. It pairs naturally with single sign-on, two-factor authentication, and short-lived, scoped access tokens. Together, these layers mean that an attacker needs to simultaneously compromise a valid credential, pass the organization’s authentication checks, and be operating from a trusted network location — a considerably higher bar than any single control alone.

It’s also worth being precise about scope: the allow list restricts access to an organization’s private resources for its members and for API/integration calls made on the organization’s behalf. It is not designed as a way to make an entire GitHub account or public content invisible to the wider internet — its purpose is narrower and more specific than that, and treating it as a full network perimeter can create a false sense of security.

A control that no one is watching is a control that quietly rots. Visibility over time matters as much as the initial setup.

Changes to an organization’s or enterprise’s allow list — entries added, renamed, deactivated, deleted, or enforcement toggled on or off — are recorded in GitHub’s audit log, alongside other security-relevant organization events. This gives administrators a historical trail: who added a given range, when, and whether enforcement itself was ever turned off, intentionally or otherwise.

Beyond the audit log itself, teams that rely heavily on this feature often build lightweight, periodic reviews into their existing security processes: a quarterly check of every entry’s name and purpose, removing anything tied to a closed office, an expired contractor engagement, or a decommissioned CI provider. A list that only ever grows and never shrinks tends to accumulate risk quietly, entry by entry.

Patterns that experienced teams converge on, and traps that catch newer administrators.

A condensed checklist drawn from the patterns discussed so far.

Concrete situations where the concepts above show up in day-to-day engineering work.

No. It is an additional, independent layer. Credentials still need to be valid; the allow list only adds a further condition about where those credentials may be used from.

Your request would be rejected once your new address is no longer on the list, which is exactly why most organizations route remote access through a stable VPN exit point rather than allow-listing individual home addresses directly.

The allow list is designed to govern access to an organization’s private resources for its members and integrations, not to act as a general gate on the wider internet’s view of public content.

The allow list is configured at the organization (or enterprise) level and applies broadly to that scope, rather than being set independently per individual repository.

Their API calls are checked against the allow list like any other request. If their IP ranges aren’t covered — either manually or through automatic inheritance — their calls will start failing, which is why reviewing installed integrations before enforcing is an important rollout step.

It’s part of GitHub’s enterprise-tier offerings rather than the free or standard team plans, reflecting its target audience of organizations with more formal network security requirements.

For Enterprise Managed Users with OIDC, these are alternatives rather than complements — enabling the identity provider allow list disables GitHub’s own native allow list configuration for the enterprise.

An IP allow list adds a second, independent gate to GitHub’s access model: alongside proving who you are, it also checks where your request is physically coming from, and rejects anything outside a defined set of trusted addresses before authentication is even evaluated. It is a powerful, well-established pattern for reducing the blast radius of leaked or stolen credentials, but it comes with real operational responsibilities — remote work planning, third-party integration management, and ongoing list hygiene — that determine whether it strengthens security or quietly breaks legitimate work.