2fa

Subscribe to all “2fa” posts via RSS or follow GitHub Changelog on Twitter to stay updated on everything we ship.

→ ~ cd github-changelog
→ ~/github-changelog|main git log main
showing all changes successfully

Enhanced 2FA management for orgs and enterprises [Public Preview]

Enterprise settings page with the selected option to enable two-factor authentication for all organizations within the enterprise. An option to enforce only secure methods of authentication is also been selected. There is a warning informing the admin that members without two-factor authentication will need to add it to re-gain access.

Enterprises now have more control over their two-factor authentication (2FA) policies for all members of their organization through an enhanced 2FA enrollment experience in GitHub.
With this update, enterprise and organization administrators can ensure that users are maintaining secure 2FA methods when accessing enterprise and org resources. Currently, GitHub defines SMS/text message as an insecure method of 2FA, and TOTP authentication applications, the GitHub Mobile app, security keys, and passkeys as secure methods. Members without a secure method of 2FA configured, or who have insecure 2FA configured, will be prompted to configure secure 2FA before being allowed to access resources.

Enterprises can enable this new 2FA policy alongside a general 2FA requirement for their members, and current enterprises with a 2FA requirement can update their 2FA settings to add this secure methods enforcement. Members who are non-compliant with the new 2FA policy will no longer be removed from organizations, lessening a historical friction around enforcing 2FA policies at an enterprise or organization level, and instead be prevented from accessing enterprise or organization resources while non-compliant.

This new policy enables enterprises to protect their resources by only allowing access for users who meet the required security standards, without compromising organization membership integrity.

Learn more about the new enterprise policy for requiring only secure methods of two-factor authentication and about how GitHub is securing developer accounts using 2FA.

See more

Organizations can now enable 2FA requirement without removing non-compliant members [GA]

Enterprises can now broadly roll out two-factor authentication (2FA) to all members of their organization through an enhanced 2FA enrollment experience in GitHub. With this update, non-compliant users will no longer be removed from organizations when an organization begins enforcing 2FA.

2FA will be enforced via conditional access policies, which means members who have not yet enabled 2FA will continue to have their organization membership, but be blocked from visiting any organization resources until they enable 2FA.

This enables organizations to enable a broader 2FA enrollment without disrupting the membership status of their members who are yet to enable 2FA. This also enables members without elevated privileges to enable or disable 2FA on their accounts without losing organization membership.

Learn more about how GitHub is securing developer accounts using 2FA, and why we’re urging more organizations to join us in these efforts.

See more

2FA security checkup experience is now improved

GitHub is committed to a secure software ecosystem and requires most developers who contribute code on GitHub.com to enable one or more forms of two-factor authentication (2FA).To ensure that all users stay up to date with their account security configurations, we are now improving the checkup experience using various global banners that guide users to review and update their settings on a more regular basis.

These banners replace the security checkup interstitials that were previously displayed every 3 months for 2FA users. Each banner calls out the specific security configuration that needs attention (ex: user only having a single verified email), and will also include a quick link to the corresponding settings page to modify the required settings.

To learn more about the 2FA program, see our April 2024 blog post about how GitHub is securing millions of developers using 2FA, as well as the “About the mandatory 2FA program” documentation.

See more

[GA] Guest Collaborators for enterprise managed users

Guest Collaborators for GitHub Enterprise Cloud EMUs are now generally available. Originally announced in public beta at the end of last year, this feature allows an identity provider to assign the guest collaborator role to a user which will restrict that user’s default access to internal repositories.

Our thanks go to the thousands of public beta participants that guided our hand to the GA experience. By popular request, today we also released a public beta for repository collaborator access in EMU enterprises! This brings the “outside collaborator” access style to EMUs, limited to selecting users that are members of the enterprise account. Combining these two features together lets you grant the most granular possible access rights to specific repositories and organizations that fit your needs for contractors and other limited access use cases.

Learn more about guest collaborators

See more

SSH CA support for enterprise-owned user accounts

Enterprises that own their user accounts can now use SSH CAs to access user-owned repositories. This is an optional setting that enterprises can enable in their enterprise SSH CA settings page. Enabling this setting allows developers to use a single SSH certificate for all of their interactions with GitHub across their user account’s repositories and their enterprise’s repositories.

This is available now for customers using Enterprise Managed Users in GHEC, and will be included in GHES 3.14. It is not available to GHEC Classic enterprises, where developers bring their own personal accounts to the enterprise; the enterprise does not own those accounts and cannot gain access to their repositories.

For more about SSH certificate authorities, see “Managing SSH certificate authorities for your enterprise“.

See more

New SSH CAs must sign expiring certificates

SSH CAs uploaded to GitHub.com after March 27th, or in GHES 3.13 and beyond, can only sign certificates that expire. They must expire within 366 days of being created.
While expirations on certificates are not required by signing tools such as ssh-keygen, we are enforcing this best practice in order to protect against a weakness in how SSH certificates are linked to users.

CAs uploaded before the cutoff date or release will be marked in the UI as being allowed to sign non-expiring certificates:

image

An “upgrade” option on the CA lets you enforce expiration of signed certificates. Once you’ve validated that you are indeed using a lifetime on your certificates, we recommend upgrading your CAs. This upgrade step is irreversible, and new CAs cannot be downgraded to allow non-expiring certificates.
If a certificate is signed with no expiration, or a too-long expiration, it will be rejected during SSH connection with an error indicating The SSH certificate used was issued for a longer period than allowed.

This change forces the valid_after issuance timestamp to be written to the certificate, which allows GitHub to detect if the user changed their username after the certificate was issued for that username. This prevents a reuse attack vector where the former holder of a username is able to use certificates issued to them to sign in as the new holder of that username.

