Passkeys leave beta on GitHub

GitHub has made passkeys generally available for all users on GitHub.com. The passwordless, phishing-resistant sign-in method launched in beta in July, and tens of thousands of developers have since adopted it. The move supports GitHub’s broader push to secure all contributor accounts with two-factor authentication by the end of 2023.

You can register a passkey from your account security settings by selecting “Add a passkey.” If you have existing security keys that are compatible, you may see an “Upgrade” option next to them instead. Details on upgrading are in the passkeys documentation.

Rolling out passkeys to a mixed ecosystem

Passkeys are still a new credential type, and GitHub found that not every platform combination is ready for them. Linux and Firefox users, in particular, struggled because those platforms lack strong native passkey support. To accommodate them, GitHub enabled cross-device registration: you can register a passkey on your phone while using your desktop browser, with the credential stored on the phone.

Technically, that meant ignoring the result of the IsUserVerifyingPlatformAuthenticator API (IsUVPAA) call and relying solely on the presence of the WebAuthn APIs. That approach lets hardware keys—which don’t trigger a true result from IsUVPAA—and cross-device flows work even when the OS/browser combination would otherwise fail the check.

Upgrading security keys

GitHub’s initial assumption was that most hardware key owners would not want to upgrade to passkeys, given threat models and the lack of sync support. In practice, many users did choose to upgrade compatible security keys. During beta, GitHub added an “upgrade” arrow next to compatible keys in account security settings to streamline the process.

Upgrade a security key to a passkey using the “up” arrow in Account Settings

Not every compatible security key shows that button: GitHub only started checking for compatibility in late February. Some browser, OS, and key combinations also don’t support the re-registration flow used for upgrades, producing an error if GitHub tries to register a new passkey over the existing key. To handle that, the experience now includes troubleshooting tips that direct users to delete the previously registered security key and then register a fresh passkey.

Prompting adoption gradually

Because GitHub wants every account to have multiple 2FA credentials, it prompts users to register a passkey when they sign in from a compatible device that hasn’t yet been used with one. Early experiments ran that prompt on 100% of applicable sign-ins, but that surfaced a problem: users who already registered a passkey but weren’t yet using it regularly would get confused, attempt another registration, and hit failures.

The prompt to register a passkey if you don't have one yet but your device is compatible. You can create a passkey then, delay registration to later, or ask to never be asked on that device again.

That led GitHub to ramp the prompt up incrementally, tying its frequency to overall passkey usage growth rather than pushing it on every sign-in.

Cross-platform momentum

Passkeys only became viable once browser and OS vendors added support. Apple, Google, and Microsoft each filled gaps GitHub considered blockers. Microsoft Windows recently improved its OS-level passkey implementation to support cross-device access: you can use a phone-stored passkey to sign in to a website on a Windows machine through any browser, which matters for first-time sign-ins on new devices where no passkey yet exists. After signing in, you can create a passkey locally for future sessions.

On the browser side, Chrome 118 lets Chrome and Mac users access the iCloud keychain on Macs, so a passkey created on iOS and synced to a Mac works in Chrome. That kind of cross-ecosystem interoperability is essential for passkeys to function freely across services.