
GitHub passkeys – Analysis of sign-ups and logins with passkeys: Best practices from GitHub
This article series aims to provide a systematic overview of the passkey process and user experience for different companies as they move towards a password-free world. While the goal is to improve user-friendly and secure authentication, each company has its own unique way of implementing passkeys.
TL;DR
- Passkey availability since July 12, 2023
- GitHub's passkey implementation is the best among tech giants seen so far
- Passkeys are accessible on major platforms, including iOS, macOS, Windows, and Android, as well as across various browsers
- Passkeys can be used both on the GitHub website and the native app
- Passkey creation only works through a pop-up right after password login or manually in the 'Password and authentication' section under account settings
- Passkeys are only available for login (not yet at sign-up)
- Conditional UI functionality is enabled, providing a seamless user experience
- Sophisticated passkey management and smart detection of browser-operating in the account settings
1. Introduction
More and more companies from a wide range of industries are stepping into a password-free world and implement passkeys. Through this series of articles, we aim to provide a comprehensive overview of the passkey user experience of those companies. This should enable you to incorporate these findings and enhance your product login accordingly. In each article, we focus on a single company. Today, we dive into GitHub. Since July 12, existing GitHub users can create passkeys for their account and log in with them. This makes GitHub the pioneering company to predominantly focus on targeting passkeys towards software developers through its software development platform. The passkey rollout paves the way for over 100 million users to enter a password-free world that offers enhanced security and user-friendliness.
Disclaimer:
- Status of the analysis is July 2023. Passkey features are subject to change by companies on an ongoing basis.
- Please refer to the use cases to find the devices we used for the analysis.
2. Key insights from GitHub passkeys analysis
In this section, we present the most important insights we have gained from the analysis of GitHub passkeys.
2.1 Highlights of GitHub passkeys implementation
2.1.1 Phased implementation approach
GitHub passkeys are currently limited to logging into GitHub accounts. Currently, there are two ways to set up a passkey for the device in use. On the one hand, users can navigate to their account settings and enable passkeys manually. In the ‘Password and authentication’ section, users manually create the passkey. On the other hand, users who have logged in with their password are presented with a pop-up message that recommends creating a passkey for their account. This hybrid rollout strategy allows GitHub to begin with low risk and identify any potential bugs by gathering feedback from early adopters. Hence, the phased implementation ensures a smooth transition and accommodates non-technical users who may be unfamiliar with passkeys as an additional login option.
2.1.2 Convenient passkey usage in GitHub's native apps
As one of the first companies to introduce passkeys, GitHub allows the creation and use of passkeys in its native apps for Apple and Android. This convenient functionality enables mobile users to log into their GitHub accounts using passkeys directly through the app, eliminating the need to visit the GitHub website.
2.1.3 Enabled Conditional UI feature
One of the standout features of GitHub's passkey implementation is the immediate integration of Conditional UI. This seamless integration allows for enhanced user convenience by automatically suggesting and prefilling stored passkeys when users click on the username input field. From the very beginning, GitHub users can experience the time-saving benefits of passkeys without the need for manual search or entry of credentials.
2.1.4 Insightful passkey properties
In the 'Password and authentication' section, where all stored GitHub passkeys of the user are displayed, GitHub provides interesting properties of the passkeys. They involve two badges that indicate the browser-operating system combination where the passkey was created and whether it has been synchronized. Additionally, timestamps are provided to indicate the creation and retrieval of the passkey.
2.1.5 Helpful user education
GitHub uses the term “passkeys”. To cater users who may be unfamiliar with passkeys or seek further information, GitHub provides comprehensive descriptions conveniently located during the passkey creation process. The descriptions refer to the underlying concept of biometric authentication, whereby no platform-specific authentication methods are mentioned. This aspect also highlights the emphasis placed on passwordless authentication offered by passkeys, which is consistently emphasized throughout GitHub's passkey creation process.
2.2 Drawbacks of GitHub passkeys implementation
2.2.1 Tedious login experience in native app
Each time a user attempts to log into the GitHub app, they are directed to a WebView screen. Consequently, direct login to the app is not possible, and users are required to enter their login credentials within the WebView to log into the app successfully. That means that there is still potential to improve the UX of the native app.
Considering what is currently possible in terms of passkey features and technology, this is still by far the best implementation we came across so far during our series of analyses on passkey rollouts.
3. Passkey setup in your GitHub account
GitHub has published a comprehensive blog article that provides a detailed explanation of passkeys and guides users through the setup process. This highlights their efforts to persuade users about the benefits of passkeys and promote passwordless authentication. It also reflects their recognition of the need to educate users about the technology and functionality behind passkeys, as not everyone may be familiar with them yet. This also becomes clear during the process of creating new passkeys in GitHub (see use cases).
To enable passkeys for your GitHub account, follow these steps:
Go to the 'Settings' sidebar and find the 'Feature Preview' tab. Click on it and enable the passkeys feature. Once passkeys are enabled, you can upgrade eligible security keys to passkeys and register new passkeys.
1. Click on your profile picture in the top right corner
2. Go to ‘Feature preview’

3. Go to 'Preview'
4. Click on ‘Enable’

5. Click on your profile picture in the right corner again
6. Go to ‘Settings’
7. Go to ‘Password and authentication’