To learn more about managing SSH CAs, see “Managing your organization’s SSH CAs” and “Managing SSH CAs for your enterprise.” For information on using SSH CAs, see “About SSH CAs.”

See more

Log in to multiple GitHub accounts with the CLI

Introducing support for multiple GitHub accounts on a single host within the CLI! Log in with your work and personal accounts to manage your projects, wherever they're happening.

To add multiple accounts in the CLI, use the gh auth login command just as before. Now, instead of replacing your previous account, you will see the addition of a new account under gh auth status. This account will be marked as active, to indicate that gh will use it when communicating with GitHub. Run gh auth switch to change the active account, or gh auth logout to remove an account. Further details can be found in the v2.40.0 release notes.

Install or update the GitHub CLI today from your preferred source.

See more

[Public Beta] Guest collaborators for enterprise managed users

GitHub Enterprise Cloud customers that use Enterprise Managed Users (EMUs) can now participate in a public beta for a new user role that has restricted visibility of internal repositories. The guest collaborator role is defined via SCIM and assigned to users by the identity provider. Guest collaborators helps companies who work with contractors and other short-term partners in a flexible and managed fashion on specific projects, while also sharing code and ideas without restrictions amongst full enterprise members. When a guest collaborator is added to an organization they will only receive access to internal visibility repositories within that organization.

add a guest collaborator

Learn more about guest collaborators.

See more

Multi-account support on GitHub.com

GitHub.com now remembers multiple accounts in your browser. You can find the account switcher in your profile picture context menu, letting you more easily switch between user accounts without re-entering your credentials.

image

The account switcher helps developers alternate between Enterprise Managed User accounts provided by an employer and personal accounts for use with personal projects and open source contributions. It also helps administrators manage service accounts they use for automation and integration purposes.

Because these accounts often have significantly different privileges, there's never any mixing of user permissions between saved accounts. When you visit a page that your current account can't access, you'll see a prompt to switch accounts if you have more than one signed in.

When you switch accounts, you won't need to sign in again or perform 2FA unless the account session has expired. Session expiration occurs after two weeks without activity. SAML/OIDC SSO authorization is also saved for sessions, but often expires every 1 or 24 hours, and may need to be done again before you can access your organization resources.

To learn more, see "Switching between accounts".

See more

Enabling reactive 2FA requirements for release creation

Users who are not part of the mandatory 2FA program will now be added to it within 24 hours of creating their first release. In August we expanded the 2FA requirement to include most GitHub.com users that had created a release. Those groups have now completed their 2FA enrollment, but additional developers have since created their first release. They will be added to the 2FA program in the coming days, as will more users over time as they create releases.

Enterprise or organization administrators can learn more about their users' current 2FA requirements by visiting the People page for their enterprise or organization.

To learn more about the 2FA program, see our May 2023 blog post, as well as the “About the mandatory 2FA program” documentation.

See more

Changes to token permission on packages

Announcing changes to permissions for packages.

We are restricting the refs REST API endpoint from accepting POSTs from users and apps that only have the permission to read and write packages. Previously, this endpoint accepted updates to both tags and branches.

If that ability is critical to your development flows you will now be required to add explicit contents permissions to create refs.

A small cohort of customers relying on this flow have been notified of these changes and will have additional time to remediate.

We appreciate your feedback in GitHub's public feedback discussions.

See more

Passkeys are Generally Available

Passkeys are a replacement for passwords when signing in, providing higher security, ease-of-use, and loss-protection. They are now generally available on GitHub.com for all users. By using a passkey you no longer need to enter a password, or even your username, when you sign in – nor do you need to perform 2FA, if you have 2FA enabled on your account. This is because passkeys validate your identity, as well as possession of a device, so they count as two authentication factors in one. Once enrolled, you can register a brand new passkey and upgrade many security keys to passkeys.

Screenshot of the security key upgrade prompt, asking the user if they'd like to upgrade a security key called 'fingerprint' to a passkey.

To learn more, check out our documentation "About passkeys", as well as this previous blog post from the passkeys beta announcement. If you have any feedback, please drop us a note in our public discussion – we're excited for this advance in account security, and would love to understand how we can make it better for you.

See more

Enterprise managed users support for Ping Federate is now generally available

Now generally available, GitHub Enterprise Cloud customers with enterprise managed users (EMU) can integrate with Ping Federate as a formally supported SSO and SCIM identity provider. To get started, download the Ping Federate "GitHub EMU Connector 1.0" from the add-ons tab on the download page, under the "SaaS Connectors" heading. Add the connector to your Ping Federate installation and consult the Ping Federate documentation in addition to GitHub's SAML SSO and SCIM documentation for configuration.

The Ping Identity logo

The "GitHub EMU Connector" is maintained and supported by our partner, Ping Identity. Ping additionally maintains their own release notes for this connector.

See more

New 2FA account recovery options via password reset flow

Users with two-factor authentication enabled can now begin the account recovery process from the password reset flow. Previously, the account password was needed to access 2FA account recovery, but passwords on 2FA-enabled accounts could only be reset with a valid second factor. If you lost your password and all of your second factors, you were locked out because you could not access account recovery. With this change, a user can recover their account as long as they can perform email verification and provide a recovery factor, such as an SSH key, PAT, or previously signed in device.

Once you have performed email verification and provided a recovery factor, your recovery will be manually reviewed by GitHub's support team, who will email you within three business days. If your request is approved, you'll receive a link that lets you disable 2FA on your account. After that, you can reset your password and regain access to your account.

For more information about two-factor authentication, see "About two-factor authentication". For account recovery details, see "Recovering your account if you lose your 2FA credentials".

See more
View more changes