OIDC for managed users exists to bring one specific capability to GitHub: your identity provider’s conditional access policy.
That is worth understanding precisely, because conditional access is frequently assumed to cover more than it does — and the gaps are where the interesting failures live.
The short answer
Section titled “The short answer”OIDC for Enterprise Managed Users is Entra ID only. GitHub states that “OpenID Connect (OIDC) and Conditional Access Policy (CAP) support for Enterprise Managed Users is only available for Microsoft Entra ID (previously known as Azure AD).”
What it adds is CAP IP condition enforcement. GitHub documents that it “will automatically use your IdP’s conditional access policy (CAP) IP conditions to validate interactions with GitHub when members use the web UI or change IP addresses, and for each authentication with a personal access token or SSH key associated with a user account.”
Only IP conditions. GitHub is explicit: “GitHub enforces your IdP’s IP conditions but cannot enforce your device compliance conditions.”
Multi-factor policies apply at IdP sign-in only, not during GitHub operations.
Migration between SAML and OIDC is documented in both directions, so the choice is not permanent in the way the EMU decision itself is.
What conditional access actually enforces
Section titled “What conditional access actually enforces”The precision that determines whether your security model is what you think it is.
IP conditions: enforced. If your CAP restricts access to corporate network ranges, GitHub honours that.
Device compliance conditions: not enforced. A policy requiring a managed, compliant device does not reach GitHub. Somebody on the corporate network from an unmanaged device satisfies the IP condition and is admitted.
Multi-factor authentication: at sign-in only. The user authenticated with MFA when they signed in to the IdP. Subsequent GitHub operations do not re-evaluate it.
Which means the control is a network-location control, and describing it as “conditional access on GitHub” to a security stakeholder without that qualification is misleading.
When conditions are evaluated
Section titled “When conditions are evaluated”Web interface use, and when a user’s IP address changes.
Every authentication with a personal access token or SSH key associated with a user account.
That second point has a large consequence. GitHub warns that “Actions that use a personal access token will likely be blocked by your IdP’s CAP” — because the request originates from wherever the automation runs, which is not a corporate IP range.
The documented workaround is service accounts exempted from IP controls. Which is a reasonable pattern and worth designing deliberately: a small, named set of automation identities, exempt from the IP condition, with correspondingly stronger controls elsewhere.
It is also a reminder that automation should not use user tokens. A GitHub App authenticating with its own installation token is not a user, and the whole class of problem does not arise. See machine identities.
Designing the automation exemption
Section titled “Designing the automation exemption”Since automation using user tokens will likely be blocked, the exemption is a design problem rather than a workaround, and it deserves the same care as any other privileged path.
Keep the exempt set small and named. Each exempt identity is a path around your network-location control. Three is manageable; thirty is the control no longer existing.
Compensate elsewhere. An identity exempt from the IP condition should have correspondingly tighter controls: narrowly scoped permissions, short-lived credentials where possible, and monitoring of its activity. Exemption from one control is a reason to strengthen others, not a free pass.
Prefer eliminating the need. Every automation moved to a GitHub App is one fewer exemption, because the app authenticates as itself rather than on behalf of a user. This is the answer that scales.
Document why each exemption exists. In two years somebody will find an exempt account and be unable to tell whether it is load-bearing or residue. A one-line reason attached to each prevents both leaving it forever and removing it dangerously.
Review the list quarterly. Exemptions accumulate the way bypass lists do, and for the same reason: each addition is individually justified and nobody removes any.
Watch for the exempt account becoming a shared credential. The failure pattern is an exempt service account whose token ends up in several systems because it is the one that works. That converts a narrow exemption into a broad one, invisibly.
What this means for developer experience
Section titled “What this means for developer experience”Conditional access is a control users feel, and anticipating the friction reduces the support load.
Working from home or a coffee shop. If the policy permits only corporate ranges, remote work requires the VPN — for GitHub as well as everything else. That is probably already true, and it is worth confirming rather than assuming.
IP address changes mid-session. Moving between networks triggers re-evaluation. A laptop switching from wired to wireless, or a VPN reconnecting, can produce an unexpected authentication prompt.
Mobile devices. Mobile networks are unlikely to satisfy a corporate IP condition. If people review pull requests on their phones, that stops working.
Personal access tokens on a personal machine. A developer’s local script using their token from home is subject to the same condition as the browser.
None of these are bugs. They are the control working. But a developer who hits one without warning files a support ticket, and a hundred developers hitting one on the same morning files a hundred.
Publish the expectations before enabling. What works, what does not, what to do when blocked, and who to ask. The same discipline as any enforcement change.
Deploy keys and the exemption
Section titled “Deploy keys and the exemption”CAP IP conditions do not apply to deploy keys. GitHub’s stated reason: deploy keys do not perform operations on behalf of a user.
Which is logically consistent and worth noting as a gap. A deploy key is repository-scoped access that bypasses your network-location control entirely.
Two consequences:
Deploy keys become the path of least resistance for automation that the IP condition would otherwise block. That is not necessarily wrong, and it should be a decision rather than a discovery.
Deploy key inventory matters more under CAP. Every deploy key is an access path outside the conditional access control, and they are long-lived, rarely rotated and frequently forgotten.
Audit them. Which repositories have deploy keys, who created them, when, whether they are read-only, and whether anything still uses them.
Codespaces
Section titled “Codespaces”GitHub documents that Codespaces “may not be available if your enterprise uses OIDC SSO with CAP to restrict access by IP addresses”, because codespaces are created with dynamic addresses that a CAP is likely to block.
This is a real trade-off, not a configuration issue to solve. An enterprise that depends on cloud development environments and also enforces IP-based conditional access has a direct conflict.
Find out before enabling. If Codespaces is in use or planned, test it against the policy in a pilot rather than discovering the incompatibility after enforcement.
The Git access question
Section titled “The Git access question”Developers do not primarily use GitHub through a browser, and how CAP interacts with Git operations is the detail that determines whether the control is workable.
Git over HTTPS with a personal access token is subject to CAP IP conditions, because it is a token authentication associated with a user account. A developer cloning from a non-permitted location is blocked.
Git over SSH with a user SSH key is likewise subject to the conditions, for the same reason.
Git over SSH with a deploy key is not, because deploy keys do not act on behalf of a user.
Which produces a consistent rule: anything authenticating as a person is checked; anything authenticating as a repository-scoped or app-scoped identity is not.
The practical consequence for developers is that Git works exactly where the browser works, and fails exactly where the browser fails. That consistency is helpful — there is one rule to explain — and it means the VPN requirement extends to command-line work.
For CI, the rule points at the right answer. A pipeline authenticating with a user’s token is subject to conditions it cannot satisfy and is a fragile design regardless. A pipeline authenticating as a GitHub App, or with the workflow’s own token, is neither.
Test both Git paths during verification, not only the browser. A configuration verified in a browser and not at the command line is half verified, and the half you skipped is the one developers use all day.
Web session protection
Section titled “Web session protection”An opt-in extension, available from the enterprise’s authentication security settings when CAP support is already enabled.
What it changes: when a user’s IP conditions are not satisfied, GitHub documents that they “can view and filter all user-owned resources but cannot view the details of the results for notifications, searches, personal dashboards, or starred repositories.”
So it is a partial restriction rather than a block. The user is not locked out; specific personal surfaces are degraded.
Which makes it a reasonable additional control for an enterprise already enforcing IP conditions, and a confusing user experience for anybody who does not know it is enabled. Document it.
Rolling it out
Section titled “Rolling it out”The sequence that avoids the two bad outcomes — a control that blocks the wrong people, and a control that turns out to enforce nothing.
-
Confirm your identity provider is Entra ID and your conditional access policy uses IP conditions. If either is false, stop — this feature does not do what you need.
-
Inventory automation using user tokens. Every one is a candidate for blocking. This is the longest step and it determines the rollout timeline.
-
Migrate what you can to GitHub Apps. Fewer exemptions is a better outcome than more.
-
Define the exemption set for what remains, with a reason and an owner for each.
-
Inventory deploy keys. They will be exempt whether you intend it or not, so know what they are.
-
Test Codespaces if it is in use, before enabling anything.
-
Verify the administrative access path and the recovery codes, with two people.
-
Publish the developer expectations — what works from where, what to do when blocked.
-
Enable CAP support, and run the verification list.
-
Observe for a period before adding web session protection. Two changes, two observation windows.
Step 2 is where the time goes, and it is worth doing thoroughly. An automation discovered after enforcement is an outage; one discovered before is a task.
Migration and lockout risk
Section titled “Migration and lockout risk”Migration between SAML and OIDC is documented in both directions, which is unusual for identity changes and means the decision is recoverable.
The lockout risk is the thing to plan around. A conditional access policy that blocks the administrators trying to fix it is a difficult position, and it is entirely possible to create.
Precautions:
Recovery codes, stored and tested, as for any SSO configuration. See SAML SSO.
A tested administrative path that satisfies the policy. Somebody must be able to reach the settings from a location the policy permits.
Exempt the migration service account. GitHub notes specifically that service accounts should be exempt from Entra ID’s CAP when using GitHub Enterprise Importer, or the migration will be blocked.
Stage the enforcement. Enable CAP support, observe, then add web session protection separately. Two changes, two observation periods.
Choosing between SAML and OIDC for managed users
Section titled “Choosing between SAML and OIDC for managed users”Given both are available with Entra ID, the choice comes down to whether CAP enforcement is worth having.
Choose OIDC if your conditional access policy uses IP conditions that you want enforced on GitHub, your identity provider is Entra ID, and you have worked through the automation, deploy key and Codespaces consequences.
Choose SAML if your identity provider is Okta or PingFederate — in which case OIDC is not available to you — or if your conditional access policy is device-based, in which case OIDC enforces nothing you do not already have.
The migration is documented both ways, which lowers the stakes considerably compared with most identity decisions. Starting with SAML and moving to OIDC later is a legitimate plan, and it lets you get managed users working before adding a second variable.
Do not choose OIDC for the protocol. OIDC versus SAML as protocols is not the decision here; the decision is CAP enforcement. If CAP is not the goal, the protocol difference is not a reason.
And verify the current support matrix before planning. Identity provider support and feature availability change, and this is the area where an out-of-date assumption invalidates the most work.
Testing the configuration
Section titled “Testing the configuration”The verification list, because a conditional access configuration that appears to work and does not is worse than none.
-
Sign in from a permitted location. Confirm access works normally.
-
Sign in from a non-permitted location. Confirm it is blocked, and note what the user sees — that message is what your support team will be asked about.
-
Change networks mid-session. Confirm the re-evaluation behaves as expected.
-
Authenticate with a personal access token from a permitted location. Confirm it works.
-
Authenticate with a personal access token from a non-permitted location. Confirm it is blocked. This is the behaviour that will surprise automation owners.
-
Use a deploy key from a non-permitted location. Confirm it works — it should, and confirming it tells you the gap is real rather than theoretical.
-
Test an exempt service account from a non-permitted location.
-
If Codespaces is in scope, create one and confirm whether it can reach your repositories.
-
Test the administrative path from a permitted location, with a second person, before you need it.
Record the results. This list is also the evidence that the control works, which is the thing an assessor will ask for, and reproducing it later from memory is unreliable.
Common mistakes
Section titled “Common mistakes”Believing device compliance is enforced. Only IP conditions are.
Recording CAP as a multi-factor control on GitHub operations. MFA applies at IdP sign-in.
Not anticipating token blocking. Automation using user tokens will likely be blocked.
No deploy key inventory. They are exempt from CAP entirely.
Enabling CAP with Codespaces in use. Dynamic addresses conflict with IP restrictions.
Not exempting the migration service account. GitHub Enterprise Importer will be blocked.
Enabling web session protection without documenting it. Users experience degraded surfaces with no explanation.
No tested administrative access path. Lockout is possible and unpleasant.
What CAP contributes to a control narrative
Section titled “What CAP contributes to a control narrative”Because the point of this is usually a compliance or risk requirement, it is worth being precise about what you can honestly claim.
You can say: access to GitHub from user accounts is restricted to network locations permitted by the corporate conditional access policy, enforced at web sign-in, on address change, and on every user token and SSH key authentication.
You cannot say: access requires a compliant managed device. GitHub does not enforce device compliance conditions.
You cannot say: every GitHub operation is subject to multi-factor authentication. MFA is evaluated at IdP sign-in.
You must qualify: deploy keys are exempt, and any exempted service accounts are exempt. Both are documented gaps and both should appear in the control description rather than being omitted.
No GitHub configuration produces compliance with SOC 2, PCI DSS, HIPAA, ISO 27001 or FedRAMP by itself. CAP enforcement can be evidence supporting a network-access control objective; whether it satisfies that objective is an assessment your auditor makes against your stated control, not something the feature grants.
Which argues for writing the control description first, in your own words, and then checking which parts GitHub actually enforces. Doing it the other way — starting from the feature and describing what it does — tends to produce a control statement that quietly overclaims.
Keep the test evidence. The verification list above, run and recorded, is what demonstrates the control operates as described. That is more persuasive than a configuration screenshot and it is the thing most organisations do not have.
Mental model
Section titled “Mental model”CAP support brings your identity provider’s network location conditions to GitHub, and only those. Device compliance and per-operation MFA stay behind. The control is real and its boundary is specific — and the gaps, particularly deploy keys and automation tokens, are where the access that matters usually lives.
What you learned
Section titled “What you learned”- OIDC and CAP support for Enterprise Managed Users is available only with Microsoft Entra ID
- CAP IP conditions are validated on web interface use, IP changes, and every user token or SSH key authentication
- GitHub enforces IP conditions but cannot enforce device compliance conditions
- MFA policies apply at IdP sign-in, not during GitHub operations
- Actions using a personal access token will likely be blocked, with exempted service accounts as the documented workaround
- CAP IP conditions do not apply to deploy keys, because deploy keys do not act on behalf of a user
- Codespaces may be unavailable under IP-restricting CAP because codespaces have dynamic addresses
- Web session protection degrades specific personal surfaces rather than blocking access outright
- Migration between SAML and OIDC is documented in both directions
Exercise
Section titled “Exercise”Reason from your enterprise’s configuration, or from documentation.
-
If you have a conditional access policy, list its conditions. Predict: how many are IP conditions and how many are device compliance?
-
For each device compliance condition, note that GitHub will not enforce it. Does that change your control assessment?
-
Inventory deploy keys across your estate. Predict: how many, and how old is the oldest?
-
Identify every automation authenticating with a user personal access token. Each is a candidate for blocking.
-
For each, decide: exempt service account, or migrate to a GitHub App?
-
Determine whether Codespaces is in use or planned. Test it against your policy.
-
Confirm at least two people can reach enterprise settings from a permitted location, and that recovery codes work.
-
Write the user-facing note explaining what web session protection changes, if you would enable it.