8. Click on ‘Add a passkey’
You can now register new passkeys for your GitHub account. We show how this works in the tested cases in the next section.
4. Analysis of the login process
4.1 Tested cases
Note that we have only performed the use cases with passkey-ready devices (e.g., no iPhone prior to iOS 16.0, no MacBook prior to macOS Ventura, no Windows device prior to Windows 10). We use the same GitHub account for every use case.
To initially set up the first passkey for our GitHub account, we clicked on ‘Add a passkey’ as previously shown in step 7 and 8.
Before a new passkey can be created, GitHub requires the confirmation of our identity through two-factor authentication.

Once this has been successfully verified, a passkey can be created.

It is noteworthy that at this point the user is again informed about what passkeys are all about. This shows that GitHub wants to educate users who do not yet know passkeys.
After clicking on ‘Add passkey’, the default Apple passkey pop-up appears that prompts us to use Touch ID.

Once our fingerprint was successfully registered, we received a notification confirming the successful generation of the passkey. The passkey can now be named individually according to our preference.
The further explanations of passkey functions once again demonstrate GitHub's commitment to support its users at every stage and guiding them through the creation process.
We have assigned the name "Safari on macOS" to our passkey, which can now be found in our account settings under 'Password and authentication'. Additionally, the passkey properties are displayed, including the official passkey logo for identification. The properties also include two badges indicating the browser-operating system-combination on which the passkey was created and whether it was synchronized, along with timestamps for creation and retrieval of the passkey.

When using the same browser-operating system-combination for which a passkey has already been stored, GitHub detects this and prevents the creation or overwrite of an existing passkey.

Here, we performed the same test as in the use case above. Instead of Safari, we used Chrome this time. Here, too, we encounter the already familiar passkey flow.In this use case, we used the previously created passkey to log in to the GitHub iOS app.
When logging into the native apps of GitHub, a WebView screen always appears where the user has to enter his login data. Upon entering our username, we were prompted to authenticate using two-factor authentication as the default method. Since we intended to log in with our passkey, we clicked on ‘Use your passkey’.

By clicking on ‘Use passkey’ we retrieved our passkey which was previously synced in the Apple iCloud Keychain (see use case 1).

After verifying our identity with Face ID, the passkey was successfully retrieved, granting us access to our account and logging us in.
In this use case, we generated a passkey on an Android device using Chrome. Our objective was to store and synchronize this passkey using the Google Password Manager so that we can retrieve it in the subsequent use case. To ensure successful synchronization and retrieval, it is crucial to be logged in into Chrome using the same Google account.
After we clicked on ‘Add passkey’, we have gone through the already familiar passkey creation process.

Below the grey horizontal line, the Google Account can be set where the created passkey is to be stored.


In this use case, we use the passkey that we created in use case 4. As this passkey is retrieved from an Android phone, no new passkey for Windows is created.
In every major browser, GitHub displays the same login screen. Under which conditions the ‘Sign-in with a passkey’ appears under the green ‘Sign in’ button, we are going to explain in section “GitHub’s passkey detection feature and Conditional UI”.

After clicking the ‘Sign-in with a passkey’ button, we were presented with the familiar Chrome passkey pop-up. Here, we selected ‘S21 von Vincent‘, which is the Android device linked to the Google account that holds the passkey from use case 4.

With this device, we scanned the QR code that appeared and successfully retrieved the passkey from use case 4.

5. GitHub’s passkey detection feature and Conditional UI
5.1 GitHub’s passkey detection feature
Here, we refer again to the initial login screen, which in all major browsers consists of a 'Username or email address' and 'Password' input field and a green 'Sign in' button.
As mentioned before, under certain conditions a 'Sign-in with a passkey' button appears below the 'Sign in' button.

This is always the case if the user has already logged in to GitHub with a passkey on the device used in the active browser. This means that GitHub detects and recognizes the use of passkeys on their platform.
On the desktop, we took a closer look at how GitHub does it. When you go to the GitHub website, the browser requests a login fragment file from GitHub. In response, GitHub provides additional information regarding the user's passkey and device, enabling background detection of whether a passkey has been utilized for GitHub on that specific device previously.


By suggesting the use of a passkey with this button, it serves as a reminder that a stored passkey may be available for the account. This not only streamlines the login process but also reduces the number of clicks required, resulting in a more efficient user experience.
5.2 Conditional UI
Speaking of the automatic suggestion to log in with a passkey, Conditional UI is still the most powerful feature. Conditional UI leverages the autofill function passkeys provide. It automatically prefills passkeys as soon as the user clicks on the username input field. This means that users no longer must search for their credentials manually (not even usernames!), as they are already stored in the device / browser and are automatically pre-filled.
Unlike Shopify (see our analysis of Shopify passkeys) and Microsoft (see our analysis of Microsoft passkeys), which also recently introduced passkeys, Conditional UI has been enabled on GitHub directly since it was rolled out.


6. Conclusion
GitHub's passkey implementation sets a new standard for all major companies introducing passkeys soon. Since its availability from July 12, 2023, GitHub has demonstrated a superior approach to passkey implementation among tech giants. With passkeys accessible on major platforms and browsers, including iOS, macOS, Windows, and Android, GitHub offers a seamless user experience. The convenience of passkey usage within GitHub's mobile apps and the integration of the Conditional UI feature further enhance user convenience. Additionally, insightful passkey properties and comprehensive user education contribute to a well-rounded passkey experience. GitHub's implementation showcases the potential and benefits of password-free authentication, establishing a benchmark for others to follow.
Enjoyed this read?
Stay up to date with the latest news, strategies and insights about passkeys sent straight to your inbox!