5.8 Firmware Specifics

This section describes features enabled by the 5.8 firmware. For additional details specific to supported protocols, see Protocols and Applications. This firmware update is a toolkit expansion for developer authentication workflows, see Yubico’s YubiLab GitHub Repository Build with Us.

• The 5.8 firmware for the YubiKey 5 Series has a number of new and improved FIDO2 features that are available for the first time on the multi-protocol YubiKey 5.
• YubiKey 5.8 supports all of the capabilities of YubiKey 5.7.4 and expands the use of passkeys specific for developer and platform use cases.
• There have been no material changes to the other protocols, such as PIV and YubiOTP in firmware 5.8.

5.8 Features Summary

YubiKey 5.8 firmware enables hardware-backed root of trust for secure digital identity and financial transactions, including privacy-preserving, human-in-the-loop authorization, and passkey-based signatures.

In addition to the YubiKey 5 Series, the features and capabilities listed in the table below, apply to both Enterprise and non-enterprise editions of the Security Keys Series, and both Multi-Protocol and FIDO editions of the YubiKey Bio Series, unless otherwise indicated.

YubiKey 5 Series Firmware 5.8 capabilities

Firmware 5.8 Capabilities CTAP 2.3, where noted	YubiKey 5 (Std, CCN)	YubiKey 5 Enhanced PIN	Security Key Series	YubiKey Bio Series
Secure payments, Document Signing, Digital Wallets, Credential, Agentic approval
Secure Payment Confirmation (SPC)	Yes	Yes	Yes	Yes
Third-party payment CTAP extension thirdPartyPayment	Yes	Yes	Yes	Yes
WebAuthn Signing Extension previewSign (Preview only)	Yes	Yes	Yes	Yes
Asynchronous Remote Key Generation (ARKG)	Yes	Yes	Yes	Yes
Pseudo-Random Function (PRF) support
MakeCredential CTAP extension hmac-secret-mc	Yes	Yes	Yes	Yes
Enterprise Credential Management, Multiple Environments
Persistent Credential Management Read Only (PCMR) CTAP pinUvAuthToken permission	Yes	Yes	Yes	Yes
Persistent PIN User Access Token (PPUAT)	Yes	Yes	Yes	Yes
Enroll YubiKey through Enroll app (LEA)	Yes	Yes	Yes	Yes
FIDO over Chip Card Interface Device (CCID), USB & smart card SCP11b secure channel	Yes	Yes	Yes	Yes
YubiHSM Auth credential editing	Yes	Yes	–	–
Conditional Mediation for Security Keys
CTAP authenticatorGetInfo API encCredStoreState	Yes	Yes	Yes	Yes
CTAP authenticatorGetInfo API encIdentifier	Yes	Yes	Yes	Yes
PIN and User Verification
CTAP authenticatorGetInfo API maxPINLength	Yes	Yes	Yes	Multi-Protocol Edition only
CTAP authenticatorGetInfo API pinComplexityPolicy	Yes	Yes	Yes	Yes
CTAP authenticatorGetInfo API pinComplexityPolicyURL	Yes	Yes	Yes	Yes
CTAP authenticatorGetInfo API uvCountSinceLastPinEntry	–	–	–	Yes
YubiKey Reset Discovery
CTAP authenticatorGetInfo API longTouchForReset	Yes	Yes	Yes	Yes
CTAP authenticatorGetInfo API transportsForReset	Yes	Yes	Yes	Yes
Enterprise Attestation: RPID storage, Multiple IdPs, Post-Quantum Cryptography (PQC)
Enterprise Attestation RPIDs from 2 to 16.	Yes	Yes	Enterprise Edition only	Yes
CTAP authenticatorGetInfo API attestationFormats	Yes	Yes	Enterprise Edition only	Yes
CTAP authenticatorMakeCredential API attestationFormatsPreference	Yes	Yes	Enterprise Edition only	Yes

Note

1. YubiKey FIPS series remains on the NIST 140-3 validated firmware version 5.7.4. This means that YubiKeys on 5.8 are not FIPS keys, though they share the cryptographic module major functions.
2. Security Key Series - Enterprise Edition and Yubico Bio Series - Multi-Protocol Edition, both require subscription with YubiKey as a Service.
3. ARKG-related previewSign code and test utilities are experimental. Do not use this for production cryptographic guidance.
4. As of YubiKey 5.8, YubiHSM Auth credential can be changed without deleting it, then recreating it.

CTAP 2.3 Features

