Okta Error Occurs When Enrolling A YubiKey With User Verification Discouraged and Authenticator Group Allowlist Enabled

When an end user enrolls a physical Fast ID Online 2 (FIDO2) security key in Okta Identity Engine (OIE) with an Authenticator Group allowlist enabled, an error occurs if the key contains a Personal Identification Number (PIN) and the Okta Authenticator Enrollment policy uses the Discouraged User Verification setting along with create passkeys disabled. This configuration causes the browser to downgrade the connection to the legacy Universal 2nd Factor (U2F) protocol, which transmits an all-zeros Authenticator Attestation Globally Unique Identifier (AAGUID) that fails the Authenticator Group allowlist check. Resolve this by adjusting the User Verification settings in the Okta Admin Console or by deploying factory-reset keys without a PIN. End users encounter the following error on the Okta Sign-In Widget during enrollment:

Your organization does not allow this authenticator.

The Okta System Log records a user.mfa.factor.activate failure with the reason User failed to set up FIDO_WEBAUTHN factor and an incoming AAGUID of 00000000-0000-0000-0000-000000000000.

• Okta Identity Engine (OIE)
• Fast ID Online 2 (FIDO2) Authenticators
• YubiKey

A client-side browser protocol downgrade triggers this issue. When Okta requests userVerification: "discouraged", the browser receives instructions not to prompt for biometric or PIN verification. If a security key already contains a FIDO2 PIN, the modern Client to Authenticator Protocol 2 (CTAP2) cannot perform credential creation without verifying the PIN. To satisfy the instruction to avoid a PIN prompt, web browsers automatically downgrade the connection from CTAP2 to the legacy Client to Authenticator Protocol 1 (CTAP1) or FIDO U2F protocol. The legacy U2F standard does not support hardware AAGUIDs and outputs an all-zeros AAGUID. Because the Authenticator Policy restricts enrollment to specific hardware AAGUIDs via an Authenticator Group, Okta evaluates the incoming all-zeros AAGUID against the allowlist, finds no match, and rejects the enrollment.

When Okta enables Create passkeys on the FIDO2 (WebAuthn) Authenticator, Okta requests a discoverable credential. The FIDO CTAP 2.1 specification mandates PIN protection for resident credentials stored in hardware memory. Even if the administrator selects the Discouraged User Verification setting, the browser or operating system forces the creation of a PIN if the key lacks one. Clearing the Create passkeys checkbox allows standard non-resident credential creation where PIN-less enrollment is possible.

Review the following table to understand how different User Verification settings affect the enrollment behavior based on the presence of a PIN.

Review the following examples of enrollment behavior using a YubiKey 5 Federal Information Processing Standard (FIPS) with Near Field Communication (NFC) that an Authenticator Group named yubikey restricts.

Example 1: Key with a PIN and Enrollment Discouraged

• Configuration: The administrator selects the Discouraged User Verification setting and clears the Create passkeys checkbox.
• Key State: The key contains a configured PIN.
• Browser Action: The browser downgrades to legacy U2F to suppress the PIN prompt.
• System Log Output:

"outcome": {
  "result": "FAILURE",
  "reason": "User failed to set up FIDO_WEBAUTHN factor"
},
"debugContext": {
  "debugData": {
    "aaguid": "00000000-0000-0000-0000-000000000000",
    "matchedAuthenticatorGroups": ""
  }
}

Result: The all-zeros AAGUID fails the allowlist check because it does not match the yubikey group.

Example 2: Key without a PIN and Enrollment Discouraged

• Configuration: The administrator selects the Discouraged User Verification setting and clears the Create passkeys checkbox.
• Key State: The key remains in a factory-reset state without a configured PIN.
• Browser Action: The browser negotiates modern CTAP2 with User Presence only.
• System Log Output:

"outcome": {
  "result": "SUCCESS",
  "reason": "User set up FIDO_WEBAUTHN factor"
},
"debugContext": {
  "debugData": {
    "aaguid": "c1f9a0bc-1dd2-404a-b27f-8e29047a43fd",
    "matchedAuthenticatorGroups": "yubikey"
  }
},
"target": [
  {
    "displayName": "YubiKey 5 FIPS with NFC",
    "detailEntry": {
      "aaguid": "c1f9a0bc-1dd2-404a-b27f-8e29047a43fd",
      "methodUsedVerifiedProperties": "[USER_PRESENCE, DEVICE_BOUND, PHISHING_RESISTANT, HARDWARE_PROTECTED]"
    }
  }
]

Result: The key transmits the genuine hardware AAGUID, matches the yubikey group, and succeeds with hardware-protected assurance.

Example 3: Key without a PIN and Create passkeys enabled

• Configuration: The administrator selects the Discouraged User Verification setting and selects the Create passkeys checkbox.
• Key State: The key remains in a factory-reset state without a configured PIN.
• Browser Action: The browser prompts the end user to create a PIN for the security key.
• Explanation: CTAP 2.1 mandates that discoverable resident credentials require PIN protection in hardware storage, which overrides the discouraged hint from Okta.

How is the User Verification configuration adjusted for keys with a PIN?

Adjust the User Verification settings in the Okta Admin Console to allow a one-time PIN during setup and bypass the PIN during multifactor authentication (MFA).

1. In the Okta Admin Console, navigate to Security > Authenticators.
2. Locate FIDO2 (WebAuthn) or Passkey and select Actions > Edit.
3. Under User Verification, set Enrollment to Preferred or Required.
4. Set Authentication to Discouraged.
5. Select Save.

Configuration for a zero-PIN fleet deployment.

Configure the Authenticator settings for a completely PIN-less deployment by disabling passkey creation and setting all User Verification options to Discouraged.

1. In the Okta Admin Console, navigate to Security > Authenticators.
2. Locate FIDO2 (WebAuthn) or Passkey and select Actions > Edit.
3. Clear the Create passkeys checkbox to enroll standard non-resident WebAuthn credentials.
4. Under User Verification, set Enrollment to Discouraged.
5. Set Authentication to Discouraged.
6. Select Save.
7. Verify that all security keys remain in a factory-default state without an initialized FIDO2 PIN before distribution.