Configure Desktop MFA for Windows to use FIDO2 keys

Setting up a Passkeys (FIDO2 WebAuthn) authenticator allows users to securely sign in to their devices using a security key.

You can register these keys through the Admin Console, or the user can register their key in their Okta End-User Dashboard.

As an alternative, Yubico can deliver the YubiKey directly to new users, already pre-enrolled with the user's data and your org configuration.

PIN support

You can enroll FIDO2 security keys with or without a PIN. Whether Desktop MFA for Windows requires the PIN depends on the User verification setting that you choose for the Passkeys (FIDO2 WebAuthn) authenticator:

Discouraged: Enrollment doesn't ask for a PIN, and a key without a PIN still works. When the user signs in, Desktop MFA asks for the PIN only if the key has one.
Preferred: Enrollment asks for a PIN, but a key without one still works. When the user signs in, Desktop MFA asks for the PIN only if the key has one.
Required: Users must use a key that has a PIN. If a key was previously enrolled or used without a PIN while User verification was Discouraged or Preferred, and you then change User verification to Required, the Security key (USB) factor is still selectable, but the challenge fails with a Challenge failed error. The failure occurs during initialization, so the user is never prompted to tap the key. The user must verify their identity with a different authentication method.

If the key doesn't have a PIN and you enabled Desktop Password Autofill, and set User verification to Discouraged or Preferred, then Desktop Password Autofill asks for the system password instead.

If you plan to set User verification to Required, assign a PIN to every key in advance. This avoids a Challenge failed error for keys that users previously enrolled or used without a PIN.

If you enable User verification in your app sign-in policy, users can verify their identity with the FIDO2 key as long as you also enable User verification in the Passkeys (FIDO2 WebAuthn) settings.

To require a PIN, set the User verification to Required in both the Passkeys (FIDO2 WebAuthn) authenticator settings and in your app sign-in policy. See App sign-in policies.

Limitations

When configuring FIDO2 security keys for use with Desktop MFA for Windows, be aware of the following limitations:

FIDO2 security keys can't be used for offline authentication.
FIDO2 passkeys and biometric-only keys aren't supported.
FIDO2 platform authenticators aren't supported.

Note:

The Offline security key factor has the opposite PIN requirement. That factor uses OATH and doesn't support a PIN, so users can't enroll an offline security key if its OATH credential is PIN protected. Desktop MFA doesn't prompt for a PIN when a user verifies with an offline security key.

Tasks

Set up the Passkeys (FIDO2 WebAuthn) authenticator
Enable FIDO2 for the Desktop MFA client
Configure FIDO2 keys

Set up the Passkeys (FIDO2 WebAuthn) authenticator

To enable users to authenticate with a FIDO2 key, set up the Passkeys (FIDO2 WebAuthn) authenticator in the Admin Console.

In the Admin Console, go to Security > Authenticators.

If you already have the Passkeys (FIDO2 WebAuthn) authenticator added, you can't add another. Ensure that the settings for the existing Passkeys (FIDO2 WebAuthn) authenticator are appropriate for your org.
Click Add authenticator.
From the list of authenticators, click Add under Passkeys (FIDO2 WebAuthn).
On the General settings page, click Edit.
Under Settings, use the dropdown menu to select a User verification method. Review the content below the setting to learn more about what each user verification type does.

If the key has no PIN and you set the User verification method to Preferred or Discouraged, then Desktop Password Autofill asks for the system password. See PIN support.
Click Save.

After you set up the Passkeys (FIDO2 WebAuthn), individually configure your user accounts to use the keys. Users can also complete the registration themselves. See User registers a FIDO2 key.

Enable FIDO2 for the Desktop MFA client

Create a PowerShell script and use your MDM to deploy the registry keys to your endpoints. Note the individual storage locations of each registry key.

Registry Key Description

