Release Notes

This section contains release notes for the FIDO Connector and related APIs, including feature updates, enhancements, resolved issues, and known limitations. The changes reported in the release notes are cumulative.

---

2026

Release 2.0.1 (15 June 2026)

New Features & Enhancements

• Serial number in Logic App: A yubikeySerial field has been added to the payload sent from the FIDO Connector to the Logic App, allowing for the serial number to be included in the PIN email. The field is separate from the existing yubikeyDisplayName field, which remains as-is. As part of this enhancement, yubikeySerial has also been added to the Logic App’s request body schema, for usage in the email template.

• Shipment ID and Credential ID in Logic App: The ShipmentId and credentialRequestId fields have been added to the payload sent from the FIDO Connector to the Logic App, including the following:

  • shipmentId for v1 FPR Shipments and v2 Credential requests (with shipment).
  • credentialRequestId for v1 and v2 Credential requests.

  The resend-pin endpoint also includes these fields. See Create Credential Request.

• Validation of single IdP configuration: Validation has been added to check if the idp.default property for a single-IdP instance is mapped to an acceptable value of the IdP implementation, when starting the FIDO Connector.

• Cleanup of non-completed shipment records: A new configuration parameter - CRON_DATA_CLEANUP_PENDING_DAYS, has been added to the environment variables allowing for stale records to be purged from the Azure Storage Table and Azure Key Vault. See Environment Variables.

• Multi-IdP configuration file loading: The ARM Template has been updated with the multi-idp-configuration-style parameter for choosing the method to load the multi-IdP configuration YAML file into the FIDO Connector, when enabling multi-IdP support. The parameter accepts the values “none” (default), “volume-mount”, or “blob-storage”. See Enabling Multi-IdP Support.

• Multi-IdP ARM template parameters: The new parameters defaultIdentityProvider and ShouldUseMultiIdp have been added to the ARM template. defaultIdentityProvider defines the primary identity provider for the application. ShouldUseMultiIdp determines whether the application is configured via environment variables only, or pulls configuration from an external file.

Release 2.0.0 (15 June 2026)

New Features & Enhancements

• Create credential request (v2): Implementation of the POST v2/credential-requests endpoint for multi-IdP/ multi-credential/ multi-key support. The endpoint creates a request for one or more credentials on one or more IdPs. The request might also include shipments of one ore more physical keys, in which case the response includes the shipment_id. See Create Credential Request.

• Get credential request by ID (v2): Implementation of the GET v2/credential-requests/{credential_request_id} endpoint for multi-IdP/ multi-credential/ multi-key support. The endpoint returns the status of pre-programmed credentials, both programmed by Yubico as well as programmed on-site by trusted agents. See Get Credential Request by ID.

• Credential request activation: The POST /v2/operations/process-credential-requests endpoint has been added to the FIDO Connector API for triggering credential activation. See Process Credential Request.

• Multi-IdP support: Multiple IdPs can be configured through a YAML file that can be stored and edited, either using Azure Blob Storage, or by uploading the file to the Azure Blob Storage Container via a volume mount. The ARM template has been updated to include Blob Storage for the multi-IdP YAML configuration file. Validation has been added to check if the idp.default property is mapped to one of the provided IdPs. See Multi-IdP Support.

• Updates to credential request fields for optional/required: recipient.telephone (required), shipment.mailing_address.region (optional), recipient.external_id (optional), shipment.customer_reference (optional), .shipment_items[*].name (optional, default “Pre-Reg YubiKey”), authenticators[*].name (optional, default “Pre-Reg YubiKey”). See Create Credential Request.

Release 1.2.10 (15 June 2026)

New Features & Enhancements

• Authentication with YED-API secret: Previously, the different Yubico services used different authentication secrets. Functionality has been updated so that the YED-API secret is now used to authenticate to all services. See Authentication.

• Credential request retry configuration: The configuration for the number of days a credential request will keep retrying after a first failure is now done through the parameter CRON_PROCESS_CREDENTIAL_REQUESTS_RETRY_NUMBER_DAYS. See Environment Variables.

• Credential request resend PIN email: A new endpoint has been added to v1 of the FIDO Connector. The POST /v1/credential-requests/{credential_request_id}/resend-pin endpoint will resend a PIN if this exists for a credential request.

Resolved Issues

• Resend PIN emails: The functionality has been enhanced so that the user IDs listed in the PIN email are now sent as a comma-separated list of non-URL encoded userId.

