Build what's next on GitHub, the place for anyone from anywhere to build anything.
Join us October 28-29 in San Francisco or online for GitHub Universe, our flagship developer event uniting people, agents, and the world's code.
We’ve dramatically increased 2FA adoption on GitHub as part of our responsibility to make the software ecosystem more secure. Read on to learn how we secured millions of developers and why we’re urging more organizations to join us in these efforts.
Though technology has advanced significantly to combat the proliferation of sophisticated security threats, the reality is that preventing the next cyberattack depends on getting the security basics right, and efforts to secure the software ecosystem must protect the developers who design, build, and maintain the software we all depend on.
As the home to the world’s largest developer community, GitHub is in a unique position to help improve the security of the software supply chain. In May 2022, we introduced an initiative to raise the bar for supply chain security by addressing the first link in that chain—the security of developers. Because strong multi-factor authentication remains one of the best defenses against account takeover and subsequent supply chain compromise, we set an ambitious goal to require users who contribute code on GitHub.com to enable one or more forms of two-factor authentication (2FA) by the end of 2023.
What followed was a year’s worth of investments in research and design around the implementation of these requirements, to optimize for a seamless experience for developers, followed by a gradual rollout to ensure successful user onboarding as we continued to scale our requirements. While our efforts to ensure developers can be as secure as possible on GitHub.com don’t end here, today, we’re sharing the results of the first phase of our 2FA enrollment, with a call for more organizations to implement similar requirements across their own platforms. Let’s dive in.
We’re proud of the initial achievements from the 2023 initiative, and the impact they’ll have on ensuring the software ecosystem is more secure. We saw:
Since we began rolling out mandatory 2FA in March 2023, we’ve seen an opt-in rate of nearly 95% across code contributors who received the 2FA requirement in 2023, and enrollments continue to trickle in. Moreover, this has led to a 54% increase in 2FA adoption among all active contributors1 on GitHub.com.
A key area of focus for this initiative was encouraging users to adopt more secure means of 2FA, especially passkeys which currently offer the strongest mix of security and usability. Since we released passkeys to public beta in July 2023, nearly 1.4 million passkeys have been registered on GitHub.com. Even more impressive, passkeys rapidly overtook other forms of Webauthn-backed 2FA in day-to-day usage.
While we’re bullish on passkeys, it’s also important that GitHub continues to offer flexibility, reliability, and security in the ways developers around the world can authenticate to the platform, particularly for those who may not have access to such technology. We continue to support SMS as a 2FA option for those who may not be able to adopt other factors, but have intentionally made design choices in our 2FA onboarding workflows to encourage users to adopt more secure alternatives where possible. This work reduced the overall share of SMS as a second factor by almost 25% between early 2023 and early 2024. We see a lot of room ahead to continue driving passkey adoption, while also driving down use of less-secure factor types, and foresee a future where passkeys are the first choice for the majority of developers on the GitHub platform.
Finally, as a result of our improved enrollment experience and passkey rollout, our data shows that it’s 47% more likely users will configure two or more forms of 2FA. Each additional factor makes it far less likely that a given user will lose all their factors and end up locked out, resulting in a smoother and more reliable user experience.
Knowing we needed to help developers employ strong account security while maintaining our promise of a seamless user experience, we invested in a number of improvements including refreshed 2FA onboarding flows, adding GitHub Mobile 2FA, and more user options in terms of primary 2FA factors. While one would reasonably expect an increase in 2FA-related support tickets as the relative usage increased on the platform, we saw the opposite. Because of the significant investments in user experience and design ahead of the rollout, we saw a one-third reduction in 2FA-related support tickets.
Further, additional internal workflow optimization and automation for GitHub Support teams led to a 54% reduction in 2FA account recovery support tickets that require significant human intervention. Today, more than 75% of account recovery tickets come through the in-product workflow, which collects recovery details from users and automatically checks for risk factors, as well as scenarios we know are safe (like doing account recovery while you’re still signed in). This data collection and vetting dramatically reduces the time it takes for GitHub Support teams to review these recovery attempts, allowing locked out users to safely get back to their accounts faster than ever and enabling GitHub to scale 2FA enrollment to millions of users.
We also introduced a 2FA verification checkup that occurs 28 days after 2FA setup, to ensure users have an opportunity to verify their configuration. This checkup was a fail-safe that helped 25% of users successfully reconfigure their accounts if they made a mistake or lost a factor, thereby avoiding account lockout for the user and significantly reducing account recovery support volume for GitHub.
While our primary focus was to secure the developers on GitHub.com, we have also been intentionally transparent with our approach to the rollout to inspire more organizations to take up the call after GitHub and npm to require their own 2FA requirements. Every user account with 2FA successfully enabled is one fewer vector for attackers to compromise organizations or important open source software. Over the last two years, we’ve been encouraged to see RubyGems, PyPI, and AWS join our efforts to drive increased usage of 2FA to secure our shared ecosystem and software supply chain.
Now that it’s 2024, you might be asking, “Why didn’t I get a 2FA requirement?” While we’re ecstatic at the progress we made in 2023 to enroll millions of developers in 2FA, the job of securing the software supply chain and the developers responsible for it doesn’t end. Our initial work prioritized distinct user groups based on the impact of their user privileges or specific actions they took.
Protecting Accounts Without 2FA
Those who are not required to enable 2FA still benefit from layered protections such as verified devices and compromised password prevention.
There is also still important industry-wide work ahead to support users that may not have access to a phone or control over the software of the computer they use to adopt 2FA. As a global platform, we believe that everyone should have access to tools that make software development easier and more secure, and our efforts to enforce strong authentication for as many developers as possible is ongoing. We’ll continue to find solutions to protect developers, the projects they’re working on, and the communities they participate in, working hard to take a balanced approach that greatly improves the security of the entire software supply chain without restricting those with different setups or environments around the world.
Looking ahead, we’re evaluating how we can require even more GitHub.com users to enroll in 2FA during 2024, while continuing to monitor and improve the user experience. We’re investigating additional account security features, such as session and token binding, that will enable developers and their organizations to better manage the risk of account compromise, with or without 2FA. We also want to continue to drive adoption of the most secure factors available to developers on the platform, such as passkeys or security keys, and help developers “move up” to more secure authenticator types. Throughout this, making security easy and effective remains a top priority—after all, security that isn’t usable isn’t security at all.
We all have a role to play in securing the software ecosystem, and platforms must commit to being both a responsible consumer of software and contributor back to it. GitHub chose to take on 2FA at scale because we believe it’s the right thing to do to protect the entire ecosystem and we believe it’s vital that other organizations join us. Our work here shows that it’s possible to raise the bar for security significantly without negatively impacting users’ experiences. We encourage other organizations to strongly consider making 2FA requirements on their own platforms where possible.
If you’d like to learn more about how we rolled out 2FA for millions of developers, look forward to a follow-up post that takes a deeper dive into our work in the coming weeks.
If you’d like to join us in this effort, enable 2FA on your own account, adopt passkeys, or require 2FA for your organization.
Note: If you or your organization are implementing internal 2FA-related policy, please note that our requirements are not designed to cover all GitHub.com users. Read more about our current enrollment criteria here and consider requiring 2FA for your organization.
Want to learn more about how GitHub can help you easily secure your code?
At GitHub Universe 2024, we’ll explore cutting-edge research and best practices in developer-first security—empowering you to ship secure code fast.
Our Super Early Bird sale ends soon! Buy your tickets now.
