gitlabFeb 25, 2026

Passkeys now available for passwordless sign-in and 2FA on GitLab (opens in new tab)

GitLab now supports passkeys for passwordless sign-in and phishing-resistant two-factor authentication. Built on WebAuthn and public-key cryptography, passkeys let users authenticate with a fingerprint, face recognition, or device PIN while keeping the private key on their device. Users can register multiple passkeys across browsers, mobile devices, and FIDO2 security keys, improving both security and convenience. ## Passkeys for Sign-In and 2FA - Passkeys can be used: - As a passwordless login method. - As a phishing-resistant 2FA method. - For accounts with 2FA enabled, passkeys automatically become the default 2FA option. - Authentication uses a device fingerprint, facial recognition, or PIN. ## Registration and Compatibility - Users can register passkeys under **Profile settings > Account > Manage authentication**. - Supported platforms include: - Chrome, Firefox, Safari, and Edge. - iOS 16 and later. - Android 9 and later. - FIDO2 hardware security keys. - Multiple passkeys can be registered for access across different devices. ## WebAuthn Security Model - Passkeys rely on WebAuthn and public-key cryptography. - The private key remains securely stored on the user’s device and is never sent to GitLab. - GitLab stores only the public key. - A breach of GitLab’s stored credentials would not give attackers usable private keys for account access. ## GitLab’s Security Goals - Passkeys support GitLab’s commitment under the CISA Secure by Design Pledge. - They help increase MFA adoption while providing a smoother, phishing-resistant authentication experience. - GitLab invites users to provide feedback through its community and feedback channels. Users should register passkeys in their GitLab authentication settings, ideally across multiple trusted devices or security keys for both stronger protection and account recovery.

webauthngitlabdevsecopssecurity+4

metaFeb 4, 2026

No Display? No Problem: Cross-Device Passkey Authentication for XR Devices (opens in new tab)

Passkeys provide phishing-resistant authentication, but standard cross-device flows depend on QR codes displayed on the device being authenticated. This creates a problem for XR headsets, smart-home hubs, sensors, and other devices with no accessible screen. The proposed solution uses an authenticated companion app to transport the FIDO hybrid-flow request, preserving proximity, trust, and standard WebAuthn security without requiring a QR code. ## The Challenge: Screenless Devices Cannot Display QR Codes - Traditional cross-device passkey authentication uses: - A QR code displayed by the desktop or other target device. - Bluetooth or NFC to verify proximity and establish communication. - Devices without usable displays cannot show a QR code for a phone to scan. - Proximity discovery alone is insufficient because users still need a clear, secure way to approve the correct authentication request. ## Companion Apps as Secure Message Transport - The target device generates the same hybrid-flow request normally encoded in a QR code. - Instead of displaying it, the device sends the request to an authenticated companion app associated with the same user account. - In-app notifications provide a user-consent surface and direct the user into the passkey flow. - Opening the app itself can initiate the flow because the user must deliberately open it, and mobile operating systems provide an additional verification step. ## Meta Quest and Meta Horizon Implementation - The implementation is broadly available on Meta Quest devices running Meta Horizon OS. - The Quest browser creates a FIDO URL containing: - A fresh ECDH public key. - A session-specific secret. - Routing information for the hybrid handshake. - The URL is packaged as structured data in a GraphQL-based push notification. - The Meta Horizon app validates that the request belongs to the correct signed-in user before processing it. ## Notification and Deep-Link Flow - iOS or Android displays a notification that a passkey login is pending. - Tapping the notification opens the Meta Horizon app, which launches the FIDO URL through the operating system. - The OS then invokes its passkey interface. - If notifications are disabled, opening the app queries the backend for pending requests. - Requests expire after five minutes, limiting the window for misuse. - The mobile device then performs the normal hybrid transport process: - Broadcasting a BLE advertisement. - Establishing an encrypted tunnel. - Generating the passkey assertion. ## WebAuthn Challenge and Response - The inaccessible device creates the normal WebAuthn challenge and waits for a response. - The mobile authenticator initiates the secure BLE or NFC connection. - The challenge travels through the encrypted channel. - After successful user verification, the phone creates an `AuthenticatorAssertionResponse` or `AuthenticatorAttestationResponse`. - The inaccessible device forwards that response to the relying-party server just as a display-equipped device would. ## Broader Impact - The approach removes the QR-code requirement while retaining FIDO hybrid transport and proximity protections. - It could extend passwordless authentication to: - XR headsets and wearables. - Screenless IoT devices. - Smart-home hubs. - Industrial sensors and hardware. - The work builds on FIDO Alliance standards and mobile operating-system support, helping broaden interoperability across device ecosystems. The companion-app model offers a practical way to bring secure cross-device passkeys to devices that cannot display QR codes. It is especially suitable where the device already has an authenticated mobile app and can rely on standard WebAuthn, BLE/NFC proximity, and platform user verification.

webauthngraphqlpasskeysiot-security+4