• Credential request PIN email sending: Previously, when credentials for a request were registered, the credential request state was updated to processed even if sending the PIN email failed. This issue has been resolved. If sending the PIN email fails, then the credential request state remains as processing until the PIN email is successfully sent.

Release 1.2.8 (6 May 2026)

New Features & Enhancements

• Authenticator name for PingOne AIC: To make it easier for recipients to identify an authenticator, support has been added for providing a custom authenticator name when using PingOne AIC as IdP. If a custom authenticators.name is provided, all characters must be ASCII and the field length must not exceed 18 characters.

  If the authenticator is of type “hardware”, the authenticator name together with the YubiKey serial number will be displayed in the IdP. For example, “KeyName: 12345678”. If a custom name is not provided, the default name "Pre-Reg YubiKey: {SERIAL}” is displayed.

Release 1.2.7 (16 April 2026)

New Features & Enhancements

• Support for remote pre-programming: The FIDO Connector has been updated to allow remote FIDO Pre-reg programming of YubiKeys by default. Remote pre-programming enables enrollment of YubiKeys by trusted users that securely program credentials on a YubiKey outside of Yubico premises.

• PingOne AIC credential activation: In order for the FIDO Connector to support PingOne AIC (Advanced Identity Cloud), a Ping AIC activate credential method has been implemented. This method registers the credentials, and is called by either the activation routine, or the endpoint.

• Retry logic for activating credentials: Retry logic has been added in case of failure when registering a YubiKey for an end user account. During the credential activation, if registering the YubiKey fails and the PingOne AIC Journey has returned a new AuthId, the retry logic will use that new AuthId in the retry operation.

• Support for end-user provided PIN: Functionality has been added allowing an end user to provide their own PIN in the remote credential issuance workflow, to avoid sending the PIN via email. In the intended scenario, an IT Admin is processing the credential request with the end user in the same location. If end-user provided PIN is enabled, the enrollment flow will display a prompt, and the device is handed over to the end user who enter their PIN.

• PingOne AIC default relying party options: Functionality has been added to make the PingOne AIC default relying party an optional configuration. If credentials.relying_party_id is present in the request, then this will be used. Otherwise, if the PingOne AIC default relying party is configured in the FIDO Connector through the PING_AIC_DEFAULT_RELYING_PARTY environment variable, then this will be used. If non of these are provided, the Journey’s Relying-Party Identifier configuration is used.

API updates in this release:

• To support end-user provided PIN, a PinEntryMethod parameter to indicate whether the credential request allows a PIN to be entered, has been added to the FIDO Connector API. The value is received by the FIDO Connector, which will let the user enter their PIN in the mobile device if the value is set to “user_entered”. If the value is set to “generated”, the end-user provided PIN option will not be displayed in the mobile device, and the PIN will be auto-generated.

• The following new APIs are used to create and process credential requests:

  • Create Credential Request
  • Get Credential Request by ID
  • Process Credential Request

  Note

  The current APIs to request shipment of FIDO pre-enrolled YubiKeys remain the same, if you also want to benefit from the Yubico Delivery service. For more information, see Create Shipment Request.

Release 1.2.3 (23 February 2026)

Resolved Issues

• Processing of shipments in Delivery Exception state: Previously, shipments in the Delivery Exception state (106) were treated as an error, causing the job to skip them. This resulted in delays in registering the YubiKey to the user’s account, as the next registration attempt was only made once the YubiKey was marked as Delivered. This issue has been resolved. The Delivery Exception state is treated as a valid status, indicating a delivery delay where the shipment is still expected to be delivered.

• Delegated subnet issue: An issue was reported where during deployment of the FIDO Connector, an error message “The environment network configuration is invalid: The delegated subnet cannot be used by any other Azure resources.” was received. Azure Container Apps require subnet delegation when the “Environment Type” is set to “Workload Profiles”. Azure has recently started to set this as the default. To resolve this issue, the deployment template has been modified to include the required subnet delegation.

2025

Release 1.2.0 (3 November 2025)

New Features & Enhancements

• Passkey name in FIDO Pre-reg calls: To make it easier for recipients to identify a passkey, a yubikey_name field has been added to the POST /v1/fpr/shipments request. The passkey name together with the YubiKey serial number is displayed in the IdP.

  The field is optional. If a custom name is not provided, the default name Pre-Reg YubiKey: {SERIAL} is displayed. If a custom name is provided, all characters must be ASCII and the field length must not exceed 18 characters. See Create Shipment Requests in the API Reference.