The Client to Authenticator Protocol (CTAP) 2.3 update enhances YubiKey functionality by improving user experience, enterprise scalability, and platform integration. Key benefits include streamlined passkey workflows with Conditional Mediation, seamless PRF-based credential management, support for Secure Payment Confirmation, expanded RPID storage for enterprises, and improved PIN management and security features. See the FIDO Alliance CTAP FIDO2 Specifications for authenticator API descriptions. See also, .NET YubiKey SDK: YubiKey API reference.

By implementing CTAP 2.3, Yubico addresses key customer challenges across user experience, enterprise credential management, and modern workflows like payments and wallet integration.

These features deliver:

• Simplified UX: Seamless passkey workflows, reducing friction for end-users.
• Enterprise Scalability: Increased flexibility and ease of management for complex enterprise environments.
• Future-Ready Innovation: Support for emerging standards like PRF-based wallets and Secure Payment Confirmation.
• Improved Security and Integration: Enhanced platform features and PIN management workflows, ensuring long-term usability and security.
• Long touch for Reset: user setting of long touch reset allowing the user to enable long touch for reset if it is disabled by default (in our case it is a prepers only option and off by default). See Long touch for Reset.
• PIN Complexity Extension: pinComplexityPolicy extension. See PIN Complexity Extension (pinComplexityPolicy).

Attestation Formats

YubiKey Firmware 5.8 with CTAP 2.3 supports a post-quantum enabled ecosystem, attestationFormatsPreference option in authenticatorGetInfo. This allows greater control and flexibility in determining the capabilities of authenticators. Currently more of a future proofing feature, it allows potential expansion as alternate attestation formats become available.

attestationFormats (0x16) communicates supported attestation formats, enabling platforms to prepare for future features like post-quantum cryptography (PQC). Allows us to skip doing attestation signatures that the platform then strips if format = none.

See CTAP 2.3 authenticatorGetInfo.

See Enterprise Attestation with FIDO 2.

Conditional Mediation for Security Keys

The YubiKey 5.8 contains a number of Client to Authenticator Protocol (CTAP) 2.3 features that can collectively be used to enable conditional mediation for credentials that are stored in security keys, instead of software-based passkey providers. Use cases include:

• Enable platforms to list credentials stored on currently connected hardware security keys during conditional mediation for passkeys.
• Enable platforms to cache credentials, that have been previously used to successfully authenticate to a specific relying party (RP), to list credentials stored on known hardware security keys during conditional mediation for passkeys, without storing identifiers that can be used to identify or correlate security keys.

CTAP APIs include:

• encCredStoreState
• encIdentifier
• encIdentifier (0x19)

By implementing these CTAP 2.3 and YubiKey firmware 5.8 options, platforms can deliver a much smoother user experience, reducing the number of user interactions needed, while mitigating tracking, as well as expanding options for safe credential selection and identification, without granting the ability to delete credentials.

Platforms and applications can enumerate the credentials on a hardware key without risk of deletion and reduce the number of authentication events required, allowing IDPs and Password Managers to deliver a smooth flow between applications and services.

See CTAP authenticatorGetInfo.

encCredStoreState

Introduces an indicator in GetInfo that allows the platform to know if the state of the credentials on the key have changed since the last time that they were cached. This allows platforms a method for checking if the credential has changed when they use Persistent PIN User Access Token (PPUAT) to enable autofill and secure payment confirmation flows.

The value is a byte value containing iv || ct.

Where:

ct is the AES-128-CBC encryption of (128-bit credential store state) using HKDF-SHA-256:

• salt = 32 zero bytes
• IKM = persistentPinUvAuthToken
• L = 16
• info = “encCredStoreState”

iv The encryption iv must be regenerated for each output of GetInfo

encIdentifier

• Provides a stable, device-unique identifier to a platform but it is always encrypted with a per-device secret (persistentPinUvAuthToken) to prevent cross-origin tracking. Each time GetInfo is called, the authenticator returns a value that changes. A platform with a valid Persistent PIN User Access Token (PPUAT) can validate this value, confirming its authorization.
• Returned in GetInfo as part of support for conditional mediation with hardware authenticators.

encIdentifier (0x19)

The GetInfo feature supports privacy-preserving cached credential management, helping platforms identify the correct authenticator without persistent tracking.

Persistent PIN User Access Token (PPUAT)

YubiKey Firmware 5.8 with CTAP 2.3 provides a new type of access token that can be acquired via PIN Protocol v2. This protocol enables the platform to acquire a long term access token that can be used to identify individual credentials on a hardware security key.

