Enforcing security settings in your enterprise account

Requiring two-factor authentication for organizations in your enterprise account

Enterprise owners can require that organization members, billing managers, and outside collaborators in all organizations owned by an enterprise account use two-factor authentication to secure their personal accounts.

Before you can require 2FA for all organizations owned by your enterprise account, you must enable two-factor authentication for your own account. For more information, see "Securing your account with two-factor authentication (2FA)."

Before you require use of two-factor authentication, we recommend notifying organization members, outside collaborators, and billing managers and asking them to set up 2FA for their accounts. Organization owners can see if members and outside collaborators already use 2FA on each organization's People page. For more information, see "Viewing whether users in your organization have 2FA enabled."

1. Navigate to your enterprise account by visiting https://github.com/enterprises/ENTERPRISE-NAME, replacing ENTERPRISE-NAME with your enterprise account's name.
2. In the enterprise account sidebar, click Settings.
   
3. In the left sidebar, click Security.
   
4. Under "Two-factor authentication", review the information about changing the setting. Optionally, to view the setting's current configuration for all organizations in the enterprise account before enforcing the setting, click View your organizations' current configurations.
   
5. Under "Two-factor authentication", select Require two-factor authentication for all organizations in your business, then click Save.
   
6. If prompted, read the information about members and outside collaborators who will be removed from the organizations owned by your enterprise account. To confirm the change, type your enterprise account's name, then click Remove members & require two-factor authentication.
   
7. Optionally, if any members or outside collaborators are removed from the organizations owned by your enterprise account, we recommend sending them an invitation to reinstate their former privileges and access to your organization. Each person must enable two-factor authentication before they can accept your invitation.

Managing allowed IP addresses for organizations in your enterprise account

Enterprise owners can restrict access to assets owned by organizations in an enterprise account by configuring an allow list for specific IP addresses. For example, you can allow access from only the IP address of your office network. The allow list for IP addresses will block access via the web, API, and Git from any IP addresses that are not on the allow list.

You can approve access for a single IP address, or a range of addresses, using CIDR notation. For more information, see "CIDR notation" on Wikipedia.

To enforce the IP allow list, you must first add IP addresses to the list, then enable the IP allow list. You must add your current IP address, or a matching range, before you enable the IP allow list.

You can also configure allowed IP addresses for an individual organization. For more information, see "Managing allowed IP addresses for your organization."

Adding an allowed IP address

1. Navigate to your enterprise account by visiting https://github.com/enterprises/ENTERPRISE-NAME, replacing ENTERPRISE-NAME with your enterprise account's name.
2. In the enterprise account sidebar, click Settings.
   
3. In the left sidebar, click Security.
   
4. Under "IP Address", type an IP address, or range of addresses, in CIDR notation.
   
5. Under "Description", type a description of the allowed IP address or range.
   
6. Click Add.
   

Enabling allowed IP addresses

1. Navigate to your enterprise account by visiting https://github.com/enterprises/ENTERPRISE-NAME, replacing ENTERPRISE-NAME with your enterprise account's name.
2. In the enterprise account sidebar, click Settings.
   
3. In the left sidebar, click Security.
   
4. Under "IP allow list", select Enable IP allow list.
   
5. Click Save.

Editing an allowed IP address

1. Navigate to your enterprise account by visiting https://github.com/enterprises/ENTERPRISE-NAME, replacing ENTERPRISE-NAME with your enterprise account's name.
2. In the enterprise account sidebar, click Settings.
   
3. In the left sidebar, click Security.
   
4. Under "IP allow list", to the right of the entry you want to edit, click Edit.
   
5. Type an IP address, or range of addresses, in CIDR notation.
   
6. Type a description of the allowed IP address or range.
   
7. Click Update.

Deleting an allowed IP address

1. Navigate to your enterprise account by visiting https://github.com/enterprises/ENTERPRISE-NAME, replacing ENTERPRISE-NAME with your enterprise account's name.
2. In the enterprise account sidebar, click Settings.
   
3. In the left sidebar, click Security.
   
4. Under "IP allow list", to the right of the entry you want to delete, click Delete.
   
5. To permanently delete the entry, click Yes, delete this IP allow list entry.
   

Using GitHub Actions with an IP allow list

To allow your self-hosted runners to communicate with GitHub, add the IP address or IP address range of your self-hosted runners to the IP allow list. For more information, see "Adding an allowed IP address."

