Plugging in a YubiKey does not tell your application which authentication protocol to use. The same product family can support several distinct applications.

A website using WebAuthn, a smartcard deployment using certificates, and a form accepting one-time codes have different server requirements.

Choose the protocol first. Then confirm the model, firmware, and interface needed for that protocol.

Compare protocols before comparing devices

FIDO2 combines browser-facing WebAuthn with the Client to Authenticator Protocol (CTAP). In a web application, the browser mediates access to the authenticator.

PIV means Personal Identity Verification. It provides smartcard-style cryptographic operations and commonly participates in certificate-based systems.

Yubico's PIV documentation describes its signing and encryption interfaces. PIV is not another name for a WebAuthn passkey.

Application requirement	Candidate protocol	Integration work
Browser sign-in using public-key credentials	FIDO2 / WebAuthn	Registration and assertion verification
Existing smartcard or certificate infrastructure	PIV	Certificate issuance, trust, renewal, and revocation
Service already accepting time-based codes	OATH TOTP	Shared-secret enrolment and code verification
Existing Yubico OTP integration	Yubico OTP	OTP validation protocol and server integration

Check the specific product's capabilities. Do not assume every YubiKey or every security-key model supports every row.

Understand where WebAuthn fits

The relying party stores a credential record and public key. The authenticator proves possession of the corresponding private key during authentication.

The browser coordinates the request for the site's relying-party identifier. Your server verifies the resulting assertion.

Application server -- challenge --> browser -- WebAuthn/CTAP --> security key
Application server <-- assertion -- browser <--- signed response --- key

A website does not need a separate YubiKey-only login protocol when it already supports compatible WebAuthn authenticators.

Use Yubico's FIDO2 credential guide to understand discoverable and non-discoverable credentials.

Use the hardware-key policy article when the requirement concerns approved hardware rather than general compatibility.

Keep OTP terminology precise

Yubico OTP and OATH TOTP are different protocols.

Yubico OTP produces a value for a corresponding validation service. OATH includes time-based and counter-based one-time-password algorithms.

A physical device can protect the secret used to generate a code. That does not make the entered code bound to the website's origin.

A phishing site can ask a person to enter a current code. Hardware storage and resistance to credential relay are separate properties.

For a new browser application, compare that risk with a public-key flow. Avoid selecting a protocol simply because both involve touching a key.

Inspect capabilities without changing the key

The YubiKey Manager CLI guide documents these inspection commands:

ykman info
ykman fido info
ykman piv info

Use the commands supported by your device and installed tool version. Record the model, firmware, enabled applications, and connection method.

Do not add reset or reconfiguration commands to a basic inspection script. Those operations can remove credentials or change an existing deployment.

This article uses documentation-backed commands. It does not claim that a physical key was attached or tested during preparation.

Plan registration and replacement separately

For WebAuthn, register a credential through the application's authenticated enrolment flow. Confirm which account owns the new credential.

Record a useful user-facing name. Treat that name as a label, not evidence of hardware provenance.

Register a spare authenticator separately when the policy permits it. Confirm that the spare can authenticate before ending the enrolment session.

For PIV, define the certificate's lifecycle. Identify the issuer, validity period, relying services, and revocation procedure.

Losing a device may require action in several systems. Removing one website credential does not revoke a PIV certificate used elsewhere.

Design the help-desk procedure

A report of a lost key should identify the affected account and credential records. Avoid asking the person to send PINs or recovery secrets.

Verify the recovery request through the approved route. Remove the lost authenticator's intended access and review existing sessions.

For an employee departure, review application permissions as well as authentication methods. Hardware possession alone does not explain the person's business authority.

Use the recovery-design guide to record approvals and replacement steps.

A reset key is not evidence that previous relying-party records have been removed. Review those records explicitly.

Run an integration acceptance review

Download the hardware-key checklist. Keep protocol-specific results in separate rows.

Test	Evidence to capture
Register and authenticate	Account, credential identifier, and successful verification
Required user verification	Server result when the policy is satisfied or missing
Wrong site or relying-party identifier	Rejection without an authenticated session
Revoke a credential	Next authentication fails for that credential
Remove an existing session	Protected request is rejected according to policy
Use the spare key	Independent credential works through the approved flow
Change interface or client device	Actual result for the supported deployment

Do not infer broad compatibility from one successful desktop test. Your users may use another browser, operating system, or connection interface.

Link the results to the exact deployment instructions. That turns “supports hardware keys” into a statement your team can substantiate.

Get integration advice from NamoID

Contact the NamoID team with your application, intended authentication protocol, and access-policy requirements. We can help review the customer sign-in integration.

Message our engineers in Slack for an early response. We can help clarify the next implementation step without assuming every hardware-key protocol is part of one product feature.

NamoID is independent of Yubico. This guide does not imply certification, endorsement, or a commercial partnership.

Related posts