PersistentPinUvAuthToken (PPUAT) enables platforms to list discoverable credentials from YubiKeys without requiring repeated PIN entry.

This means that users can provide the passkey validation on login and the platform can use the persistent PIN to authenticate the user over multiple clicks and buried menus. Users do not have to constantly re-authenticate each move within a logged in session.

The access token simplifies workflows by delivering an autofill-like experience for YubiKey passkeys, aligning security key usability with password managers and platform credentials.

See CTAP authenticatorClientPIN.

Persistent Credential Management Read Only (PCMR) Permission

YubiKey Firmware 5.8 with CTAP 2.3 provides new permission that can be assigned to a Persistent Credential Management Read Only (PCMR) to enable reading credential information only.

Used in conjunction with PPUATs to grant long-term read-only permission to credentials on an authenticator. PCMR is a pinUvAuthToken permission that allows platforms to display security key credentials alongside on-platform passkeys, supporting modern Conditional Mediation UX. For example, password manager-like dropdowns.

See CTAP authenticatorCredentialManagement.

FIDO over CCID and USB

YubiKey Firmware 5.8 supports FIDO over Chip Card Interface Device (CCID) allowing CTAP 2.x commands to be carried using ISO7816 Application Protocol Data Unit (APDU) messaging over the USB CCID smart card interface in addition to the USB Human Interface Device (HID) FIDO interface.

This provides a standards-defined alternative transport for CTAP that leverages the OS smart card stack, and enables secure channel establishment (SCP11b) beyond NFC. It adds flexibility and functionality for remote enrollment of devices, including expanding options on the iOS platform.

See FIDO2 with USB-C or Lightning and FIDO over CCID.

PIN and User Verification

YubiKey Firmware 5.8 with CTAP 2.3 PIN-related GetInfo enhancements used to enable the platform to guide the user towards having more success with creating and remembering their PIN. FIDO 2 PIN and user verification feature updates.

These new enhancements allow customers, especially those subject to high-assurance security standards, to mandate and enforce strong PIN policies and authentication frequency events. Enabling these options within the hardware means customers do not have to solely rely on their application platforms to enforce policies.

Platforms can now query the hardware to assess PIN minimum and maximum lengths, whether complexity is enabled and monitor how often the PIN is entered.

When implemented, the platforms can control and modify the UX experience for users as well as ensuring security policies are met and maintained.

See CTAP authenticatorGetInfo.

maxPINLength

Specifies the maximum PIN length (beyond the baseline byte spec limit) the authenticator enforces for ClientPIN, measured in Unicode code points. This enables platforms to validate PIN length client-side and provide accurate user guidance before submission.

Allows platforms to provide users-guidance regarding what is acceptable for a PIN, and better user experience when attempting to set a PIN that will be rejected by the authenticator because it exceeds the maximum length.

Note

Specification constraint. Even if maxPINLength is set, the authenticator must still restrict the PIN to 63 bytes or fewer.

maxPINLength (0x1D) ensures platforms respect PIN length limits. For example, max 8 for PIV compatibility. This improves user experience with PIN setup.

pinComplexityPolicy

A true/false value that indicates whether an authenticator has additional PIN complexity restrictions besides minimum and maximum PIN lengths.

Allows the platform to inform the user that additional PIN complexity requirements are enforced, so that they are more likely to choose a PIN that complies with the authenticator’s PIN policy. May be used by the platform to decide whether to attempt to process the pinComplexityPolicyURL, or display a generic message if the platform does not support pinComplexityPolicyURL.

pinComplexityPolicy (0x1B) enables platforms to know that the authenticator is enforcing stronger PIN policies (reducing weak PIN usage and improving security) and therefore can provide better UX when a user tries to set a PIN that does not meet the complexity requirements.

pinComplexityPolicyURL

Optional URL that allows platforms to provide users with a specific link to PIN complexity rules, ensuring clarity and compliance with authenticator requirements.

Allows the platform to provide a way for the end user to understand what PIN complexity policies are in force for the specific device they are using, to guide the user to setting a PIN that will not be rejected by the authenticator.

pinComplexityPolicyURL (0x1C) allows platforms to provide users with a specific link to PIN complexity rules, ensuring clarity and compliance with authenticator requirements. For example, yubi.co/pin.

uvCountSinceLastPinEntry

