Skip to content

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

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

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

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

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

As part of the two-factor authentication requirement program on GitHub.com, the People pages of enterprises and organizations have been updated to include the 2FA requirement status of members and collaborators. As an administrator, you can see which of your users have not yet enabled 2FA but are required to do so because of an action they have take in one of your organizations, or elsewhere on GitHub.com.

A clock icon will appear as a user's 2FA status will show if the user is required to enable 2FA. When the icon is red, they are past the due date for enabling 2FA, and are at risk of being blocked from accessing GitHub.com until they enable it. Clicking the clock icon will display the user's enrollment date.
256704235-eb7cb75d-2806-4aa6-aa44-aa9148bfb828

You can filter the UI to show only users who have a pending requirement. Enrollment dates are also now included in the CSV and JSON downloads of enterprise and organization memberships.

To learn more about the 2fa enrollment program, see our blog post with more details. For information about viewing your members, see the organization and enterprise documentation.

See more

Passkeys are a replacement for passwords when signing in, providing higher security, ease-of-use, and loss-protection. They're now available on GitHub.com as a public beta – see this blog post for more information.

This public beta is open to all users with a password, regardless of whether you use 2FA. To get started, enable passkeys as a feature preview.

By using passkeys, 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. That's 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 a passkey. If you're enrolled in the preview, the next time you use an eligible security key you'll be asked to upgrade it.
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 this blog post about passkeys, as well as "About passkeys" in our documentation. 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

During two-factor authentication and when entering sudo mode for sensitive actions on GitHub.com, TOTP codes could be successfully used multiple times within their validity window. To improve security, this reuse is no longer allowed on GitHub.com, and will be updated in GHES with version 3.10.

Systems that have attempted to script the login flow, across multiple parallel jobs, may break as a result of this change.

Learn more about two-factor authentication with TOTP.

See more

The option to use SMS on the sudo page on GitHub.com has been removed. Users can still use other 2FA methods as well as their password to pass the sudo check and take sensitive actions. If your account only has SMS as its 2FA method, you can visit your security settings to enable additional methods such as security keys and TOTP, as well as installing the GitHub Mobile app.

To learn more about the GitHub.com sudo prompt, see "Sudo mode". For details about setting up additional 2FA methods, see "Configuring two-factor authentication".

See more

You can now set up both SMS and an authenticator app (TOTP) for two-factor authentication on your GitHub.com account. Previously these methods were mutually exclusive, and you needed to create a "fallback" SMS registration that could be used for account recovery.

2FA settings page showing both authenticator app and SMS registered

With this update, we are removing the fallback SMS option, and will migrate all fallback SMS registrations to be standard 2FA methods today. A small set of users had both a primary and fallback SMS registration on their account – they continue to have that fallback SMS registration, and will receive email about it today.

To learn more about setting up 2FA and GitHub's account recovery methods, see "Configuring 2FA" and "Configuring 2fa recovery methods"

See more

The Primary field on two-factor authentication methods has been removed, and replaced with a Preferred option. This new option sets your preferred 2FA method for account login and use of the sudo prompt. You can choose between TOTP, SMS, security keys, or GitHub Mobile as your preferred 2FA method.

Additionally, you can now update your 2FA methods inline at https://github.com/settings/security, rather than going through the initial 2FA setup flow again.

image

With this change, device-specific preferences for 2FA have been removed – each login will always default to your preferred method. If you previously set a default on one of your devices, your most recent choice has been copied to your account-wide preference. Otherwise, no preference will be set, and GitHub will select from your available second factors in this order: security keys, GitHub Mobile, TOTP, and then SMS.

To learn more, see "Changing your preferred two-factor authentication method" and "Configuring two-factor authentication".

See more

You can now unlink your email address from a two-factor enabled GitHub account in case you’re unable to sign into it or recover it. When the worst occurs, and a user is unable to find an SSH key, PAT, or a device that’s been previously signed into GitHub in order to recover their account, they may want to start fresh with a new GitHub.com account. Since accounts on GitHub are required to each have a unique email address, though, locked out users can have difficulty starting a new account using their preferred email address.

