FIDO2 Passkeys

What is a passkey?

A passkey is a modern, phishing-resistant credential that replaces traditional passwords. Passkeys are built on public key cryptography and can be stored on devices or security keys, enabling users to authenticate securely and seamlessly across applications and devices.

ADSelfService Plus supports FIDO2-based passkeys, following the open authentication standard developed by the FIDO Alliance. With WebAuthn integration, ADSelfService Plus enables passkey-based authentication for secure access to network resources.

ADSelfService Plus currently provides FIDO2 passkey authentication for the following:

• ADSelfService Plus portal logins
• Cloud application logins
• Machine logins (Windows, macOS, and Linux)
• VPN and RADIUS MFA when SecureLink Email Verification is enabled
• Outlook Web Access (OWA)
• Password resets or account unlocks from the ADSelfService Plus portal

How it works

FIDO2 passkeys are phishing-resistant credentials built on public key cryptography and integrated with ADSelfService Plus through the WebAuthn API. During enrollment, users register their passkey (security key or device passkey) with ADSelfService Plus by providing user verification (biometrics, PIN, or physical tap) on their authenticator. The authenticator generates a unique cryptographic key pair: the private key remains securely stored on the user's device or security key and never leaves it, while the public key is sent to and registered with ADSelfService Plus along with the Relying Party ID (RP ID).

When users authenticate, they verify their identity directly on their device or security key using biometrics, PIN, or a physical tap. The authenticator uses the private key to cryptographically sign a challenge and sends the signed response to ADSelfService Plus. ADSelfService Plus validates this response against the stored public key and grants access upon successful verification. This passwordless approach eliminates phishing risks since the private key never leaves the user's device and the authentication is bound to the specific domain (RP ID), preventing credentials from being used on fake websites.

Limitations

• Limited to machine logins and browser-based authentication: FIDO2 Passkeys currently does not support password resets and account unlocks via the ADSelfService Plus mobile app.
• Biometric authentication compatibility requirements: Biometric authentication via biometric security keys like YubiKey Bio Series devices requires browser or OS compatibility for biometric authentication. If neither the browser nor the OS supports biometric authentication during MFA, the YubiKey Bio device will automatically fall back to PIN-based authentication. For compatibility information, refer to the YubiKey documentation. For troubleshooting steps, see the troubleshooting page.

Prerequisites

Before configuring FIDO2 Passkeys, ensure the following requirements are met:

• Administrator privileges: Configuration can only be performed using ADSelfService Plus' default admin account or a product technician account with Super Admin privileges.
• WebAuthn-supported devices: Users must have devices that support WebAuthn to use FIDO2 passkey authentication.
• HTTPS configuration: ADSelfService Plus must have HTTPS enabled with a valid SSL certificate.
• Valid domain name: The access URL must be configured with a valid domain name, not an IP address.
• Certificate requirements:
  • A valid certificate should be deployed in ADSelfService Plus
  • The Common Name (CN) or Subject Alternative Name (SAN) on the certificate must match the hostname used in the ADSelfService Plus access URL.
  • If using an internal Certificate Authority (CA), the CA certificate must be trusted on all users' devices. Learn how to distribute certificates to users' machines.

Configuring FIDO2 Passkeys

FIDO2 passkeys let users authenticate with two types of authenticators:

• Security Keys
• Device Passkeys

Security Keys

These include portable FIDO2-compliant hardware security keys like YubiKey and Titan Security Key, that are removable and compatible with multiple platforms. These authenticators can be connected to a device via USB, NFC, or Bluetooth for secure authentication.

Device Passkeys

These authenticators are built into the user’s device and managed by the operating system. They verify the user’s identity using biometric or PIN-based credentials that are securely stored on the device. Examples include Windows Hello, Android biometrics, and Apple Touch ID or Face ID.

Device passkeys can be either device-bound or synced across multiple devices, depending on how the vendor has implemented it.

• Device-bound passkeys: These are passkeys that are stored only on the device and not synced to cloud services. This means users should enroll separately on each device they wish to use.
• Synced passkeys: These are passkeys securely stored in the cloud and synchronized across a user’s devices through cloud services such as iCloud Keychain or Google Password Manager. This synchronization allows seamless access to ADSelfService Plus without the need to re-enroll each device. However, user verification data, such as PINs and biometrics (including Face ID and Touch ID), remain device-specific and should be set up individually on each device. For example, if John uses Touch ID on his MacBook and then buys a new iPhone, he doesn’t need to re-enroll the iPhone in ADSelfService Plus, but should set up Face ID on the iPhone to authenticate.
• Mobile-based synced passkeys also support Cross-Device Authentication (CDA), enabling users to verify their identity on one device while accessing resources on another. For example, users can use their smartphone’s built-in authenticators, such as Android biometrics or Apple Face ID, to log into ADSelfService Plus on their laptop by scanning a QR code and establishing a Bluetooth connection.