Allows platforms to occasionally prompt PIN entry after repeated biometric usage, preventing PIN forgetfulness. It is defined as a counter: the number of consecutive successful user verification (UV) attempts since the authenticator last required the user to re-enter their PIN.

Enables “PIN recheck” policies. For example, require PIN after N biometric uses.

uvCountSinceLastPinEntry (0x17) allows platforms to occasionally prompt PIN entry after repeated biometric usage, preventing PIN forgetfulness.

Digital Wallet and Credential Management with PRF

YubiKey Firmware 5.8 with CTAP 2.3 enables Pseudo-Random Function (PRF) during make credential (hmac-secret-mc). This allows dual-HMAC keys to be created seamlessly during credential setup instead of requiring two separate steps.

Applications, such as Dashlane, that rely on PRF for end-to-end encrypted synced passkeys, make seamless integration critical. However, setting up credentials that rely on PRF requires multiple user interactions, and creates adoption barriers for lifecycle management of wallets and synced passkeys.

hmac-secret-mc extension reduces friction during setup, enabling smooth passkey lifecycle management and digital wallet adoption, keeping YubiKeys relevant in evolving ecosystems.

CTAP references:

• authenticatorClientPIN.
• PersistentPinUvAuthToken.

Pseudo-Random Function (PRF) Support

Defined as a WebAuthn extension (PRF) in WebAuthn Level 3, PRF is used to provide per-credential high-entropy secrets that can be used to derive symmetric encryption keys. The YubiKey provides PRF support via the hmac-secret extension, which was introduced in CTAP 2.0 and has been a part of the YubiKey firmware since 2019.

YubiKey Firmware 5.8 with CTAP 2.3 hmac-secret-mc extension:

• Expands the PRF functionality with the hmac-secret-mc function. This allows developers to generate encryption keys immediately upon account creation and reduce the number of times a user needs to interact with the key. For example, removes the double-tap.
• Developers can deliver smoother flows when they need to create both authentication and encryption keys at the same time.

Use cases:

• Deriving strong symmetric keys: Use PRF output as a user’s local encryption key for cloud storage.
• Application-specific keys: Derive one secret for authentication, another for encrypting files, and another for signing transactions (all from the same credential).
• Federated/delegated identity: Payment provider derives its own secret from the merchant’s credential, with no shared state needed.

CTAP references:

• hmac-secret.
• hmac-secret-mc.

hmac-secret

A mandatory CTAP extension for authenticators starting in CTAP 2.1.

Provides per-credential, per-RP high-entropy secrets that can be derived during getAssertion.

hmac-secret-mc

Extension introduced in CTAP 2.3.

The hmac-secret-mc extension allows for the derivation of secrets during makeCredential, reducing the number of times that users need to interact with an authenticator to create a credential and then immediately use that credential to generate encryption keys.

Reset-Related Capability Discovery

YubiKey Firmware 5.8 with CTAP 2.3 delivers enhanced reset device protection. Security is improved by allowing platforms to identify what reset options are available on the authenticator and tailor the user flow and messaging to reflect that. For example, reset over a non-wireless connection if only USB is offered as an option. Additionally devices can be delivered with a longer presence check enforced, ensuring the destructive action is intentional.

The transportsForReset, GetInfo bit field is set in pre-pers, and that value determines which transports can be used for reset. For example, USB, NFC, both, or neither.

See CTAP authenticatorGetInfo.

transportsForReset (0x1A)

Improves reset security by requiring a non-wireless connection, preventing specialized attacks on FIDO authenticators that rely on the ability to reset a device using NFC without the knowledge or consent of the device owner.

Allows the platform to direct the user to connect a device over an allowed transport for reset to be successful. Addressing emerging FIDO2 reset restrictions over NFC.

The default value should be that all available transports (USB, Lightning, NFC) are available for reset, however, there shall exist an interface to turn off interfaces for reset (e.g. not allow reset over NFC). This should be a “pre-pers” option. For example, it cannot be changed once the key has been programmed.

longTouchForReset (0x18)

Improves reset security by requiring deliberate long-touch actions instead of a simple touch. This is currently defined as five seconds so as not to break Windows 10 while still providing evidence of a deliberate action. Default is still for the shorter touch.

Allows the platform to direct the end user to use a gesture other than the default short touch to indicate they intend to reset their device. Without this value, platforms cannot inform users the actions they need to take to successfully reset a security key that requires a long touch to reset.