In the 2FA recovery flow, a new option is presented at the bottom of the page, which will allow a user to remove their email address from a GitHub account:

image

Selecting this option will send emails to each of the addresses on file for the account, each one containing a unique link. Following the link will remove the respective email address from the GitHub account, making it available again for a new account.

For more information, see Unlinking your email from a locked account.

See more

GitHub.com users who set up two-factor authentication will see a prompt after 28 days, asking them to perform 2FA and confirm their second factor settings. This prompt helps avoid account lockout due to misconfigured authenticator applications (TOTP apps), especially those that failed to save the TOTP secret after validating it during set up.

This prompt appears in existing sessions if you haven't already performed 2FA as part of a sudo prompt or signing in on another device. If you find that you can't perform 2FA, you'll be presented with a shortcut that allows you to reset your 2FA setup.

image

All users that enable 2FA will be eligible for this prompt, including users required to enable it by their organization or GitHub itself.

To learn more about two-factor authentication, see "Configuring two-factor authentication".

See more

As we prepare for next year's 2FA requirement for active contributors on GitHub, we're making improvements to our two-factor setup UI to encourage best practices and ensure new 2FA users have their authentication factors set up correctly from the start.

We now take an opinionated stance on which second factor you should set up first – you'll no longer be asked to choose between SMS or setting up an authenticator app (known as TOTP), and instead see the TOTP setup screen immediately when first setting up 2FA.

If you wish to use SMS when setting up 2FA, you can switch your authentication method via the new option at the bottom. In the future, you'll also find security keys there as an option for initial setup on supported devices and browsers.

For more information, see "Configuring two-factor authentication".

See more

You can now review and manage your browser and GitHub Mobile sessions using the new Sessions tab in your user settings. This new tab includes all of your signed-in web sessions, as well as each GitHub Mobile app your account is signed into. You can revoke each web and mobile session individually. For mobile sessions, this signs you out of the GitHub Mobile app on that device, and disables that application for use as a second factor. The new Sessions tab replaces the web sessions view that was present under Password and authentication.

image

This new settings page is generally available for GitHub.com users now, and will be released to GitHub Enterprise Server as part of GHES 3.8.

To learn more, see "Viewing and managing your sessions".

See more

Starting today, two-factor authentication (2FA) will be enforced for maintainers of all high-impact npm packages. A package is marked as a high impact package when they have more than 1 million weekly downloads or have more than 500 dependents. Maintainers of such packages will be notified 15 days in advance to enroll for 2FA.

To learn more about configuring 2FA, see Configuring two-factor authentication.
To learn more about 2FA in general, see About two-factor authentication.
For questions and comments, open a discussion in our feedback repository.

See more

Users with 2FA enabled may see false-alert flags in their security log for recovery_code_regenerated events between July 15 and August 11, 2022.
These events were improperly emitted during an upgrade to the 2FA platform. The storage format of the per-user value GitHub uses to generate your recovery codes was updated, causing the watch job to trigger the erroneous recovery_code_regenerated event.

No action is required from impacted users with regards to these events. GitHub has a policy to not delete security log events, even ones generated in error. For this reason, we are adding flags to signal that these events are false-alerts. No recovery codes were regenerated, and your existing saved recovery codes are still valid.

image

See more

Recover Accounts Elsewhere allows a user to store a recovery token with a third-party recovery partner to use as a recovery method when their account is protected by two-factor authentication. Effective immediately, we will no longer be allowing new recovery tokens to be stored using Recover Accounts Elsewhere.

On December 1st, 2021, account recovery tokens stored using Recover Accounts Elsewhere will no longer be accepted as a recovery option when contacting support to recover access to your account. You will still be able to use our other recovery mechanisms to recover your account.

If you have registered an account recovery token using this feature, we recommend you take this opportunity to download your two-factor recovery codes. You can also revoke your recovery tokens using these steps:

  1. Navigate to the Account Security page.
  2. Scroll down to "Recovery tokens" and client "Edit".
  3. Click "Revoke token" for each token.

We'll be sending occasional email notifications throughout the deprecation period to all users with recovery tokens registered.

Questions? Take a look at our updated documentation on account recovery, or contact GitHub Support.

See more