• Configurable IdP service: In order for the FIDO Connector to work with multiple IdPs, support has been added for configuration of IdP-specific application properties. The IdP to be used is set through properties that can be overridden by an environment variable (IDP_DEFAULT). Currently the supported IdPs are Microsoft Entra ID (property value set to entraid) and PingOne (property value set to pingone). If no value is set for the environment variable (IDP_DEFAULT), the FIDO Connector will use entraid as the default.

• Passkey name provided in PIN email: To make it easier for recipients to identify passkeys, functionality has been added to provide the passkey name together with the PIN in the email sent to recipients. The payload sent to the Azure Logic App providing the email now includes a new field yubikeyDisplayName, which is the authenticator display name. The email also includes the serial number of the YubiKey.

• PingOne Object_Id (username) as user_id: As part of the added FIDO Connector PingOne support, functionality has been added to verify that the user_id used is a GUID, when creating the MFA User Device on PingOne. If the value is not a GUID, it is handled as an Object_Id, and the GUID user ID for it is retrieved from the PingOne endpoint /environments/{environments}/users. The user_id is then saved as the GUID value.

• Email sending of PIN to recipient: The Logic App, which controls the sending of the PIN emails, has been updated to support more IdPs. It is now used only to send emails and does not contain any IdP-specific logic. By default the email sender Logic App is configured to send PIN email to “recipient_email” provided in the POST /v1/fpr/shipments request.

  The POST /v1/fpr/shipments request also has a new enrollment_contacts.emails_to field which takes a list of strings with email addresses to which the PIN can be sent. Using the "enrollment_contacts" object is optional for every IdP implementation. When using this method, the default Send Shipment Pin Azure Logic App must be appropriately modified to use emailsTo. See Create Shipment Requests in the API Reference.

• Matching authentication method display names: Functionality has been added to the FIDO Connector to match the “YubiKey Display Name”, sent in the PIN email, with the Auth Methods “Nickname” available in PingOne.

• Email functionality: The default Logic App functionality has been updated to send the PIN email to the email addresses received in the new emailsTo list. If no email addresses are provided, sending the PIN email will fail. As part of this, the ARM template has also been updated to support the Logic App updates.

Resolved Issues

• Resending PIN not possible: An issue was reported where it was not possible to resend the PIN due to issues with the Logic App. The credentials were activated but the shipment request remained in state “Ongoing”. In this case, the PIN resend functionality expects the state to be “Complete”. This issue has been resolved, and resending a PIN now works as expected.

Release 1.1.6 (16 October 2025)

New Features & Enhancements

• Expiration date for Azure Key Vault secrets: A default expiration date has been set for Key Vault secrets in order to align with policies requiring an expiration date. When creating a Key Vault secret, the FIDO Connector will set SecretProperties setExpiresOn(OffsetDateTime expiresOn) to 45 days. This value can be changed in the Azure portal. For more information, see Key Vault - Secrets (Microsoft documentation).

Release 1.1.4 (22 August 2025)

New Features & Enhancements

• Get user using UPN (User Principal Name): Previously, in the JSON request the user_id was provided as Object ID. To enhance the user experience, the input now allows user_id to be provided either as Object ID, for example "user_id": "123456-abc-123456-xyz", or as UPN, for example "user_id": "username@yubico123.sample.com".

• Connector container app version: Functionality has been updated to show the application version. /v1/status now returns the "FIDO_CONNECTOR_VERSION": "string" field displaying the version of the FIDO Connector application software.

Resolved Issues

• Connector API response: Previously the API was returning a “500 Internal Server Error” message, for example when an invalid YubiEnterprise API token was used. To provide more guidance to the user, the error message has been changed to show a “401 Unauthorized” error message instead.

Release 1.1.1 (25 June 2025)

New Features & Enhancements

• PIN length changed to 4-63. The validation in the API accepts a PIN length value between 4 to 63, inclusive. This means you can enter any number from 4 up to 63 (including either 4 or 63) as PIN length. See API Reference.

• Support for address validation override. An address_validation_bypass flag (true/false) has been added to the API. If set to “true”, the API will accept the provided address without further validation. See Address Validation.

Release 1.0.0 (3 April 2025)

First release of the Yubico FIDO Connector App. The application is deployed to a Microsoft Azure subscription and handles most of the Customer Orchestration complexities. For more information about included features, see Yubico FIDO Connector App.