The default value should be that a short touch is used for reset to not cause customer confusion, however, there shall exist an interface to change to long touch for reset. This should be a “pre-pers” option, that is, it cannot be changed once the key has been programmed.

RPID Storage for Enterprises

YubiKey Firmware 5.8 with CTAP 2.3 increases storage capacity for Enterprise Attestation Relying Party ID (RPID)s from 2 to 16 without affecting certificate storage. It simplifies enterprise testing, deployment, and operations, ensuring smoother credential management across complex environments. This allows customers to:

• Support both test and production environments. For example, test-tenant.acme.com and prod-tenant.acme.com.
• Support Enterprise Attestation on multiple identity providers.

Secure Payment Confirmation

YubiKey Firmware 5.8 with CTAP 2.3 provides a ThirdPartyPayment extension per-credential bit flag enables YubiKeys to be used for cross-domain credentials without redirects, as required by Secure Payment Confirmation (SPC).

Enables YubiKeys to support modern, frictionless payment flows, increasing usability and business adoption for secure payments.

See CTAP thirdPartyPayment.

Signing Extension (Preview)

This feature is currently delivered as a preview option with YubiKey Firmware 5.8 and is likely to change before the final specifications are agreed.

Proposed by Yubico for inclusion in WebAuthn L4, the previewSign extension is intended for use cases that need to sign an un-modified (not including client or authenticator data) message with a hardware security key. Like the thirdPartyPayment extension, this uses a separate credential which may not be used for normal authentication.

Asynchronous Remote Key Generation (ARKG) with the raw signing, previewSign extension, as implemented for the FUNKE EUDI Wallet Prototypes, enables end users to use a YubiKey as a root of trust in a wallet scenario and for additional use cases that require signing of arbitrary data. For example:

• The ability to use hardware security keys to sign raw data with signature schemes that are not suitable for authentication, but are suitable for digital wallet applications.
• Provides hardware-backed ECDSA P-256 signing over application-defined data via the previewSign extension. Keys are generated using ARKG; relying parties may integrate ARKG into protocol designs explicitly for key unlinkability or just use the resulting keys like any other ECDSA P-256 key. Additional algorithms or derivation models may be supported in the future.

By extending signing operations beyond just user authentication new use cases are opened up, the signing extension allows for solutions to sign raw data without needing to include client or authenticator details. For example:

• Enables customers to offer comprehensive solution for digital wallets and also for additional use cases where signing arbitrary data is needed.
• By delivering this preview version of the Signing Extension, customers can build out new use cases and solutions ready for full adoption

Third-party payment extension

YubiKey Firmware 5.8 supports CTAP 2.3 Third Party Payment, thirdPartyPayment, extension for third-party payment.

See CTAP thirdPartyPayment.

Defined as a WebAuthn extension, thirdPartyPayment, can be requested by the RP in navigator.credentials.create() or navigator.credentials.get() and is supported via CTAP 2.2 if the authenticator advertises it in the GetInfo extensions. It is returned in the authenticator responses if the extension is recognized and supported.

thirdPartyPayment allows an RP to declare that a credential is being created for a payment use case on behalf of a third party. It provides a privacy-preserving signal that the credential may be scoped or treated differently for payment flows, enabling trusted payment UX without leaking sensitive data.

These extensions focus on giving vendors the tools to be able to present streamlined, secure payment flows to customers, reducing payment friction by removing redirects and confusing UX messages. Historically a credential has been tied to the platform where it was created, meaning merchants would need to redirect users to external sites to perform payment, creating extra steps and confusion.

Use cases:

• Delegated payment credential creation

  • Example: The user creates a passkey with their bank. With the thirdPartyPayment extension set to true, the user can now use that bank passkey on a merchant site to validate the transaction with the bank.
  • Authenticator understands this is a “third party payment” credential and can surface appropriate UX. For example, payment icon, branding, and warnings.

• Improved payment UX in browsers/platforms

  • Allows the platform (browser/OS) to display “Use this passkey to pay with Provider X” instead of a generic login prompt.
  • Prevents confusing UX where a payment credential looks identical to a normal website credential.

YubiHSM Auth credential editing

Prior to YubiKey firmware 5.8, after a credential is created in the YubiHSM Auth component it could not be updated. With YubiKey Firmware 5.8 you can update an existing credential if:

• In possession of the authkey, or
• In possession of the current password

This helps in deployment situations when a credential is set to an initial value by for example an admin, then changed later after the end user receives their key.

See Yubico .NET YubiKey SDK: User’s Manual, YubiHSM Auth Overview.