---
url: 'https://www.corbado.com/blog/github-passkeys'
title: 'GitHub Passkeys: Implement Passkeys like GitHub'
description: 'Analyze best practices for GitHub passkeys. Tailored for developers seeking to enhance security and user experience.'
lang: 'en'
author: 'Vincent Delitz'
date: '2023-07-19T00:00:00.000Z'
lastModified: '2026-10-03T06:00:32.453Z'
keywords: 'GitHub passkeys, passkeys in github'
category: 'Passkeys Reviews'
---
# GitHub Passkeys: Implement Passkeys like GitHub
## 1. TL;DR
- [Passkey availability](https://www.corbado.com/faq/are-passkeys-available) 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](https://www.corbado.com/blog/webauthn-errors),
macOS, Windows, and [Android](https://www.corbado.com/blog/how-to-enable-passkeys-android), as well as across
various browsers
- Passkeys can be used both on the GitHub website and the
[native app](https://www.corbado.com/blog/native-app-passkeys)
- [Passkey creation](https://www.corbado.com/blog/passkey-creation-best-practices) 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](https://www.corbado.com/glossary/conditional-ui) functionality is enabled, providing a
seamless user experience
- Sophisticated passkey management and smart detection of browser-operating in the account
settings
## 2. 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](https://www.corbado.com/faq/passkey-user-experience-benefits-non-technical-audience) 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:
1. Status of the analysis is July 2023.
[Passkey features](https://www.corbado.com/blog/social-logins-pre-filled-passkeys-customization) are subject
to change by companies on an ongoing basis.
2. Please refer to the use cases to find the devices we used for the analysis.
## 3. Key insights from GitHub passkeys analysis
In this section, we present the most important insights we have gained from the analysis
of GitHub passkeys.
### 3.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](https://www.corbado.com/faq/gradual-rollout-support-passkey-adoption) 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](https://www.corbado.com/blog/how-to-enable-passkeys-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](https://www.corbado.com/glossary/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](https://www.corbado.com/blog/passkey-creation-best-practices) process. The
descriptions refer to the underlying concept of
[biometric authentication](https://www.corbado.com/blog/passkeys-biometric-authentication), whereby no
platform-specific authentication methods are mentioned. This aspect also highlights the
emphasis placed on [passwordless authentication](https://www.corbado.com/glossary/passwordless-authentication)
offered by passkeys, which is consistently emphasized throughout GitHub's
[passkey creation](https://www.corbado.com/blog/passkey-creation-best-practices) process.
### 3.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](https://www.corbado.com/blog/native-app-passkeys) screen. Consequently, direct login to the app is not
possible, and users are required to enter their login credentials within the
[WebView](https://www.corbado.com/blog/native-app-passkeys) to log into the app successfully. That means that
there is still potential to improve the UX of the [native app](https://www.corbado.com/blog/native-app-passkeys).
**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.**
## 4. 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](https://www.corbado.com/glossary/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.
## 5. Analysis of the login process
### 5.1 Tested cases
Note that we have only performed the use cases with passkey-ready devices (e.g., no iPhone
prior to [iOS](https://www.corbado.com/blog/webauthn-errors) 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.
| | MacBook (macOS Ventura 13.4.1) | iPhone (iOS 16.5.1) | Xiaomi Mi 10 (Android 11) | Windows 11 |
| --------------------- | ---------------------------------- | ------------------------------------------ | ---------------------------------- | ---------------------------------- |
| Multi-device passkey | [Use case 1](#use-case-1) (Safari) | [Use case 2](#use-case-2) (GitHub iOS app) | [Use case 3](#use-case-3) (Chrome) | N/A |
| Single-device passkey | N/A | N/A | N/A | [Use case 4](#use-case-4) (Chrome) |
4.1.1 Use case 1: MacBook Chrome passkey creation
| Use case | MacBook Chrome passkey creation |
| ---------------- | ------------------------------- |
| Use case number | 1 |
| Device | MacBook |
| Operating system | macOS Ventura 13.4.1 |
| Browser | Safari |
| Platform | Apple |
| Synced in | Apple iCloud Keychain |
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](https://www.corbado.com/blog/psd2-passkeys/are-passkeys-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.
4.1.2 Use case 2: iPhone GitHub iOS app passkey login
| Use case | iPhone GitHub iOS app passkey login |
| ---------------- | ----------------------------------- |
| Use case number | 2 |
| Device | iPhone |
| Operating system | iOS 16.5.1 |
| Browser | N/A |
| Platform | Apple |
| Synced in | Apple iCloud Keychain |
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](https://www.corbado.com/blog/webauthn-errors) app.
When logging into the native apps of GitHub, a [WebView](https://www.corbado.com/blog/native-app-passkeys) 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](https://www.corbado.com/blog/psd2-passkeys/are-passkeys-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](https://www.corbado.com/glossary/icloud-keychain) (see use case 1).
After verifying our identity with [Face ID](https://www.corbado.com/faq/is-face-id-passkey), the passkey was
successfully retrieved, granting us access to our account and logging us in.
4.1.3 Use case 3: Android Chrome passkey creation
| Use case | Android Chrome passkey creation |
| ---------------- | ------------------------------- |
| Use case number | 3 |
| Device | Xiaomi Mi 10 |
| Operating system | Android 11 |
| Browser | Chrome 114 |
| Platform | Android |
| Synced in | Google Password Manager |
In this use case, we generated a passkey on an
[Android](https://www.corbado.com/blog/how-to-enable-passkeys-android) device using Chrome. Our objective was to
store and synchronize this passkey using the Google
[Password Manager](https://www.corbado.com/blog/passkeys-vs-password-managers) 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.
4.1.4 Use case 4: Windows Chrome passkey login
| Use case | Windows Chrome passkey login |
| ---------------- | ---------------------------------------- |
| Use case number | 4 |
| Device | HUAWEI MateBook X Pro |
| Operating system | Windows 11 Home 22H2 OS build 22621.1635 |
| Browser | Chrome 114 |
| Platform | Windows |
| Synced in | N/A |
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 GitHubs 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](https://www.corbado.com/blog/qr-code-login-authentication) that
appeared and successfully retrieved the passkey from use case 4.
## 6. GitHubs passkey detection feature and Conditional UI
### 6.1 GitHubs 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.
### 6.2 Conditional UI
Speaking of the automatic suggestion to log in with a passkey,
[Conditional UI](https://www.corbado.com/glossary/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](https://www.corbado.com/blog/shopify-passkeys) (see our analysis of
[Shopify passkeys](https://www.corbado.com/blog/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.
## 7. How Corbado can help
This whole analysis was done by hand. A handful of devices, a handful of browsers, a
tester walking through the login and writing down what happened. That is a fine way to
review somebody else's login. Running the same review on your own login every week is a
job for [Corbado Observe](https://www.corbado.com/observe), which reads it off your real traffic.
[Video: Device health](https://www.corbado.com/videos/features/device-health.mp4) ([See how Corbado Connect ships this](https://www.corbado.com/connect))
- The one real weakness section 3.2 finds in GitHub's rollout is the native app, where
login is pushed into a WebView. Device Health splits outcomes into web and app, ranks
devices, operating systems and OS versions against each other, and keeps a table of OS
versions that behave differently from the rest. An app path that performs worse than the
web path becomes a number you can act on, well before it becomes an app store review.
- Conditional UI is the feature section 6.2 rates highest, and whether your users get it
depends on what their browser supports.
[Client Capabilities](https://www.corbado.com/blog/webauthn-client-capabilities) charts conditional get and
[conditional create](https://www.corbado.com/blog/conditional-create-passkeys) as shares of your sessions,
alongside [platform authenticator](https://www.corbado.com/glossary/platform-authenticator) availability,
hybrid transport,
[related origins](https://www.corbado.com/blog/webauthn-related-origins-cross-domain-passkeys) and the signal
API, with application, touchpoint and OS as filters. Those six shares are counted on web
sessions, so the WebView login that section 3.2 singles out contributes nothing to them.
- GitHub's detection feature in section 6.1 is a guess about whether a passkey exists on
this device. Passkey Errors covers what happens when a guess like that is wrong. It
sorts failed ceremonies into groups tight enough that a wrong guess keeps its own group:
the same error name from a different step, or under a different UI pattern, does not
merge into it.
- The device and browser matrix in section 5 took manual testing to produce. The
Technology page gives you the operating system, OS version and browser mix behind your
own logins, so you know which combinations carry enough traffic to be worth a test run.
Read one limit into it before you plan from it: that page queries web sessions only, so
the app row of a matrix like this one, the row that carried the actual finding here, is
not in it. Device Health is where the app side of your traffic sits.
## 8. 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.
## Frequently Asked Questions
### How does GitHub's Conditional UI work and how does it compare to other platforms like Shopify or Microsoft?
GitHub enabled Conditional UI from the moment passkeys launched on July 12, 2023, unlike
[Shopify](https://www.corbado.com/blog/shopify-passkeys) and Microsoft which did not enable it immediately. It
uses the autofill function to automatically prefill stored passkeys the moment a user
clicks the username input field, removing the need to manually search for or enter
credentials.
### How does GitHub detect whether I have a passkey stored on my current device?
When a user visits GitHub, the browser requests a login fragment file from GitHub's
servers. GitHub uses the data in this file to determine whether a passkey has previously
been used on that specific device and browser, then conditionally surfaces a 'Sign-in with
a passkey' button beneath the standard sign-in button.
### Can I use passkeys in the GitHub mobile app or only on the website?
GitHub supports passkey creation and login in its native apps for both Apple and Android
devices. However, logging into the [native app](https://www.corbado.com/blog/native-app-passkeys) currently
routes through a WebView screen where credentials must be entered, so direct in-app
[passkey login](https://www.corbado.com/blog/passkey-login-best-practices) without a WebView step is not yet
available.
### What information does GitHub show me when I manage my passkeys in account settings?
In the 'Password and authentication' section, GitHub displays each stored passkey with two
badges: one indicating the browser-OS combination used to create it and one showing
whether the passkey is synchronized. Creation and last-retrieval timestamps are also shown
alongside the official passkey logo.
### Why does GitHub limit passkey setup to a pop-up after password login or the account settings page rather than during sign-up?
GitHub's [phased implementation](https://www.corbado.com/faq/gradual-rollout-support-passkey-adoption) approach
restricts passkeys to existing account holders logging in, not new sign-ups, in order to
start with low risk and gather feedback from early adopters. The two creation paths, a
post-login pop-up and manual setup in settings, help accommodate users who are unfamiliar
with passkeys while allowing GitHub to identify and fix bugs gradually.