GitHub Enterprise Cloud with data residency is scheduled to stop accepting HTTPS/TLS connections from clients that offer only X25519 for key agreement beginning October 7, 2026. GitHub says P-256, also known as secp256r1, and P-384, or secp384r1, will remain supported.
The change is most relevant to applications, proxies, security appliances, runtimes, GitHub CLI installations, and other TLS clients that have been explicitly restricted to X25519. GitHub says current browsers, operating systems, GitHub CLI releases, and commonly used TLS libraries already support P-256, so many customers may not need to change anything. However, teams with deliberate TLS group restrictions should review those settings before the cutoff.
What is changing
After the announced date, affected GHE.com HTTPS endpoints will reject connections from clients configured to offer only X25519. Clients must offer a supported alternative, with P-256 as GitHub’s stated recommendation. P-384 is another supported option.
This is a TLS compatibility change rather than a reported vulnerability or exploit. It applies to HTTPS/TLS connections for GitHub Enterprise Cloud with data residency. GitHub’s announcement explicitly says SSH connectivity is not affected, so the change does not require an SSH configuration update.
The supplied announcement identifies October 7, 2026 as the effective date. Its URL contains the text “september-15,” but that slug does not match the stated date; administrators should use October 7, 2026 as the announced cutoff rather than the URL wording.
Who should review their configuration
The likely impact is concentrated among systems that intentionally limit TLS key agreement to X25519. That can include outbound clients embedded in applications, enterprise proxies, inspection or security appliances, operating system policies, language runtimes, GitHub CLI deployments, and TLS libraries.
A normal client that already offers P-256 alongside X25519 is not described as requiring X25519 to be disabled. The available documentation supports configuring a list of groups, but it does not establish a complete compatibility matrix or guarantee how every intermediary will negotiate with every GHE.com service. Administrators should therefore verify the settings and test the systems that matter rather than assume that a particular product version is affected or unaffected.
GitHub’s GHE.com network documentation lists general client-facing hostname patterns, including *.SUBDOMAIN.ghe.com, *.pages.SUBDOMAIN.ghe.com, *.actions.SUBDOMAIN.ghe.com, *.githubassets.com, *.githubusercontent.com, *.blob.core.windows.net, and auth.ghe.com. Those patterns should not be interpreted as a definitive list of endpoints governed by the announced TLS policy. The supplied documentation does not map the policy to each individual hostname.
Use current enterprise metadata
GHE.com customers should avoid relying on an incomplete hard-coded endpoint list when identifying services to test. GitHub’s network documentation directs customers to query the /meta API for enterprise-specific storage hostnames and current service metadata. The REST API documentation also describes the metadata endpoint and the need to query current values directly.
In practice, administrators should first identify the enterprise-specific hostnames used by their integrations and automation. They can then review the TLS behavior of the applications and intermediary systems that connect to those services. The documentation establishes how to obtain current metadata, but it does not provide a GitHub-maintained test environment or a customer-specific pass/fail workflow for this change.
How to inspect TLS group settings
OpenSSL provides a generic way to make a controlled TLS connection to a host and port, set the TLS Server Name Indication (SNI) value, and specify supported groups. For example:
openssl s_client -connect HOST:443 -servername HOST -groups P-256:P-384:X25519The OpenSSL s_client documentation documents the connection, SNI, and -groups options, including the P-256, P-384, and X25519 group names. OpenSSL’s configuration documentation explains that group lists are ordered by preference and that the first listed group is used for the TLS 1.3 key share.
This is a diagnostic example, not a GitHub-certified validation procedure. Use the actual hostname identified for the relevant enterprise service. Also, do not treat a connection as production-safe merely because s_client continues after a certificate verification error; the OpenSSL documentation warns that the tool can continue in that situation.
Applications using libcurl may have a corresponding option. CURLOPT_SSL_EC_CURVES accepts a colon-delimited list of client key-exchange algorithms when the TLS backend supports the option. The documented supported backends include OpenSSL and wolfSSL, and the option was added in curl 7.73.0. The exact setting still depends on how the application and its TLS backend are configured.
What you should do
- Inventory outbound TLS clients. Include applications, proxies, security appliances, runtimes, GitHub CLI installations, and libraries that connect to GHE.com services.
- Look for X25519-only restrictions. Review group or curve policies in both applications and intermediary systems. Pay particular attention to configurations that explicitly list only X25519.
- Enable P-256. GitHub recommends ensuring that
secp256r1is offered. P-384 may also be offered, but it is not stated to be mandatory. - Identify current service hostnames. Query the enterprise-specific
/metaAPI and consult the current GHE.com network documentation instead of assuming a fixed endpoint list. - Run controlled tests. Use a tool such as OpenSSL with SNI and selected group lists to examine relevant connections. Treat successful generic testing as evidence for that tested path only, not proof that every endpoint or intermediary is ready.
- Seek customer-specific assistance if needed. GitHub Support may be appropriate for validation questions, although the supplied support page does not provide a detailed procedure for this change.
Availability and remaining limits
The change is announced for October 7, 2026 and is limited in the supplied evidence to GitHub Enterprise Cloud with data residency. It should not be generalized to GitHub.com or other GitHub products. The evidence also does not specify affected operating-system, runtime, proxy, appliance, GitHub CLI, or TLS-library versions.
Most modern client environments may already be compatible because GitHub says they support P-256. The operational risk is instead concentrated in systems with a deliberate X25519-only policy. Teams should confirm their own configurations and connection paths before the announced date, while treating the exact endpoint coverage and GitHub-side group-selection behavior as undocumented where the available documentation does not specify them.