Configuration steps

1. Log into the ADSelfService Plus admin portal and navigate to Configuration > Self-Service > Multi-factor Authentication > FIDO2 Passkeys > Modify.

1. The Relying Party ID should either be the domain name or effective domain name (server name or the parent domain of the server name) used in the access URL.

For instance, if the access URL is https://selfservice.example.com, only the following RP IDs are valid:

• selfservice.example.com
• example.com

Security caution: Specifying a parent domain in the RP ID allows FIDO2 passkeys to be used across the domain's subdomain websites as well. For instance, if example.com is chosen as the RP ID, then FIDO2 passkeys registered on site1.example.com can also be used on site2.example.com or site3.example.com. To allow FIDO2 Passkeys enrolled with ADSelfService Plus to authenticate only with the product, you can define the authentication scope by specifying the access URL used in ADSelfService Plus as the RP ID.

1. A Username Pattern helps prevent ambiguity by associating the user account with distinct attribute values in AD. It is an easily memorable and distinct username made in this pattern for the user account that will be registered with the FIDO2 passkey.
2. Open Advanced Settings and use the Allowed Passkey Types dropdown to configure the types of FIDO2 passkeys your users can enroll in.
   • Select Security Keys to permit users in your organization to enroll for passkeys like YubiKeys or Google Titan keys.
   • Select Device Passkeys to permit users in your organization to enroll for device-based passkeys that use the machine’s or phone’s built-in authentication methods, such as biometrics like fingerprint or facial recognition.
3. Enable the Deny syncable passkeys checkbox to ensure passkeys are tied to specific organizational devices and not synced across multiple devices through cloud services. This is ideal for organizations with security requirements to allow only device-bound passkeys.

1. From the drop-down menu, select whether User Verification is Required, Preferred, or Discouraged for security keys. User verification, such as a PIN or additional biometrics, provides an extra layer of security, ensuring that the security key is in the possession of authorized individuals. This is important because misplaced keys could be exploited by unauthorized users who find them.