Registry Key	Description
Name: `AllowedFactors` Type: `REG_MULTI_SZ` Default: `*`	List of factors that users can authenticate with. Note: Store the `AllowedFactors` key at `HKLM\Software\Policies\Okta\Okta Device Access`. The `AllowedFactors` list requires that you also enable `UseDirectAuth`. Possible values for this setting: `*` - all factors are allowed. This is the same as setting this value to empty. `OV_Push` `OV_TOTP` `Offline_TOTP` `Offline_Security_key` `FIDO2_USB_key` `RSA_Token` `Offline_Fingerprint` `Offline_FaceBio` Ensure that the factors are spelled correctly. CAUTION: A user can be locked out of their computer if the factors included the `AllowedFactors` list don't match the factors shown to the user by the `OfflineLoginAllowed` and `OnlineLoginAllowed` registry settings.
Name: `PasswordlessAccessEnabled` Type: `REG_DWORD` Default: `0`	This value enables password autofill, allowing users to sign in to their device securely using non-password factors. Note: Store the `PasswordlessAccessEnabled` key at `HKLM\Software\Policies\Okta\Okta Device Access`. By default, password autofill is disabled (`0`). Password autofill supports Okta Verify Push, FIDO2 keys, or Windows Hello biometrics when you specify these as `AllowedFactors`. Desktop MFA always attempts to enforce user verification through the FIDO2 key PIN. If the key doesn't have a PIN, then Desktop MFA falls back to password authentication.
Name: `UseDirectAuth` Type: `REG_DWORD` Default: `0`	This value enables Desktop MFA users to authenticate with FIDO2 or RSA authenticators. Note: Store the `UseDirectAuth` key at `HKLM\Software\Okta\Okta Device Access`. By default, this setting is disabled (`0`). This value is required for Device-Bound Single Sign-On. Note: If the Okta username doesn't match the Microsoft User Principal Name (UPN), you can configure multiple identifiers on the user profile policies. This allows users to be identified with their UPN attribute. The steps to implement this workaround are available in this knowledge base article.

Name: AllowedFactors

Type: REG_MULTI_SZ

Default: *

List of factors that users can authenticate with.

Note:

Store the AllowedFactors key at HKLM\Software\Policies\Okta\Okta Device Access.

The AllowedFactors list requires that you also enable UseDirectAuth.

Possible values for this setting:

* - all factors are allowed. This is the same as setting this value to empty.
OV_Push
OV_TOTP
Offline_TOTP
Offline_Security_key
FIDO2_USB_key
RSA_Token
Offline_Fingerprint
Offline_FaceBio

Ensure that the factors are spelled correctly.

CAUTION:

A user can be locked out of their computer if the factors included the AllowedFactors list don't match the factors shown to the user by the OfflineLoginAllowed and OnlineLoginAllowed registry settings.

Name: PasswordlessAccessEnabled

Type: REG_DWORD

Default: 0

This value enables password autofill, allowing users to sign in to their device securely using non-password factors.

Note:

Store the PasswordlessAccessEnabled key at HKLM\Software\Policies\Okta\Okta Device Access.

By default, password autofill is disabled (0).

Password autofill supports Okta Verify Push, FIDO2 keys, or Windows Hello biometrics when you specify these as AllowedFactors.

Desktop MFA always attempts to enforce user verification through the FIDO2 key PIN. If the key doesn't have a PIN, then Desktop MFA falls back to password authentication.

Name: UseDirectAuth

Type: REG_DWORD

Default: 0

This value enables Desktop MFA users to authenticate with FIDO2 or RSA authenticators.

Note:

Store the UseDirectAuth key at HKLM\Software\Okta\Okta Device Access.

By default, this setting is disabled (0).

This value is required for Device-Bound Single Sign-On.

Note:

If the Okta username doesn't match the Microsoft User Principal Name (UPN), you can configure multiple identifiers on the user profile policies. This allows users to be identified with their UPN attribute. The steps to implement this workaround are available in this knowledge base article.

Configure FIDO2 keys

There are several ways that you can prepare a FIDO2 key for your users:

Register a FIDO2 key on behalf of a user.
A user registers their own FIDO2 key.
Use a pre-enrolled YubiKey.

Choose the registration method that works best for your org.

In the Admin Console, go to Directory > People.
Click a user to open their profile.
Click More Actions and choose Enroll FIDO2 Security Key from the list.
Insert the FIDO2 key into your computer and click Register.
Follow the prompts until you receive confirmation that the FIDO2 key has been successfully registered to the user.
Give the enrolled FIDO2 key to the appropriate user.

User registers a FIDO2 key

If a user receives a FIDO2 security key, they can register it using the Okta End-User Dashboard. Encourage your users to set up the security key with the appropriate settings for your org.

Sign in to the Okta End-User Dashboard.
Click your name in the upper-right corner and select Settings.
Under Security Methods, locate Security Key or Biometric Authenticator and click Set up another.
Verify your identity with one of the presented options, and then click Set up.
Follow the prompts to register the FIDO2 key to your Okta account.

After the user successfully registers the security key, they can verify their identity by inserting the FIDO2 key into the Windows device and following the on-screen prompts.

Note:

When users enroll the FIDO2 factor, they're limited to the org's URL. For example, if users enroll the FIDO2 factor on your orgname.okta.com URL, the factor only allows access to your org with that same orgname.okta.com URL. If users enroll the FIDO2 factor using the custom URL for your org, the factor only allows access to your org with the custom URL.

Admins must configure Desktop MFA to use the same domain where users have enrolled the FIDO2 authentication factor.