GitHub has released the early results of its two-factor authentication (2FA) requirements for code contributors on GitHub.com. The developer platform rolled out the requirements in 2023 to help secure developer accounts and prevent the next supply chain attack.
“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,” said GitHub Chief Security Officer Mike Hanley.
Over the last two years, GitHub has focused on the heavy upfront research and development, design, and enrolment of millions of developers in 2FA as part of this cross-platform effort.
“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,” said Henley. “Because strong multi-factor authentication remains one of the best defences 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 optimise for a seamless experience for developers, followed by a gradual rollout to ensure successful user onboarding as we continued to scale our requirements. But our efforts to ensure developers can be as secure as possible on GitHub.com don’t end here. We’re sharing the results of the first phase of our 2FA enrollment, calling for more organisations to implement similar requirements across their platforms.”
The results of the first phase of the 2FA enrollment include a 2FA 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.
GitHub says since it released passkeys to public beta in July 2023, nearly 1.4 million passkeys have been registered on GitHub.com, quickly overtaking other forms of Webauthn-backed 2FA in day-to-day usage.
GitHub is bullish on passkeys. However, it says it continues to offer flexibility, reliability, and security in the ways developers 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. GitHub says there is a lot of room ahead to keep increasing passkey adoption while also driving down the use of less-secure factor types. GitHub says it sees a future where passkeys are the first choice for most developers on the platform.
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.
GitHub invested in several 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 user experience and design investments ahead of the rollout, GitHub saw a one-third reduction in 2FA-related support tickets.
Further, additional internal workflow optimisation 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 and safe scenarios (like doing account recovery while you’re still signed in).
This data collection and vetting dramatically reduces the time for support teams to review these recovery attempts. This allows locked-out users to safely get back to their accounts faster than ever, and enables GitHub to scale 2FA enrollment to millions of users.
GitHub also introduced a 2FA verification check-up 28 days after 2FA setup. This ensures users have an opportunity to verify their configuration. This fail-safe check-up 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 the primary focus was to secure the developers on GitHub.com, GitHub has also been intentionally transparent with its rollout approach, encouraging more organisations to take up the call to require their own 2FA requirements. Every user account with 2FA successfully enabled is one less vector for attackers to compromise. 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.
GitHub is evaluating how to encourage even more GitHub.com users to enrol in 2FA during 2024 while continuing to monitor and improve the user experience. It is investigating additional account security features, including session and token binding, that will enable developers and their organisations 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.
GitHub chose to take on 2FA at scale because it believed it was the right thing to do. It says the work demonstrates that the security bar can be raised without negatively impacting the user experience. GitHub encourages other organisations to strongly consider implementing 2FA requirements on their own platforms where possible.
