GitHub, the world’s leading AI-powered developer platform, has released the early results of its two-factor authentication (2FA) requirements for code contributors on GitHub.com–which was first announced in 2022 and rolled out across 2023–in efforts to secure developer accounts and prevent the next supply chain attack. Over the last two years, it has focused on heavy upfront R&D, design, and enrolment of millions of developers in 2FA as part of this cross-platform effort.

Here are the initial achievements from the 2023 initiative, and the impact they’ll have on ensuring the software ecosystem is more secure.

• Dramatic increase in 2FA adoption on GitHub.com, focused on users who have the most critical impact on the software supply chain
• Users adopting more secure means of 2FA, including passkeys
• Net reduction in 2FA-related support ticket volume, credit to heavy up-front user research and design as well as Support process improvements
• Other organizations like RubyGems, PyPI, and AWS joined in raising the bar for the entire software supply chain, proving that large increases in 2FA adoption aren’t an insurmountable challenge

Mike Hanley, Chief Security Officer at GitHub, said: “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 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,” Hanley added.

2FA Adoption

Since GitHub began rolling out mandatory 2FA in March 2023, it has 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 contributors on GitHub.com.

Stronger and More Reliable Authentication

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 GitHub 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 GitHub is bullish on passkeys, it’s also important for GitHub to continue 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. GitHub continues to support SMS as a 2FA option for those who may not be able to adopt other factors, but has intentionally made design choices in 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 23% between early 2023 and early 2024. There is a lot of room ahead to continue driving passkey adoption, while also driving down use of less-secure factor types, and GitHub sees a future where passkeys are the first choice for the majority of developers on the platform.

Finally, as a result of GitHub’s improved enrollment experience and passkey rollout, 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.

User Experience and Support

GitHub 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, to help developers employ strong account security while maintaining our promise of a seamless user experience. While one would reasonably expect an increase in 2FA-related support tickets as the relative usage increased on the platform, GitHub saw the opposite. Because of the significant investments in user experience and design ahead of the rollout, GitHub saw a one-third reduction in 2FA-related support tickets.

Further, additional internal workflow optimization and automation for GitHub’s 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 safe scenarios (like doing account recovery while you’re still signed in). This data collection and vetting dramatically reduces the time it takes for 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.

GitHub also introduced a 2FA verification check up that occurs 28 days after 2FA setup, to ensure users have an opportunity to verify their configuration. This check up 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.

Ecosystem Impact

While the primary focus was to secure the developers on GitHub.com, GitHub has also been intentionally transparent with its approach to the rollout, with the goal of inspiring 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, RubyGems, PyPI, and AWS have joined GitHub’s efforts to drive increased usage of 2FA to secure GitHub’s shared ecosystem and software supply chain.

Looking Forward

GitHub is evaluating how to encourage even more GitHub.com users to enroll in 2FA during 2024, while continuing to monitor and improve the user experience. It is 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. The company will 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.

A Call to Action

GitHub chose to take on 2FA at scale because it believes it’s the right thing to do to protect the entire ecosystem and it’s vital that other organizations join. GitHub’s work shows that it’s possible to raise the bar for security significantly without negatively impacting users’ experiences, and encourages other organizations to strongly consider making 2FA requirements on their own platforms where possible.