Enabling SAML single sign-on for organizations in your enterprise account

SAML SSO gives organization owners and enterprise owners on GitHub a way to control and secure access to organization resources like repositories, issues, and pull requests. For more information, see "About identity and access management with SAML single sign-on."

Enterprise owners can enable SAML SSO and centralized authentication through a SAML IdP across all organizations owned by an enterprise account. After you enable SAML SSO for your enterprise account, SAML SSO is enabled by default for all organizations owned by your enterprise account. All members will be required to authenticate using SAML SSO to gain access to the organizations where they are a member, and enterprise owners will be required to authenticate using SAML SSO when accessing an enterprise account.

To access each organization's resources on GitHub, the member must have an active SAML session in their browser. To access each organization's protected resources using the API and Git, the member must use a personal access token or SSH key that the member has authorized for use with the organization. Enterprise owners can view and revoke a member's linked identity, active sessions, or authorized credentials at any time. For more information, see "Viewing and managing a user's SAML access to your enterprise account."

We offer limited support for all identity providers that implement the SAML 2.0 standard. We officially support these identity providers that have been internally tested:

• Active Directory Federation Services (AD FS)
• Azure Active Directory (Azure AD)
• Okta
• OneLogin
• PingOne
• Shibboleth

If you're participating in the private beta for user provisioning for enterprise accounts, when you enable SAML for your enterprise account, SCIM provisioning and deprovisioning is enabled by default in GitHub. You can use provisioning to manage organization membership by configuring SCIM in your IdP. If you're not participating in the private beta, SCIM is not supported for enterprise accounts. For more information, see "Managing user provisioning for organizations in your enterprise account."

For more detailed information about how to enable SAML using Okta, see "Configuring SAML single sign-on and SCIM for your enterprise account using Okta.

1. Navigate to your enterprise account by visiting https://github.com/enterprises/ENTERPRISE-NAME, replacing ENTERPRISE-NAME with your enterprise account's name.
2. In the enterprise account sidebar, click Settings.
   
3. In the left sidebar, click Security.
   
4. Optionally, to view the setting's current configuration for all organizations in the enterprise account before enforcing the setting, click View your organizations' current configurations.
   
5. Under "SAML single sign-on", select Enable SAML authentication.
   
6. In the Sign on URL field, type the HTTPS endpoint of your IdP for single sign-on requests. This value is available in your IdP configuration.
   
7. Optionally, in the Issuer field, type your SAML issuer's name. This verifies the authenticity of sent messages.
   
8. Under Public Certificate, paste a certificate to verify SAML responses.
   
9. To verify the integrity of the requests from your SAML issuer, click . Then in the Signature Method and Digest Method drop-downs, choose the hashing algorithm used by your SAML issuer.
   
10. Before enabling SAML SSO for your enterprise, click Test SAML configuration to ensure that the information you've entered is correct.
    
11. Click Save.

Managing user provisioning for organizations in your enterprise account

Enterprise owners can manage organization membership in an enterprise account directly from an identity provider (IdP).

If you use Okta as your IdP, you can use SCIM to manage organization membership in your enterprise account. SCIM automatically invites people to or removes people from organizations in your enterprise account based on whether they are members of the group that corresponds to each organization in your IdP.

If you're participating in the private beta for user provisioning for enterprise accounts, when you enable SAML for your enterprise account, SCIM provisioning and deprovisioning is enabled by default in GitHub. You can use provisioning to manage organization membership by configuring SCIM in your IdP. Optionally, you can also enable SAML provisioning and, separately, deprovisioning.

If you configure SCIM in your IdP, each time you make changes to group membership in your IdP, your IdP will make a SCIM call to GitHub to update the corresponding organization's membership. If you enable SAML provisioning, each time an enterprise member accesses a resource protected by your enterprise account's SAML configuration, that SAML assertion will trigger provisioning.

For each SCIM call or SAML assertion, GitHub will check the IdP groups the user belongs to and perform the following operations:

• If the user is a member of an IdP group that corresponds to an organization owned by your enterprise account, and the user is not currently a member of that organization, add the user to the organization (SAML assertion) or send the user an email invitation to join the organization (SCIM call).
• Cancel any existing invitations for the user to join an organization owned by your enterprise account.

For each SCIM call and, if you enable SAML deprovisioning, each SAML assertion, GitHub will also perform the following operation:

• If the user is not a member of an IdP group that corresponds to an organization owned by your enterprise account, and the user is currently a member of that organization, remove the user from the organization.

If deprovisioning removes the last remaining owner from an organization, the organization will become unowned. Enterprise owners can assume ownership of unowned organizations. For more information, see "Managing unowned organizations in your enterprise account."

To enable user provisioning for your enterprise account using Okta, see "Configuring SAML single sign-on and SCIM for your enterprise account using Okta."

Managing team synchronization for organizations in your enterprise account

Enterprise owners can enable team synchronization between an IdP and GitHub to allow organization owners and team maintainers to connect teams in the organizations owned by your enterprise account with IdP groups.

When you synchronize a GitHub team with an IdP group, changes to the IdP group are reflected on GitHub automatically, reducing the need for manual updates and custom scripts. You can use an IdP with team synchronization to manage administrative tasks such as onboarding new members, granting new permissions for movements within an organization, and removing member access to the organization.

You can use team synchronization with your enterprise account with Azure AD.

After you enable team synchronization, team maintainers and organization owners can connect a team to an IdP group on GitHub or through the API. For more information, see "Synchronizing a team with an identity provider group" and "Team synchronization."

You can also configure and manage team synchronization for an individual organization. For more information, see "Managing team synchronization for your organization."

Prerequisites

Before you can enable team synchronization for your enterprise account:

• You or your Azure AD administrator must be a Global administrator or a Privileged Role administrator in Azure AD.
• You must enable SAML single sign-on for organizations in your enterprise account with your supported IdP. For more information, see "Enabling SAML single sign-on for organizations in your enterprise account."
• You must authenticate to your enterprise account using SAML SSO and the supported IdP. For more information, see "Authenticating with SAML single sign-on."

Managing team synchronization for Azure AD

To enable team synchronization for Azure AD, your Azure AD installation needs the following permissions:

• Read all users’ full profiles
• Sign in and read user profile
• Read directory data

1. Navigate to your enterprise account by visiting https://github.com/enterprises/ENTERPRISE-NAME, replacing ENTERPRISE-NAME with your enterprise account's name.
2. In the enterprise account sidebar, click Settings.
   
3. In the left sidebar, click Security.
   
4. Confirm that SAML SSO is enabled. For more information, see "Managing SAML single sign-on for your organization."
5. Under "Team synchronization", click Enable for Azure AD.
   
6. To confirm team synchronization:
   • If you have IdP access, click Enable team synchronization. You'll be redirected to your identity provider's SAML SSO page and asked to select your account and review the requested permissions.
   • If you don't have IdP access, copy the IdP redirect link and share it with your IdP administrator to continue enabling team synchronization.
     
7. Review the identity provider tenant information you want to connect to your enterprise account, then click Approve.
   
8. To disable team synchronization, click Disable team synchronization.
   

Managing your enterprise account's SSH certificate authorities

Enterprise owners can add and delete an enterprise account's SSH certificate authorities (CA).

By adding an SSH CA to your enterprise account, you can allow members of any organization owned by your enterprise account to access that organization's repositories using SSH certificates you provide. You can require that members use SSH certificates to access organization resources,. For more information, see "About SSH certificate authorities."

Adding an SSH certificate authority

When you issue each client certificate, you must include an extension that specifies which GitHub user the certificate is for. For more information, see "About SSH certificate authorities."

1. Navigate to your enterprise account by visiting https://github.com/enterprises/ENTERPRISE-NAME, replacing ENTERPRISE-NAME with your enterprise account's name.
2. In the enterprise account sidebar, click Settings.
   
3. In the left sidebar, click Security.
   
4. To the right of "SSH Certificate Authorities", click New CA.
   
5. Under "Key," paste your public SSH key.
   
6. Click Add CA.
7. Optionally, to require members to use SSH certificates, select Require SSH Certificates, then click Save.
   

Deleting an SSH certificate authority

Deleting a CA cannot be undone. If you want to use the same CA in the future, you'll need to upload the CA again.

1. Navigate to your enterprise account by visiting https://github.com/enterprises/ENTERPRISE-NAME, replacing ENTERPRISE-NAME with your enterprise account's name.
2. In the enterprise account sidebar, click Settings.
   
3. In the left sidebar, click Security.
   
4. Under "SSH Certificate Authorities", to the right of the CA you want to delete, click Delete.
   
5. Read the warning, then click I understand, please delete this CA.