• Required: The user will always be required to verify their identity using the built-in verification mechanism configured on the security key after inserting it.
• Preferred: If user verification, such as a PIN or biometrics, is configured on the security key, users will be prompted to verify their identity when the authenticator is inserted. If no verification method is set, users will not be asked for any identification.
• Discouraged: If your organization uses U2F-based security keys (Universal 2nd Factor security keys that do not support user verification, admins can select the Discouraged option. Users will not be asked for verification upon inserting their FIDO2 passkey. However, some security keys mandate verification on supported devices even when it is Discouraged. Please refer to the documentation received with your security key to ascertain this.

1. Specify the maximum number of passkeys each user can add in the No. of passkeys allowed per user field. Users can enroll up to five FIDO2 passkeys.
2. Click Save.

Supported devices

The OS and browsers that support each of the following types of passkeys are as follows:

Security keys

Security keys can be used across a wide range of operating systems and browsers, provided both the OS and browser meet the necessary requirements for WebAuthn support.

*The numbers within parenthesis indicate the minimum supported browser version required.

Device passkeys

Device passkeys are supported across a wide range of browsers and operating systems, with compatibility varying based on how the passkeys are accessed:

1. Device-bound passkeys:

*The numbers within parenthesis indicate the minimum supported browser version required.

2. Synced passkeys

*The numbers within parenthesis indicate the minimum supported browser version required.

3. Cross-Device Authentication

CDA client: The CDA client in a Cross-Device Authentication flow is the device on which ADSelfService Plus is being accessed.

CDA authenticator: The CDA authenticator in a cross-device authentication flow is the device used to verify their identity.

For example, you can use your phone as a cross-device authenticator to sign in to ADSelfService Plus from your laptop. In this case, the laptop is the CDA client, and the phone acts as the CDA authenticator.

The supported CDA clients and authenticators are as follows:

*The numbers within parenthesis indicate the minimum supported browser version required.

Supported FIDO2 passkeys for machine login scenarios

Endpoint MFA strengthens login security across user endpoints by enabling phishing-resistant FIDO2 passkeys. Before you enforce FIDO2-based machine logins, refer to the table below to understand which passkey methods are supported across different operating systems and machine login scenarios. For more details on MFA for endpoints, click here.

For login, unlock, and UAC scenarios, users can use a security key or their mobile phone. Mobile phones allow users to scan a QR code to open a secure link on their device and authenticate using built-in passkeys or security keys—no direct device-to-device connection (like CDA) is required. Note that mobile phones cannot be used for offline MFA.

For RDP sessions, FIDO2 authentication can be enabled on supported Windows clients and servers using Windows’ native WebAuthn redirection. On systems that do not support this feature—such as Windows versions older than 10 version 1809—you will need to use third-party USB-over-IP tools like IncentivesPro USB Redirector RDP Edition or Eltima USB Network Gate.

Supported client and server versions for Windows Hello:

• Client OS: Windows 10 version 1809 or later, or Windows 11
• Server OS: Windows Server version 1809, 2019, 2022, or 2025 and later

Enrolling FIDO2 passkeys

During enrollment, users can choose their preferred passkey type based on the options provided, such as security keys or device passkeys.

Security keys: The user will be required to authenticate using the security key’s built-in mechanism. For example, if using a YubiKey, they might need to enter a PIN or scan their fingerprint using the sensor. Security keys can be enrolled through the ADSelfService Plus web portal from a device that supports USB, near-field communication (NFC), or Bluetooth Low Energy (BLE) connections. A single security key can be enrolled as a passkey for multiple users, and multiple security keys can be enrolled for a single user account.

Device passkeys: The user will complete enrollment by verifying their identity using their device’s built-in authenticator, such as Face ID, Touch ID, or PIN.

• Device-bound passkeys: A device-bound passkey is stored only on the device where it was created. If users want to use the passkey on additional devices, they should enroll a new passkey on each device that supports device-bound passkeys.
• Synced passkeys: A synced passkey is stored in the cloud and automatically synchronized across the user's devices that are linked to the same account, using services like iCloud Keychain or Google Password Manager. Once synced, users do not need to enroll the passkey again on other devices that support synced passkeys.

If a user wishes to enroll a different smartphone or tablet, they can scan the QR code displayed on the screen to start the authentication process via Bluetooth. Admins should ensure that users' devices support CDA for a smooth enrollment process. A list of supported devices is available here.

You can find the step-by-step enrollment process for users here.

Verification using FIDO2 Passkeys

Once enrolled, users will verify their identity using their passkeys when signing in.

Security keys: Users should verify the security key on their device by connecting via USB, NFC, or BLE. Once verified, the key can be used on other devices by repeating the process. This ensures secure, consistent access across all devices.

Device passkeys: The device's built-in authenticators can be used for verification on the enrolled device. If the passkey is synced across multiple devices, it can also be used on those devices.

• Device-bound passkeys: Users should verify their identity on the same device where the passkey was enrolled. This could involve entering a PIN or using biometric authentication. If successful, the system will recognize the passkey and allow the user to login.
• Synced passkeys: When the passkey is synced across multiple devices linked to the same account, users can use it for MFA on any of those devices. The user can verify their identity using a built-in authenticator, and authentication is completed using the synced passkey, enabling a seamless login experience.

If a user needs to authenticate using a different smartphone or tablet, they can scan the QR code displayed on the screen to complete verification via Bluetooth.

You can find the detailed verification steps here.

Tips

1. Finalize configuration before deployment: Determine your access URL and RP ID before enabling FIDO2 Passkeys, especially for load-balanced or highly available deployments. Changing the access URL after users have enrolled will modify the RP ID, causing complete loss of all enrollment data and forcing organization-wide re-enrollment.
2. Choose the right RP ID scope: Use the full access URL (e.g., selfservice.example.com) as the RP ID to restrict passkeys exclusively to ADSelfService Plus. Only use the parent domain (e.g., example.com) if you intentionally want passkeys to work across multiple subdomains, but understand this broader scope creates security implications as passkeys enrolled on one subdomain can authenticate to others.
3. Configure fallback mechanisms for biometric security keys: For biometric security keys like the YubiKey Bio Series, ensure users configure PIN-based authentication as a fallback mechanism. Biometric authentication requires browser or operating system support; when accessing systems from older browsers or incompatible machines, the YubiKey Bio automatically falls back to PIN authentication, preventing lockouts while maintaining security.