Verifying Your FIDO2 Hardware Security Key: What a Browser Can Confirm

You ordered a security key, it arrived, and your first login with a tap just worked. That success only proves the website accepted a credential. It says nothing about whether the device in your hand is genuine, or whether someone slipped a clone into the box before it reached you.

This guide shows the checks you can run entirely in your browser, with no uploads and no extra software, using three free CapyToolkit tools. You’ll learn how to confirm a key’s attestation is intact, what your browser still leaks that the key doesn’t fix, and why the backup password matters more than the marketing suggests.

Why a Hardware Key Needs Verifying in the First Place

A FIDO2 key drops the password from your main login, which is exactly why it shuts down the phishing and credential-stuffing attacks that dominate every breach report. The browser writes the site’s origin into the credential and the key signs over it, so thieves can’t use a password taken from one site to unlock another; the WebAuthn spec binds each credential to a specific origin for this reason.¹

But a successful login only proves the site accepted some credential. It doesn’t prove that credential came from a genuine authenticator built by the vendor you trust, or that this key is your only factor. A cloned device with a convincing attestation will sail through, and a second factor is worthless if the account’s recovery path quietly falls back to a password.

So the green light is the worst moment to stop paying attention. Three things go wrong in real life: a counterfeit device, a key you enroll as a second factor but that stays silently bypassable, and a recovery path that leans on a password too weak to stand alone. None of these show up on the login screen, which is precisely why they catch people off guard.

Confirming the Key Is Genuine: Reading Its Attestation Certificate Chain

Every time you register a key, it hands the site a receipt called attestation. The browser grabs a CBOR blob at registration, and buried inside it sits an x5c array of DER-encoded X.509 certificates that chain back to the vendor’s attestation authority. The FIDO2 attestation format packages that material as an X.509 chain rooted at the vendor’s attestation CA, so decode the blob and pull the x5c array out before you paste anything.² Because your browser only mediates the exchange and never validates the chain, that job falls to the site’s server, or to a client-side inspector like this one, which checks each link against the vendor’s root. You don’t have to take the vendor’s word, because you can trace the chain yourself.

What Attestation Actually Proves

By tying a credential to a specific model and firmware build, attestation tells the site which device made it, not who you are. The statement “this came from a real YubiKey 5 or a real Titan” is enough to block a cheap clone that can’t forge that chain. This single fact is what separates a genuine key from a convincing copy at registration time.

What it can’t do is prove you’re holding the key during later logins. The live signature challenge at each sign-in handles that, so attestation and the login challenge answer two different questions. Think of attestation as “which device,” and the challenge as “is that device here right now,” the part no upfront inspection can fake.

Reading the Chain in the X.509 Inspector

Paste the certificate you pulled from the x5c array into a client-side inspector and walk the leaf-to-root path yourself. You can read a FIDO2 key’s attestation certificate chain in your browser, and let the tool match each Authority Key Identifier to the next issuer’s Subject Key Identifier, the same step that certificate chain validation uses to build a trusted path from leaf to root. No vendor portal, no account, nothing leaves your machine.

Inside that view, CapyToolkit’s X.509 Certificate Inspector lays out each certificate as a card and flags weak keys, whether RSA under 2048 bits or ECDSA below P-256, plus SHA-1 signatures and expired links.³ Those flags are the difference between a chain you can trust and one you should question, and the tool does the whole check locally. The same inspector that reads a website’s TLS certificate will read your key’s attestation just as happily.

Red Flags a Genuine Key Won’t Show

If the chain stops on an INTERMEDIATE card instead of a self-signed root, treat that as your first warning. The same goes for an RSA key under 2048 bits, an ECDSA key below P-256, or any SHA-1 signature: all of them are reasons to question the device.³ Real FIDO2 keys sign with ECDSA P-256 or Ed25519, not legacy RSA, so when you see a current curve running all the way to a vendor root, that’s the chain you want, not a red flag.⁴

Anything flashing a weak-key or SHA-1 badge deserves suspicion, since a name-brand vendor simply doesn’t ship attestation material that old. When the inspector throws one of those flags, treat the key as unverified until you’ve got a second opinion. Gathering a clean chain costs you almost nothing and spares you the nasty surprise of a weak link once that key is your only way back in.

Checking the Key Against Your Browser’s Fingerprint Leaks

Buy a key and you’ve killed phishing, full stop. It makes you safer, not private. Your browser still hands every page you open its quiet little identifiers, and the key does nothing to stop that. Both threats want your account, so they feel like one fight, yet they run on different machinery, and you stay safe only by treating them as the separate problems they are.

What the Inspector Actually Surfaces

See what your browser leaks to trackers on every page with CapyToolkit’s Browser Fingerprint Inspector, which scans on its own and reports 30-plus signals: canvas hash, WebGL renderer, audio fingerprint, installed fonts, timezone, and more. The entropy score at the top estimates how uniquely your browser can be picked out, which is worth reading before you believe any “private” claim about your setup.

Rows marked TRACKABLE are the heaviest signals, the ones a tracker reads first. To see how browser fingerprinting collects your device signals into a unique identifier, watch which rows carry that flag in your own report; the inspector shows exactly which queries make you unique before any site runs them, and that visibility is the first step toward shutting the leak down.

Why a Key Beats a Trackable Browser

Phishing and fingerprinting look like the same threat, but they ride on different machinery, and a hardware key only defeats one of them. Cross about 20 bits of entropy and a tracker can pick your browser back out across sessions and private windows, no cookie required.⁵ The key doesn’t shrink that number. What it actually kills is credential replay and session theft, the daily attacks a fingerprint never touches. So the two protections cover different halves of the same problem, and beating one while ignoring the other still leaves you wide open.

Pair the key with a browser that resists fingerprinting and you close both doors at once. The key shuts the phishing door; the browser shuts the tracking door; leave either one open and half the problem stays exposed. Because the attacks don’t overlap, the defenses stack, so an attacker who slips past one layer still runs into the other.

Where the Password Still Matters (and How Much Entropy You Need)

Even after you confirm the key and shut down the fingerprint leaks, one gap still sits between you and a clean setup: the account recovery fallback. That backup password is the weak spot. Most keys still ask you to set one, and recovery often falls back to it, so the password the key was supposed to replace never really leaves your life. In daily use the key only moves that password aside; it still lurks in the recovery path. NIST sets only an 8-character floor for a password used alongside another factor, so the backup must clear a higher bar when it stands in for the factor the key was meant to provide.⁶

Run that backup through a password entropy analyser. You can measure the entropy of your backup password offline, where it shows Shannon entropy next to a zxcvbn pattern score and GPU crack-time estimates.⁷ Those two numbers together tell you whether the password is actually strong or just looks complicated to eyes that have seen “P@ssw0rd” too many times.

The analyser reports the lower of its two scores on purpose. A password like “P@ssw0rd123” can read as 70-plus bits of Shannon entropy yet score Very Weak on zxcvbn, because the substitution pattern is one attackers already know by heart. When the engine flags a high-entropy password, that flag is the trap, not a win, so read both columns before you trust that backup to hold your recovery alone.

NIST SP 800-63-4 requires at least 15 characters for a password standing alone as the only factor, a bar most short backups never clear. The real question is role, not raw length. When recovery depends on the password alone, the weak daily password the key lets slide as a second factor becomes the fallback the analyser’s strength bands must judge, and Strong starts at 75-plus bits. Treat the backup as the weakest link it is.

A Browser-Only Verification Routine You Can Run Today

Pull the three tools into one check you can run the moment a key lands on your desk, with nothing installed and nothing uploaded. The CapyToolkit’s browser-based tools that process everything locally keep your key’s data on its own machine the whole time, which is the whole reason to do this client-side instead of handing your attestation to a website. Give it five minutes and work top to bottom. The order matters, because each step builds on the trust the last one earned, so jumping to the password before the chain checks out would bury a cloned key behind a strong backup.

Question about your key	Tool	What it confirms
Is the attestation chain intact and algorithm-current?	X.509 Certificate Inspector	No weak-key, SHA-1, or broken-chain flags on the attestation cert
What does my browser still leak that the key doesn’t fix?	Browser Fingerprint Inspector	Entropy score and TRACKABLE signals worth suppressing
Is my backup password strong enough if recovery falls back to it?	Password Entropy Analyser	Entropy bits and crack-time against the 15-character NIST floor

1. Read the attestation chain in the X.509 inspector and confirm it ends on a genuine root with no weak-key or SHA-1 badge.
2. Scan your browser with the fingerprint inspector and note the entropy score plus any TRACKABLE rows you can suppress.
3. Paste your backup password into the entropy analyser and check it clears the 75-bit Strong band if recovery depends on it.

Walk through it in that order and note which flags showed up, so you can re-run it after a firmware or browser update changes the picture. Five minutes today spares you from finding a weak link during a real login emergency, when you’ve got no time and no spare device.

What to Look for Once the Setup Checks Out

With the chain and the backup confirmed, the only real question left is which key to trust long-term. The attestation you just read is the technical basis for that call, because a clean chain is what separates a genuine device from a convincing clone the moment you buy it. Use those checks as your filter instead of the marketing copy.

• FIDO2 and U2F support. The key then covers both modern passkey flows and the older sites that never upgraded.
• Match the connection type to your gear: USB-C or NFC, never the wrong shape for your laptop or phone.
• Resident passkeys on the hardware itself matter once you rely on passkeys instead of passwords.
• A second backup key, or biometrics, if your recovery plan still leans on that backup password.

The YubiKey 5C NFC carries FIDO2, U2F, OTP, PIV, and OpenPGP in one USB-C key, while Google’s Titan Security Key stores up to 250 passkeys and covers FIDO2/U2F at a lower price. Both hold up cleanly against the attestation checks above, so either one is a defensible long-term pick once the chain confirms it’s genuine.

Match the spec to your recovery plan. A key with a fingerprint reader or a second backup key changes how much you depend on that backup password the analyser scored earlier, so weigh the extras against how you’d actually get back in if the primary key breaks or goes missing. A key that needs the password less often is a key that survives a weak backup, and that trade is what you’re really shopping for once the attestation already checks out.

YubiKey 5 NFC

On the YubiKey 5 NFC, hardware executes HMAC, not software. The YubiKey 5 NFC stores a secret key in tamper-resistant hardware and computes HMAC-SHA1 challenge-response authentication entirely on-device. Your application sends a 64-byte challenge; the YubiKey returns a 20-byte HMAC-SHA1 response computed using the stored 20-byte secret key⁸. Because the secret never leaves the device, an attacker who compromises your application server cannot extract it - the key is physically protected.

Yubico positions the YubiKey 5 NFC as the consumer and enterprise standard, and with approximately $58 USD retail pricing it is the most widely deployed hardware security key in the market as of 2026. It supports HMAC-SHA1 challenge-response in two programmable slots (slot 1 and slot 2), FIDO2/WebAuthn for browser authentication, TOTP and HOTP for time and counter-based OTP, OpenPGP 3, PIV (smart card), and Yubico OTP. The NFC antenna enables tap-based FIDO2 authentication on Android and iOS devices in addition to USB-A; note that HMAC challenge-response requires a physical USB or Lightning connection and does not operate over NFC.

Configure HMAC-SHA1 challenge-response using the Yubico Authenticator app or the YubiKey Manager CLI (ykman). Each slot stores one HMAC secret up to 20 bytes. The challenge-response mode is well-suited for KeePass database encryption, VeraCrypt two-factor authentication, and custom applications that need hardware-bound HMAC without network round trips.

Compared to a software HMAC implementation, the YubiKey provides two guarantees software cannot: the key is stored in hardware that resists physical extraction, and the computation happens in an environment isolated from the host operating system. For threat models that include a compromised OS or stolen disk image, hardware HMAC eliminates the attack vector that software HMAC cannot address.

Yubico YubiKey 5 NFC specifications

Specification	Value
HMAC algorithm	HMAC-SHA1 (challenge-response, slots 1 and 2)
FIDO2 support	Yes - FIDO2/WebAuthn, FIDO U2F
Additional protocols	TOTP/HOTP, OpenPGP 3, PIV/CCID, Yubico OTP
Connector	USB-A + NFC
OS compatibility	Windows, macOS, Linux, Android, iOS
Approximate US retail price	~$58 USD (May 2026)

YubiKey Manager programs and manages challenge-response slots

The ykman command-line tool programs HMAC-SHA1 secrets into either YubiKey slot over USB, and it is the recommended way to provision challenge-response credentials because it handles key generation, slot selection, and verification in a single workflow. To write a random secret to slot 2, run: ykman otp chalresp -generate 2. The -generate flag creates a random 20-byte key and stores it without displaying the key material to the terminal, which is the safest approach since the secret is never exposed in shell history or log output. Slot 1 activates on a short button press; slot 2 requires a long press of two to three seconds. This distinction matters when slot 1 holds a Yubico OTP configuration, because accidental short presses would produce OTP output rather than a challenge-response interaction.

Choosing a slot for daily use

Select the slot you touch least often for sensitive challenge-response workflows. A long-press requirement reduces accidental activation, which matters when the same key also handles OTP or FIDO2 actions throughout the day and you do not want an unintended challenge-response output mixed in with your regular authentication flow. Programming both slots with different secrets is also possible when you need one slot for daily KeePass access and another for a separate VeraCrypt volume, giving you hardware-enforced separation between two independent encrypted resources on a single physical device.

For resilience, program a second YubiKey with the same HMAC-SHA1 secret using ykman otp chalresp -key <hex_secret> before deploying the primary key. Store the backup key at a separate physical location such as a locked drawer, a safe, or a trusted family member’s home. If the primary key is lost or damaged, the backup restores full access without reprovisioning any dependent service, which is the recovery scenario that justifies the extra five minutes of setup time before you start relying on the primary key in production.

For offline password managers and encrypted volumes, HMAC provides hardware-bound protection

For applications that protect a database or volume with hardware challenge-response, the HMAC interaction functions as part of a two-factor unlock: something you know (master password) and something you have (the YubiKey). KeePassXC sends a challenge derived from the database file to the YubiKey and requires the correct HMAC-SHA1 response before allowing access, which means the key derivation process involves both a human-memorized secret and a hardware-protected secret simultaneously. Without the physical key, the database does not open even if an attacker has both the master password and the database file, because the HMAC step cannot be completed without the hardware-stored secret.

Keeping offline access independent from the host

The protection matters most when the host is untrusted. A stolen laptop, infected operating system, or copied disk image still lacks the physical key, so the HMAC step remains outside the compromised environment and the attacker cannot derive the correct response even with full disk access. This threat model is the primary reason organizations deploy hardware-backed HMAC rather than software-stored secrets, because a software secret can be exfiltrated from a running process or a memory dump while a hardware secret cannot.

VeraCrypt can also use a YubiKey for volume protection, though through a different mechanism: Yubico’s official guide imports a 64-byte keyfile into the PIV “Printed Information” slot (object 0x5fc109) and configures VeraCrypt to read from that slot. Unlike KeePassXC’s HMAC-SHA1 challenge-response, this is a static keyfile approach where the YubiKey acts as a secure storage medium rather than an HMAC computation partner.

Verifying slot output consistency after provisioning and firmware events

Verifying that a YubiKey slot produces consistent output after firmware updates or reprovisioning catches silent configuration loss before it locks you out of dependent systems. Use ykchalresp -2 <hex_challenge> to send a known 64-byte challenge to slot 2 and compare the response against a reference value you recorded at initial setup. HMAC-SHA1 is deterministic: the same challenge always produces the same 20-byte response for the same stored key⁸. Any deviation indicates the slot was cleared or reprogrammed.

Recording deterministic reference pairs

Record reference challenge-response pairs for all deployed keys, and work out the expected HMAC-SHA1 response yourself so a known-good value exists before you ever touch the physical key, then run the comparison check after any ykman operation that modifies slot configuration. Store at least three challenge-response pairs per slot in a secure location separate from the YubiKey itself, because if a firmware update or accidental reprovisioning clears the slot, these reference pairs are the only way to confirm whether the key material changed. A fixed challenge such as 64 bytes of zero produces a deterministic response that serves as a fingerprint for the stored secret, making it trivial to detect silent configuration loss before it causes an authentication failure in production.

Notes for checking the YubiKey 5 NFC with CapyToolkit

• Two programmable slots. This key stores its HMAC-SHA1 secret in slot 1 (short touch) or slot 2 (long touch). On the HMAC-SHA1 tab of the Hash Generator, remember the real device computes its response in hardware from a challenge it receives over USB. It doesn’t take a typed message the way the Hash Generator’s demo does.
• SHA-1 only, not SHA-256. The OTP slots on this key support HMAC-SHA1 only. Use the Hash Generator’s HMAC-SHA1 tab to see that algorithm’s mechanics, but don’t assume a Nitrokey 3 shares this same ceiling.
• Deterministic response checking. This key sends a fixed 64-byte challenge and compares the 20-byte response against a recorded reference. The HMAC-SHA1 tab illustrates why that comparison works: the same input and key always produce the same output.

Common questions about the YubiKey 5 NFC

How do I configure HMAC-SHA1 challenge-response on the YubiKey 5 NFC? Use the YubiKey Manager desktop app or the ykman CLI. Select “Applications > OTP”, then choose a slot (1 or 2) and configure “Challenge-response > HMAC-SHA1”. You can generate a random secret or enter a specific key. The slot stores the secret permanently; it cannot be read back, only used.

Does the YubiKey 5 NFC support HMAC-SHA256? The built-in challenge-response mode uses HMAC-SHA1 only. The YubiKey 5 does not support HMAC-SHA256 in its OTP slots. For HMAC-SHA256 hardware protection, consider the Nitrokey 3 with its HMAC-SHA256 application, or use FIDO2 HMAC-SHA256 assertions for WebAuthn-compatible use cases.

What is the difference between YubiKey OTP mode and challenge-response mode? YubiKey OTP mode generates a one-time password when the key is touched - a long string using Yubico’s proprietary OTP protocol, typically used with Yubico’s cloud validation service. Challenge-response mode accepts a challenge from your application, computes HMAC-SHA1 internally, and returns the response without any network connectivity. Challenge-response is for offline or custom implementations.

Can I use the YubiKey 5 NFC for browser-based FIDO2 login? Yes. The YubiKey 5 NFC supports FIDO2/WebAuthn for password-less and second-factor browser authentication. Connect via USB-A or tap the NFC antenna to a supported device. FIDO2 uses ECDSA-SHA256 internally for the authentication assertion - this is separate from the HMAC-SHA1 challenge-response functionality.

How does hardware HMAC differ from software HMAC for the same key? The output is identical - HMAC-SHA1 with a given key and challenge produces the same bytes regardless of whether it runs in hardware or software. The difference is key security: a software HMAC stores the secret in memory or on disk, where an OS-level attacker can extract it. Hardware HMAC stores the secret in a secure element that resists extraction even with physical access to the device. CapyToolkit’s device pages separate hardware-bound HMAC from browser-computed hashes so you choose the right model.

Nitrokey 3

In the Nitrokey 3, open source goes all the way down. Unlike proprietary security keys, the Nitrokey 3 publishes both its hardware design (schematic and PCB layout under open-source licenses) and its firmware (written in Rust using the Trussed cryptography framework). Consequently, every HMAC-SHA256 computation, every ECDSA signature, and every key storage operation can be audited by any security researcher with the technical background to verify the code.

At approximately $59 USD, the Nitrokey 3 is priced above the Thetis Pro and comparable to the YubiKey 5 NFC. It justifies its cost through protocol breadth: FIDO2/WebAuthn, OpenPGP 3 (for email and file signing), PIV (smart card for Windows domain authentication), TOTP/HOTP, and applications built on the Trussed framework including HMAC-SHA256 operations. The USB-C/NFC model (Nitrokey 3A NFC) covers modern connector standards; a USB-A model (Nitrokey 3A Mini) is also available for legacy ports.

For developers who want hardware-enforced HMAC-SHA256 rather than HMAC-SHA1, the Nitrokey 3’s Trussed platform supports HMAC-SHA256 through its application framework. Custom applications running on the Trussed platform can use the hardware-isolated key store for HMAC operations, providing SHA-256 where the YubiKey 5 NFC offers only SHA-1 in its OTP slots.

The open-source design is most valuable for high-security environments where supply chain trust is a concern. Organizations that audit their dependencies can verify the Nitrokey’s firmware against the published source before deployment, providing a level of assurance that proprietary keys cannot match regardless of security certifications.

Nitrokey 3 specifications

Specification	Value
HMAC support	HMAC-SHA256 via Trussed framework applications
FIDO2 support	Yes - FIDO2/WebAuthn, FIDO U2F
Additional protocols	OpenPGP 3, PIV/CCID, TOTP/HOTP
Firmware	Open source (Rust / Trussed) - auditable
Connector	USB-C + NFC (3A NFC model); USB-A Mini also available
Approximate US retail price	~$59 USD (May 2026)

Generating OpenPGP keys directly on the Nitrokey 3 hardware

Generating an OpenPGP key directly on the Nitrokey 3 produces private key material that never exists outside the device, which is the strongest possible guarantee that the secret cannot be stolen through a software vulnerability. Use GnuPG to initiate on-card generation: gpg -card-edit, then the admin command, then generate. The Trussed secure element creates the key internally and blocks export. Only the public key leaves the device. For existing GPG subkeys on disk, moving a subkey to the card with gpg -edit-key and keytocard removes the private key from disk and leaves a stub pointer in its place so that GnuPG still routes signing operations to the hardware.

Keeping private key material on-card

The security benefit comes from never creating the private key in host memory. Once generated on the device, the private material cannot be copied to a laptop image or extracted by malware, and even a fully compromised operating system cannot dump what it never had access to in the first place. This on-device generation pattern is the reason hardware security keys are recommended for high-value email signing, code commit signing, and encryption operations where the private key must remain isolated from any general-purpose computing environment. Organizations that handle classified or regulated data often mandate on-card key generation specifically because it eliminates the attack window that exists between key creation on a general-purpose OS and key import into hardware, which is the moment when a keylogger or memory scraper could capture the secret.

Thunderbird and most mail clients that support GnuPG-based OpenPGP signing work with keys stored on the Nitrokey 3. Email signed with a hardware-stored key provides assurance that the private key was not compromised even if your workstation was infected after the key moved to the device. This guarantee holds because the signing operation happens inside the secure element, so the private key material never appears in the host computer’s memory where a keylogger or memory scraper could capture it.

In SSH authentication, the PIV application exposes keys through PKCS#11

For SSH key authentication with hardware protection, the PIV application on the Nitrokey 3 stores RSA or ECC keys and exposes them through a PKCS#11 interface that any standards-compliant SSH client can use. Add PKCS11Provider /usr/lib/x86_64-linux-gnu/opensc-pkcs11.so (or the equivalent OpenSC path on your system) to your ~/.ssh/config. The SSH client passes authentication challenges to the device, which signs them internally. The private key never leaves the device during an SSH session, so even a compromised SSH agent on the host cannot leak the raw key material.

Matching the SSH workflow to human presence

Hardware SSH is strongest when a person is present to press the key, because the physical touch requirement guarantees that no automated process can initiate an SSH session without deliberate human authorization. For unattended jobs, consider short-lived software keys with strict repository permissions instead of bypassing the button requirement, since a hardware key that requires a button press at three in the morning is a deployment bottleneck no engineer wants to debug.

For fully automated CI or deployment pipelines that require SSH access without human interaction, PIV-based hardware keys impose a button-touch requirement that may not suit the use case. Software keys with tightly scoped access controls are often more appropriate for pipelines where no human is present to press the button.

When open-source firmware auditability matters for your threat model

When your security policy requires verifiable supply chain integrity for authentication hardware, the Nitrokey 3 provides a verification path that proprietary devices cannot match. Build the Trussed firmware from the published source at github.com/Nitrokey/nitrokey-3-firmware. Verification only holds if you compute a hash for the firmware you built and compare that digest against the value reported by nitropy nk3 verify-update. A matching hash confirms the factory firmware matches the published source code.

Turning auditability into a deployment gate

This verification step is uncommon for individual users but relevant for organizations with formal supply chain policies. The comparison takes under five minutes on a modern workstation. No proprietary hardware security key offers an equivalent option because the firmware is not published. For environments that audit every firmware component in their security boundary, this auditability is a concrete differentiator. Make the firmware hash comparison a mandatory step in your procurement checklist, so that every batch of newly purchased keys is verified against the published source before it enters production, rather than trusting that the factory firmware matches the open-source repository without checking.

Notes for checking the Nitrokey 3 with CapyToolkit

• HMAC-SHA256, not SHA-1. This key’s Trussed framework performs HMAC-SHA256 through custom applications, while the HMAC tab of the Hash Generator demonstrates HMAC-SHA1. The SHA-1 tab still explains the general challenge-response mechanic, even though this specific key runs the stronger variant.
• Firmware you can verify. This key’s article describes comparing a self-built firmware hash against the official verify-update check. It’s the same trust-but-verify logic behind checking HMAC output against a known reference in the Hash Generator.

Common questions about the Nitrokey 3

Does the Nitrokey 3 support HMAC-SHA256 (not just HMAC-SHA1)? Yes. The Nitrokey 3’s Trussed firmware framework supports HMAC-SHA256 through its application layer, unlike the YubiKey 5 which provides only HMAC-SHA1 in OTP slots. Custom applications deployed to the Trussed runtime can use HMAC-SHA256 with hardware-isolated keys.

What does open-source hardware mean for security? It means the schematic, PCB design, and firmware are publicly available for review. Any security researcher can verify that the device does what it claims - there are no undocumented backdoors in the hardware design or firmware. Proprietary keys make security claims without allowing independent verification of the implementation.

How does Nitrokey 3 compare to YubiKey 5 NFC? Both support FIDO2, OpenPGP, PIV, and OTP. The Nitrokey 3 offers HMAC-SHA256 (vs YubiKey’s HMAC-SHA1), fully open-source hardware and firmware, and USB-C as the primary modern connector. The YubiKey 5 NFC has broader ecosystem support, more mature tooling, and comes from a larger organization. CapyToolkit’s device comparisons separate protocol support from price. Choose Nitrokey 3 if open-source auditability or SHA-256 in HMAC operations are priorities.

Can I use the Nitrokey 3 for SSH authentication? Yes. The PIV application on the Nitrokey 3 stores an RSA or ECC key that works with SSH via PKCS#11. OpenPGP authentication subkeys also work for SSH. Both require configuring your SSH client to use the hardware key through the appropriate agent or PKCS#11 library.

Is the Nitrokey 3 available in the US? Yes. Nitrokey ships internationally from Germany. Delivery to the US takes approximately 5–10 business days. The approximate retail price is $59 USD; the actual cost in USD varies with exchange rates. Nitrokey also sells through Amazon US, which provides faster delivery.

Feitian ePass FIDO2

For regulated environments, government compliance requires certified hardware. The Feitian ePass FIDO2-NFC K40 Plus carries FIPS 140-2 Level 2 certification (NIST CMVP Certificate #4422)⁹ - a NIST-administered security standard that validates the device’s cryptographic module against physical tamper evidence requirements, role-based authentication, and documented key management procedures. This certification is required or strongly recommended for US federal agencies, contractors under FedRAMP, and many financial and healthcare organizations operating under federal oversight.

At approximately $30.50 USD, the ePass FIDO2-NFC K40 Plus is one of the most affordable FIPS 140-2 L2 certified hardware keys in the US market as of mid-2026. The price point makes compliance-grade authentication accessible for individual contractors and small organizations that operate in regulated environments without the budget for enterprise key management infrastructure.

SHA-256 is central to the device’s FIDO2 operation¹⁰. Every WebAuthn authentication assertion the ePass FIDO2-NFC signs includes an ECDSA-P256 signature over a SHA-256 hash of the authenticator data and client data - the same internal SHA-256 usage as other FIDO2 devices, but here validated under FIPS 140-2 L2 procedures. The certification confirms that the SHA-256 implementation meets NIST FIPS 180-4 requirements.

The ePass FIDO2-NFC K40 Plus supports FIDO2, FIDO U2F, OATH-HOTP, OATH-TOTP, PIV (smart card), and OpenPGP protocols. It does not provide HMAC challenge-response slots. For FIDO2 and PIV authentication in compliance-sensitive environments, the K40 Plus offers FIPS 140-2 L2 certification at a competitive price. Organizations that need additional protocols such as Yubico OTP or NFC-based challenge-response should evaluate the YubiKey 5 FIPS series, which carries FIPS 140-2 L2 certification alongside the full YubiKey protocol suite.

Feitian ePass FIDO2 specifications

Specification	Value
Security certification	FIPS 140-2 Level 2 (CMVP #4422)
FIDO2 support	Yes - FIDO2/WebAuthn, FIDO U2F
Additional protocols	OATH-HOTP, OATH-TOTP, PIV (smart card), OpenPGP
HMAC support	None (FIDO2/PIV-only device)
Internal hash usage	SHA-256 (FIPS 180-4) in ECDSA-P256 assertions
Connector	USB-C + NFC (K40 Plus model)
Approximate US retail price	~$30.50 USD (May 2026)

Understanding what FIPS 140-2 Level 2 certification covers

FIPS 140-2 Level 2 adds physical security requirements on top of the algorithm correctness tests at Level 1, moving beyond pure cryptographic validation into tangible hardware protections that an attacker cannot bypass through software alone¹¹. The cryptographic module must provide tamper evidence through coatings, seals, or pick-resistant locks that reveal unauthorized physical access attempts to any examiner. Level 2 also requires role-based operator authentication to the module and a finite state model documenting the module’s operational states so that every mode transition is formally specified. For the ePass FIDO2-NFC K40 Plus, these requirements were validated under NIST’s Cryptographic Module Validation Program (CMVP)⁹, which subjects the device to independent laboratory testing before issuing a certificate. NIST maintains the full validation record, including exact algorithm implementations tested, at csrc.nist.gov/projects/cryptographic-module-validation-program.

Confirming the exact certified module

The certificate must match the exact model and firmware family you buy, so always cross-reference the CMVP validation number against the specific product SKU before placing an order. Procurement should record the validation number, vendor name, and certificate status before ordering, because a similar-looking key without the same certificate may not satisfy the control and you may need to return the entire batch.

Validation certificates carry an expiration date that compliance auditors will check during assessments. Before purchasing for a compliance-gated procurement, search the CMVP database by vendor name to confirm the certificate is still active and that the specific module version matches the product you are purchasing, because buying a key whose certificate has lapsed can force a costly replacement cycle mid-project.

FIPS requirements apply directly in federal and contractor environments

FedRAMP High authorization requires FIPS 140-2 L2 validated hardware authenticators for privileged access, and this requirement flows down to every service provider and contractor that handles federal data under the FedRAMP umbrella. NIST SP 800-63B specifies hardware cryptographic authenticators at AAL3 for the highest authentication assurance level, which is the tier that federal agencies must meet for administrative and privileged accounts. The ePass FIDO2 satisfies these requirements for FIDO2-based authentication workflows. Contractors operating under CMMC Level 2 or Level 3 need hardware multi-factor authenticators for accounts with privileged system access.

Aligning key rollout with the compliance control

Map each user role to the specific compliance control it must satisfy before buying any keys. Standard users may need FIDO2 MFA only, while privileged administrators may also require stronger approval workflows, asset tagging, and documented recovery procedures that go beyond what a single hardware key can provide on its own.

Organizations with procurement timelines extending past 2026 should verify whether the specific certificate version remains valid at time of purchase, because FIPS 140-2 certificates transition to FIPS 140-3 on an ongoing basis. NIST’s CMVP transition guidance documents the schedule and the conditions under which FIPS 140-2 validated modules remain acceptable after the transition date.

When FIDO2-only coverage satisfies your compliance requirement

When your compliance obligation requires hardware-backed FIDO2 multi-factor authentication for user accounts without a PIV or OpenPGP requirement, the ePass FIDO2 covers the mandate at the lowest FIPS-certified price point. At approximately $25 per key compared to the YubiKey 5 FIPS at approximately $80, the per-key savings of $55 are significant at scale: 100 keys save $5,500 with no reduction in FIDO2 authentication quality.

Segmenting users by protocol requirement

For mixed environments where some users need PIV for Windows domain authentication or OpenPGP for document signing alongside FIDO2, deploy ePass FIDO2 keys for standard users and reserve FIPS-certified PIV-capable keys for privileged users. Segmenting by actual protocol requirements controls hardware costs without compromising compliance coverage for any role, and a defensible write-up depends on showing the SHA-256 this key validates under FIPS rather than citing the 140-2 certificate number alone. Create a simple matrix that maps each user role to the minimum set of protocols they need, then assign the least expensive key model that satisfies each row, because buying every user a fully-featured key when most only need FIDO2 is an unnecessary expense that adds up quickly across a large organization.

Notes for checking the ePass FIDO2 with CapyToolkit

• No user-facing HMAC API. This key’s SHA-256 use is internal to FIDO2 assertions only and isn’t accessible as a programmable HMAC function. The HMAC-SHA1 tab of the Hash Generator shows what an exposed HMAC API looks like, by contrast.
• FIPS-validated SHA-256. This key’s internal SHA-256 implementation is tied to FIPS 180-4 validation under CMVP #4422, useful for compliance-minded readers comparing that certified implementation against the Hash Generator’s general-purpose HMAC-SHA1 output.

Common questions about the Feitian ePass FIDO2

What does FIPS 140-2 Level 2 mean for a hardware key? FIPS 140-2 Level 2 adds physical security requirements beyond Level 1. The cryptographic module must show evidence of tampering - coatings, seals, or pick-resistant locks - so that physical attacks are detectable. Level 2 also requires role-based authentication to the module. For US federal use, FIPS 140-2 L2 is the minimum required for cryptographic modules protecting sensitive unclassified information.

Is the Feitian ePass FIDO2 approved for US government use? FIPS 140-2 L2 certification means it satisfies the cryptographic module standard required by NIST SP 800-63B for hardware authenticators in federal systems. Whether it is approved for a specific agency or contract depends on the agency’s security policy and any additional requirements beyond FIPS 140-2. CapyToolkit’s device pages flag protocol limits so compliance buyers verify the exact certified use case.

Does the ePass FIDO2 support HMAC operations? No. The ePass FIDO2 is a FIDO2-only device. Its SHA-256 usage is internal to FIDO2 authentication assertions and is not accessible through a user-programmable HMAC API. For hardware HMAC with FIPS-validated SHA-256, evaluate the YubiKey 5 FIPS series.

How does FIPS 140-2 L2 compare to FIPS 140-3? FIPS 140-3 is the updated standard (aligned with ISO 19790:2012) that NIST began approving in 2020. FIPS 140-2 certificates remain valid until 2026, after which new validations require FIPS 140-3. The ePass FIDO2’s FIPS 140-2 L2 validation was active as of May 2026; check NIST’s CMVP database for current certificate status and expiration.

Can I use the ePass FIDO2 for SSH or smart card authentication? No. The ePass FIDO2 does not support PIV (smart card) or OpenPGP applications. It handles FIDO2 WebAuthn and FIDO U2F only. For SSH key authentication stored on hardware, a PIV-capable device such as the YubiKey 5 or Nitrokey 3 is required.

Thetis Pro FIDO2

For the Thetis Pro FIDO2, FIDO2 authentication uses SHA-256 internally¹⁰. When the Thetis Pro FIDO2 authenticates a WebAuthn request, the device signs an authenticator data structure using ECDSA-P256 - which internally hashes with SHA-256. The hash function secures the authentication assertion: the signed payload includes a SHA-256 hash of the client data JSON, binding the authentication response to the specific origin and challenge. This means even though the Thetis Pro does not expose a user-accessible HMAC API, SHA-256 is integral to every login it performs.

At approximately $33 USD¹², the Thetis Pro FIDO2 is the leading budget option among hardware security keys in the US market as of mid-2026. Its primary differentiator is the dual USB-A/USB-C connector - a foldable aluminum body switches between the two form factors on a single device. NFC support enables authentication on mobile devices. The device supports FIDO2, FIDO U2F, and OATH TOTP/HOTP protocols; it does not support HMAC challenge-response, OpenPGP, PIV, or Yubico OTP modes.

The Thetis Pro targets users who need strong second-factor authentication without the cost of a YubiKey 5 series or Nitrokey 3. FIDO2 authentication is phishing-resistant by design: the key binds each credential to a specific origin (website domain), making credential reuse across domains impossible. An attacker who redirects you to a phishing domain cannot get a valid FIDO2 assertion for the legitimate domain.

For use cases that require HMAC challenge-response for offline applications (VeraCrypt, KeePass, custom HMAC authentication), the Thetis Pro is not the right choice - it is FIDO2-only. For browser-based second-factor authentication across accounts, it provides strong security at a price accessible to individual developers and small teams.

Thetis Pro FIDO2 specifications

Specification12	Value
HMAC support	None (FIDO2-only device)
FIDO2 support	Yes - FIDO2/WebAuthn, FIDO U2F
Internal hash usage	SHA-256 in ECDSA-P256 WebAuthn assertions
Connector	Dual USB-A/USB-C (physical slider) + NFC
OS compatibility	Windows, macOS, Linux, Android, iOS
Approximate US retail price	~$33 USD (May 2026)

FIDO2 origin binding blocks phishing at the hardware level

Each credential the Thetis Pro generates is cryptographically bound to the website origin it was registered on, which means the key material is tied to a specific domain at the hardware level and cannot be used anywhere else¹. During registration, the device records the relying party ID, which is the site’s domain. When you authenticate, the browser sends the current origin to the device. If the origin does not match the registered domain, the device refuses to sign the challenge, and the login attempt fails. A phishing site at a lookalike domain cannot receive a valid FIDO2 assertion for the legitimate service, regardless of whether you entered your password.

Why origin binding matters in phishing attacks

The browser sends the exact origin to the authenticator, so a lookalike domain cannot reuse a credential registered elsewhere. This hardware check is stronger than a password prompt because the key refuses the challenge before signing, and no amount of social engineering can persuade the device to sign for a domain it did not originally register with. Even if an attacker tricks you into entering your password on a perfect clone of your bank’s login page, the FIDO2 key simply will not produce a valid assertion for the wrong domain, and the login fails before any session token is issued. This is the core property that separates FIDO2 from SMS-based or TOTP-based second factors, which remain vulnerable to real-time phishing proxies that forward the one-time code to the legitimate site within its short validity window.

This binding is enforced in hardware and cannot be overridden by a browser extension, injected script, or malware running on the host. It is the primary reason FIDO2 security keys are classified as phishing-resistant authenticators under NIST SP 800-63B¹³, and it is also why major browsers and identity providers have made FIDO2 the recommended second-factor method over older approaches like SMS codes and TOTP apps.

For registering with common services, the setup process is the same everywhere

For any service that supports FIDO2 or WebAuthn, registration follows the same three steps regardless of which key brand you use. Navigate to your account security settings and select Add security key. When the browser prompts you, insert the Thetis Pro and press the button. The device generates a unique key pair for that service, stores the private key internally, and sends the public key to the service. The process takes under thirty seconds, and you can repeat it for every account you want to protect with the same physical key.

Registering the same key across multiple accounts

A single Thetis Pro can hold separate credentials for many services, and each credential remains isolated by origin so that a compromise of one service never leaks the key material for another. That lets you use one device for work, personal, and developer accounts without reusing a FIDO2 key pair across different relying parties. The device stores each credential independently, so registering a new service does not expose or weaken any existing credential, and you can revoke access for one service at any time without affecting the others. Most services display the key’s nickname or registration date in their security settings, making it straightforward to audit which accounts a given Thetis Pro protects and to remove credentials for services you no longer use.

Google, GitHub, Microsoft Entra, Cloudflare, and Okta all support FIDO2 security keys for second-factor or password-less login. Connect via USB-A or USB-C using the physical slider switch, or tap the NFC antenna on a compatible Android or iOS device. CapyToolkit lists which protocols each key supports so you can match a key model to the connectors and services your team actually uses before placing an order.

Comparing the Thetis Pro against the YubiKey 5 NFC by protocol scope

Comparing the Thetis Pro to the YubiKey 5 NFC comes down to protocol breadth and price. Both devices provide FIDO2 and FIDO U2F authentication. The YubiKey 5 NFC adds HMAC-SHA1 challenge-response, OpenPGP, PIV smart card, and TOTP; the Thetis Pro provides none of these. For users whose only requirement is browser-based second-factor authentication, the price difference per key represents straightforward savings with no reduction in FIDO2 protection quality.

Checking protocol scope before procurement

For teams that need HMAC challenge-response for KeePassXC or VeraCrypt, or PIV authentication for Windows domain login, the YubiKey 5 NFC is the correct choice. Evaluate protocol requirements across your full user base before committing to a key model for a deployment, and where the key hashes internally during FIDO2 assertions, you can watch SHA-256 run outside the FIDO2 hardware to understand the algorithm, even though this specific device never exposes it as a user-facing function. Survey every team that will use the keys, because a developer who relies on PIV for corporate VPN access has a very different requirement than a designer who only needs FIDO2 for GitHub login, and buying the wrong key model means either paying for unused features or discovering a missing protocol after the keys are already deployed.

Notes for checking the Thetis Pro FIDO2 with CapyToolkit

• No HMAC challenge-response. This key is FIDO2-only with no HMAC slots. Running the HMAC-SHA1 tab of the Hash Generator shows the mechanism this device cannot do, which is why readers who need HMAC (KeePass, VeraCrypt) get pointed to the YubiKey 5 or Nitrokey 3 instead.
• SHA-256 stays internal to FIDO2. This key’s SHA-256 use is inside ECDSA-P256 WebAuthn signing and is never exposed as a user HMAC API, a useful contrast to the Hash Generator’s exposed HMAC-SHA1 computation.

Common questions about the Thetis Pro FIDO2

Does the Thetis Pro FIDO2 support HMAC challenge-response? No. The Thetis Pro is a FIDO2-only device. It does not support HMAC challenge-response slots, OTP modes, OpenPGP, or PIV. If you need hardware HMAC for offline applications (VeraCrypt, KeePass, custom HMAC authentication), use a YubiKey 5 series instead.

How does FIDO2 use SHA-256 internally? FIDO2 authentication uses ECDSA-P256, which signs the SHA-256 hash of the authenticator data and client data. The client data JSON includes a SHA-256 hash of the origin URL, binding the assertion to the specific website. The device never exposes this hash function to user-level code - it is internal to the FIDO2 protocol.

What is the difference between FIDO2 and FIDO U2F? FIDO U2F (Universal 2nd Factor) is the older protocol, used as a second factor alongside a password. FIDO2/WebAuthn is the newer standard that supports password-less authentication in addition to second-factor use. The Thetis Pro supports both. Modern deployments prefer FIDO2 for its broader capability set and wider browser support.

Is the Thetis Pro FIDO2 suitable for enterprise use? It handles FIDO2 authentication as well as more expensive keys for most enterprise use cases. The limitation is protocol breadth - enterprises that require PIV (smart card) for Windows login, OpenPGP for email signing, or HMAC challenge-response for custom applications need a YubiKey 5 or Nitrokey 3. CapyToolkit’s comparison pages highlight protocol scope before price. For browser-based SSO and account protection, the Thetis Pro is fully adequate.

How do I register the Thetis Pro FIDO2 with a website? Navigate to the security settings of any FIDO2-supporting service (Google, GitHub, Microsoft, Cloudflare). Select “Add security key” and follow the prompts. When asked, insert the key and touch the button. The registration uses FIDO2 WebAuthn to bind a credential to your account and the website’s origin.

Google Titan

Where Yubico spreads seven protocols across its 5-series keys, Google’s Titan Security Key keeps things narrow: FIDO2/WebAuthn and FIDO U2F only, on a purpose-built secure element chip designed specifically for high-assurance authentication.¹⁴ That narrower focus comes with a lower price, $35 for the USB-C/NFC model against the YubiKey 5C NFC’s $58, and a notably larger passkey capacity of up to 250 discoverable credentials, well beyond the 100-credential limit on Yubico’s comparable 5-series keys.¹⁵ The USB-C model supports NFC tap authentication on most Android and iOS phones, while the USB-C-to-USB-A adapter ships only with the USB-A/NFC key. As with any hardware key, though, plenty of your accounts will still lean on a password somewhere in the recovery chain, which is where the entropy fundamentals behind the Password Entropy Analyser still apply.

Google Titan Security Key (USB-C) specifications

Specification	Value
Connector	USB-C (USB-A adapter not included)
NFC support	Yes, for compatible phones
Protocols	FIDO2/WebAuthn, FIDO U2F
Passkey capacity	Up to 250 discoverable credentials
Price	$35 (PCMag)

Where the Titan Key trades protocol breadth for passkey capacity

Skipping OTP, PIV, and OpenPGP support keeps the Titan Key’s firmware simpler and its price lower than a multi-protocol key like Yubico’s 5C NFC. For most people whose hardware key usage is entirely FIDO2 passkey logins, that narrower scope costs nothing in practice while saving about $23 against a comparable multi-protocol key.

Why narrower protocol support still covers most users

FIDO2 and FIDO U2F together cover passkey login and hardware two-factor authentication for the overwhelming majority of consumer services, which means the missing OTP, PIV, and OpenPGP features matter only in specialized environments. Most personal accounts never need those extras, since the protocols the Titan Key does implement already cover anything involving web logins, app authentication, or FIDO2 passkey verification. The omissions begin to matter only when you also want SSH key storage, GPG signing, or access to legacy OTP-only systems, all of which require a multi-protocol key rather than the Titan Key’s FIDO2/U2F-only firmware.

If your workflow never touches SSH key storage, GPG signing, or legacy OTP-only systems, the Titan Key’s firmware is doing everything you actually need at a lower price and with a simpler attack surface. The tradeoff shows up specifically if you also want SSH key storage or GPG signing on the same device, neither of which the Titan Key’s FIDO2/U2F-only firmware supports. Its 250-credential passkey capacity, though, comfortably outpaces what most people will register across every service they use, even accounting for future passkey adoption growth.

For a household managing several family accounts across a shared set of services, that larger credential ceiling matters more than it might for a single user, since registering the same key across multiple people’s logins consumes slots faster than registering it for one person alone. Running out of discoverable credential slots on a 100-capacity key is a realistic scenario in that setup; running out at 250 is not.

The secure element and firmware verification

Google built the Titan Key around a hardware chip running firmware Google engineered itself, which verifies the key’s integrity and helps ensure the key has not been physically tampered with.¹⁴ That check is a defense aimed at supply-chain attacks rather than the more common threat of a stolen password or phished login.

Why this matters beyond marketing language

This kind of hardware-level trust anchor addresses a threat model regular password entropy cannot: an attacker who compromises the physical key’s firmware before it ever reaches you. It does not change how you should think about your remaining passwords, but it does explain why a purpose-built secure element commands a price premium over a generic USB security dongle. For most individual buyers, this supply-chain protection is a background guarantee rather than a daily concern, but it matters more for organizations distributing keys to a large number of employees through third-party channels, where a compromised shipment could otherwise go unnoticed until well after deployment.

Why the hardware benefit is only half the story

Even when the firmware is intact and verified, the account recovery path and any backup password you set still need the same entropy scrutiny as any other credential. A hardware key protects the login itself, but it does not protect the recovery email, backup password, or fallback method a service may still require. Those still fall under ‘something you know,’ and that is exactly where password entropy matters most. CapyToolkit offers a tool that grades a recovery password’s resistance to guessing, which does not change how the Titan Key secures the login step but does help explain why recovery credentials still need to be strong no matter how capable the hardware key is.

From the user’s standpoint, that distinction matters most when deciding whether to trust a cheaper key bought through a marketplace rather than directly from the manufacturer or an authorized reseller; a tampered firmware image is exactly the kind of failure a password entropy score cannot reveal, because the vulnerability exists at the hardware layer before any password ever enters the system.

Real user feedback: the risks of a small, easy-to-lose key

PCMag describes the Titan Key as small enough to hang on a keychain,¹⁵ and a key that small is also easy to misplace. Because losing your only hardware key can lock you out of an account entirely, registering a backup key and keeping it somewhere physically separate from your primary key matters as much here as it does for any hardware authenticator.

Mashable found setup easy for Google accounts but noted that Google cannot control how other FIDO services handle it, a fair point given that WebAuthn registration flows vary noticeably between browsers and operating systems. None of this changes the underlying security the key provides once set up, but it does mean the recovery codes and backup passwords generated during that setup deserve the same entropy scrutiny as any other credential you rely on. Budgeting a few extra minutes for the initial registration, and testing the key against a low-stakes account first, avoids the frustration reviewers describe while you still have full access to fall back on.

Notes for checking the Titan Security Key (USB-C) with CapyToolkit

• Recovery path stays password-based. This key protects your login, but your recovery email or backup password still falls under something you know, which is exactly where entropy matters most.
• Easy to lose, needs a backup. User reviews flag this key’s small size as easy to misplace. The recommended second-key or backup-code path still depends on entropy the same way your primary recovery password does.

Common questions about the Google Titan Security Key

Is the Google Titan Key as secure as a YubiKey? For FIDO2 and U2F authentication specifically, both meet the same open FIDO standards and provide comparable security. The Titan Key adds a custom secure element with Google-verified firmware, while YubiKey’s advantage is broader protocol support, OTP, PIV, and OpenPGP, that the Titan Key does not include. Both keys rely on the same phishing-resistant login standard, and CapyToolkit’s password entropy tool helps explain why the recovery password still needs genuine randomness regardless of which key you choose. You would use it to judge the strength of any backup password protecting a key recovery path.

Why is the Titan Key cheaper than a YubiKey 5C NFC? The Titan Key supports only FIDO2 and FIDO U2F, while the YubiKey 5C NFC supports five additional protocols including PIV smart card and OpenPGP. That narrower feature set, along with Google’s manufacturing scale, keeps the Titan Key’s price well below the comparable multi-protocol YubiKey.

What happens if I lose my only Titan Security Key? You would need to use a backup authentication method, typically a recovery code or a second registered key, to regain access to your accounts. This is exactly why registering a second Titan Key or a different FIDO2 key as backup, stored separately from your primary key, is standard security advice.

Does the USB-C Titan Key work on older USB-A-only computers? Yes, though the USB-C-to-USB-A adapter is bundled with the USB-A/NFC model rather than the USB-C one, so connecting a USB-C key to an older port takes a separate adapter purchase. NFC tap authentication also works independently of the USB connector on supported phones.

Can the Titan Key store passkeys for non-Google services? Yes. Despite the Google branding, the Titan Key works with any service supporting the open FIDO2 and WebAuthn standards, including Microsoft accounts, Amazon, and password managers like Bitwarden and 1Password, not only Google’s own services.

Kensington VeriMark Guard

A fingerprint replaces the PIN step entirely on Kensington’s VeriMark Guard, the first device in this lineup to build biometric matching directly into the FIDO2 key itself rather than relying on a laptop’s own sensor. Certified for FIDO2, WebAuthn/CTAP2, and FIDO U2F, the key uses Match-in-Sensor technology that isolates fingerprint data inside the sensor chip, so only an encrypted match or no-match result ever leaves the device. It supports up to 10 enrolled fingerprints and carries an MSRP of $69.99, positioning it between Yubico’s budget and premium keys on price.¹⁶ Because biometric authentication measures something fundamentally different from password entropy, a physical trait rather than a memorized secret, this section also covers where the two concepts intersect and where they stay entirely separate.

Kensington VeriMark Guard (USB-C) specifications

Specification	Value
Connector	USB-C
Protocols	FIDO2, WebAuthn/CTAP2, FIDO U2F
Biometric capacity	Up to 10 enrolled fingerprints
False rejection rate	2% (FRR)
False acceptance rate	0.001% (FAR)

How Match-in-Sensor fingerprint matching works, and why it isn’t entropy

The VeriMark Guard’s Match-in-Sensor design performs the entire fingerprint comparison inside the sensor chip itself, meaning your raw fingerprint image never travels to the host computer, only an encrypted pass or fail signal does. This isolates the biometric data from the same kind of exposure a stolen password database creates, since there is no fingerprint template stored anywhere an attacker could exfiltrate at scale.

A different security factor entirely

Unlike a password or PIN, a fingerprint has no meaningful entropy measurement in bits, because you are not choosing it from a keyspace an attacker could theoretically brute-force. Biometrics fall under ‘something you are’ rather than ‘something you know,’ which is precisely why they pair with, rather than replace, the entropy-based secrets the Password Entropy Analyser measures; a fingerprint unlocks the key’s cryptographic operation, but a PIN or password still exists as a fallback path.

Combining a biometric factor with a cryptographic key also means an attacker cannot simply replicate what you know, the way they could with a phished password. They would need physical possession of the key itself, and a fingerprint convincing enough to pass Match-in-Sensor verification, which raises the bar considerably above anything credential-based alone can offer.

The accuracy numbers: FRR and FAR explained

Kensington rates the VeriMark Guard at a 2% false rejection rate and a 0.001% false acceptance rate.¹⁶ The false rejection rate means roughly 2 in 100 legitimate authentication attempts get incorrectly rejected, requiring a retry, a usability cost rather than a security one. The false acceptance rate is the security-relevant figure: roughly 1 in 100,000 attempts by a fingerprint that is not actually enrolled would be incorrectly accepted as a match.

What the 0.001% false acceptance rate means in practice

That 0.001% figure exceeds the accuracy typical consumer fingerprint sensors report, though it still is not zero, which is exactly why FIDO2 hardware keys pair biometric unlock with an underlying cryptographic key rather than using the fingerprint match as the entire security boundary on its own. A device that relied purely on a 99.999% accurate sensor would still need a fallback for the roughly 2% of legitimate attempts the sensor itself misreads, which is exactly the gap the underlying PIN and cryptographic key are built to cover.

A known software issue, and what still needs a strong PIN

At least one independent review found Kensington’s management software failed to launch on Windows 11 during testing, though the key itself continued to function normally for enrollment and authentication once fingerprints were registered through the operating system’s own settings. If you hit a similar issue, registering fingerprints directly through Windows Hello or your browser’s WebAuthn prompt sidesteps the standalone management app entirely.

Why the PIN still matters even with biometrics enabled

Every FIDO2 device, including the VeriMark Guard, still requires a PIN as a fallback authentication path for account recovery or for devices where biometric enrollment fails. That PIN’s entropy matters exactly as much as any other PIN discussed elsewhere in the Password Entropy Analyser, since the fingerprint convenience layer does not change the underlying cryptographic requirements of the FIDO2 standard beneath it.

Choosing a longer FIDO2 PIN than the minimum a device requests, where the option exists, closes the gap between the fallback path’s security and the biometric path’s much lower practical guess rate, a gap worth checking directly by comparing a fallback PIN’s guess odds rather than assuming the minimum length is enough. Most FIDO2 implementations also lock out PIN attempts after a small number of failures, adding the same kind of throttling protection discussed elsewhere in the Password Entropy Analyser for numeric codes, so a stolen key alone still cannot be brute-forced open in any practical timeframe.

Notes for checking the VeriMark Guard (USB-C) with CapyToolkit

• PIN is still the fallback. Every FIDO2 device, including this one, requires a PIN as a fallback for recovery or failed fingerprint enrollment. That PIN’s entropy matters exactly as much as any other PIN the Password Entropy Analyser scores.
• Biometrics aren’t entropy. A fingerprint has no bit-based entropy measurement since it isn’t chosen from a keyspace. That’s why it falls under something you are rather than something the entropy tool can evaluate.

Common questions about the Kensington VeriMark Guard

Can someone steal my fingerprint data from a VeriMark Guard? The Match-in-Sensor design specifically prevents this by performing fingerprint comparison inside the sensor chip and never transmitting the raw fingerprint image to the connected computer. Only an encrypted match or no-match result leaves the device, so there is no fingerprint template exposed to a compromised host machine.

What does a 0.001% false acceptance rate actually mean? It means roughly 1 in every 100,000 authentication attempts by a fingerprint that was never enrolled would incorrectly be accepted as a valid match. This figure describes the biometric sensor’s accuracy, separate from the underlying FIDO2 cryptographic security, which does not depend on the fingerprint match alone.

Do I still need to set a PIN if I use fingerprint login on the VeriMark Guard? Yes. FIDO2 hardware keys require a PIN as a fallback authentication method regardless of biometric capability, used for account recovery or on devices where fingerprint enrollment is not available. CapyToolkit’s password entropy checker scores that fallback PIN the same way it scores any other PIN, since the fingerprint layer never replaces the underlying cryptographic requirement. That PIN’s strength still follows the same entropy principles as any other PIN.

Why did the management software fail to launch on Windows 11 in some reviews? At least one independent review reported this issue without a confirmed root cause disclosed publicly. The key’s core FIDO2 authentication and fingerprint enrollment functioned normally through the operating system’s native settings even when the standalone Kensington management app failed to open.

How many fingerprints can I register on one VeriMark Guard? Up to 10 fingerprints per device, which is enough to register multiple fingers from the same hand for redundancy, or to share one physical key among a small number of trusted users, each enrolling their own fingerprint for individual verification.

Yubico Security Key C NFC

Twenty-nine dollars buys the simplest entry point into Yubico’s hardware key lineup, a USB-C and NFC key that supports only two protocols, FIDO2/WebAuthn and FIDO U2F, deliberately stripped down from the seven protocols on Yubico’s premium 5-series keys.¹⁷ That narrower scope is not a downgrade in security so much as a different target buyer: someone who wants passkey and two-factor login coverage without paying for smart card or OpenPGP features they will never touch. It shares the same IP68 water and dust resistance and crush-resistant housing as Yubico’s more expensive keys, built on the same manufacturing standard. This section covers its exact specs, how its passkey capacity compares to the pricier 5C NFC, and who should actually choose the budget option.

Yubico Security Key C NFC specifications

Specification17	Value
Connector	USB-C 2.0
NFC support	Yes (ISO 14443-3 Type A)
Protocols	FIDO2/WebAuthn, FIDO U2F only
FIDO2 passkey capacity	100 discoverable credentials
Price	$29 (Yubico direct)

What you get, and what you deliberately don’t

The Security Key C NFC supports FIDO2/WebAuthn and FIDO U2F only, the two protocols that cover passkey login and hardware two-factor authentication for the overwhelming majority of consumer services. Missing entirely are OTP, OATH-TOTP/HOTP, PIV smart card, and OpenPGP, the protocols that let Yubico’s 5-series keys double as SSH key storage or GPG signing hardware.

For anyone whose hardware key usage begins and ends at logging into websites and apps, that missing feature set costs nothing in practice. The protocols the Security Key C NFC does implement follow the same FIDO Alliance open standards as every other certified key on the market, so the login security itself is not a reduced or simplified version of anything.

Why open-standard compliance rules out vendor lock-in

That standards compliance matters because it means the Security Key C NFC is not a proprietary, Yubico-only authentication method. Any service that has implemented WebAuthn correctly will accept it exactly as it would accept a YubiKey 5-series key or a competitor’s FIDO2 device, since the specification, not the manufacturer, defines what a compliant authenticator must support. That interoperability is part of what makes shopping by price rather than brand a reasonable strategy once you have confirmed FIDO2 and U2F are the only protocols you actually need, since no service can lock you into one manufacturer’s hardware once the open standard is what actually gets checked at login.

Same 100-credential capacity as the premium key

Despite the lower price, the Security Key C NFC shares its parent Security Key Series firmware with Yubico’s NFC-enabled keys, supporting the same 100 discoverable FIDO2 credential slots found on the YubiKey 5C NFC. Passkey storage capacity, in other words, is not where Yubico differentiates its budget and premium tiers.

The actual differentiator is protocol count, not passkey limits

Because the two keys match on discoverable credential capacity, someone choosing between them purely for FIDO2 passkey logins gains nothing from paying the premium-tier price. The gap only opens up once you need one of the additional protocols exclusive to the pricier keys, at which point the decision becomes about those specific features rather than about passkey capacity or FIDO2 security strength.

That gap only matters once a specific workflow calls for one of those missing protocols. Someone managing SSH access or signing Git commits with GPG will find the extra hardware worth paying for, but a login-only user gains nothing from protocols they will never invoke, since those unused signing and smart-card slots stay completely dormant on a key that only ever answers a FIDO2 challenge.

Who should buy the budget key over the 5C NFC

If your hardware key use case is entirely passkey login and two-factor authentication for consumer or workplace accounts, the Security Key C NFC delivers an identical FIDO2 security posture to the $58 YubiKey 5C NFC for roughly half the price. The underlying cryptography, credential capacity, and certification are the same; only the protocol count differs.

Developers, system administrators, and anyone managing SSH access or signing commits with GPG should skip the budget key and go straight to a multi-protocol option, since retrofitting those capabilities later means buying a second key rather than upgrading the first one’s firmware. For everyone else, the Security Key C NFC is the more cost-effective choice without a meaningful security tradeoff.

Where the savings compound: outfitting multiple people

A household outfitting several people with backup hardware keys is a good example of where the savings add up. At $29 apiece, four Security Key C NFC keys for family members, each with its own recovery password entropy to track, cost roughly the same as one or two premium $58 5C NFC keys, while providing the same FIDO2 login coverage and the same 100-credential capacity across every account that matters day to day.

Notes for checking the Security Key C NFC with CapyToolkit

• Budget key, same recovery gaps. This stripped-down FIDO2/U2F-only key still leaves backup recovery codes and your password manager’s master password dependent on entropy, scored the same regardless of which Yubico tier you bought.

Common questions about the Yubico Security Key C NFC

Is the Security Key C NFC less secure than the YubiKey 5C NFC for logging in? No. Both implement the same FIDO2/WebAuthn and FIDO U2F protocols to the same open standard, and both support 100 discoverable credentials. The 5C NFC’s security advantage only appears if you use its additional protocols, OTP, PIV, or OpenPGP, none of which affect FIDO2 login strength.

Can I upgrade a Security Key C NFC to support more protocols later? No. The protocol set is fixed in the key’s firmware at manufacturing and cannot be expanded after purchase. If you later need PIV or OpenPGP support, you would need to buy a separate multi-protocol key such as the YubiKey 5C NFC rather than upgrading the existing one.

Does the Security Key C NFC work with NFC on my phone the same way as the 5C NFC? Yes. Both keys use the same ISO 14443-3 Type A NFC interface and the same first-use activation behavior, requiring an initial USB connection on newer firmware before NFC responds. NFC reliability depends more on your phone’s case and antenna position than on which key model you use.

Is $29 worth it compared to a free authenticator app? A hardware key resists phishing in a way an authenticator app cannot, since a FIDO2 key cryptographically verifies the website’s domain before responding, while a one-time code from an app can be phished and relayed by an attacker regardless of how it was generated.

Should I still use a strong password with a Security Key C NFC registered? Yes, wherever a password still exists in your login chain: backup recovery codes, any service without passkey support, and your password manager’s master password all still depend on entropy rather than on the hardware key. CapyToolkit’s password entropy checker scores those recovery codes and manager passwords the same way it scores any other credential, since the hardware key only replaces the password for services that support FIDO2 directly.

YubiKey 5C NFC

Yubico’s YubiKey 5C NFC packs seven authentication protocols into a single USB-C key: FIDO2/WebAuthn, FIDO U2F, Yubico OTP, OATH-TOTP, OATH-HOTP, PIV smart card, and OpenPGP, all on one piece of IP68-rated hardware manufactured in Sweden.¹⁸ It sits at the premium end of Yubico’s lineup, priced at $58 directly from Yubico, aimed at users who need more than basic FIDO2 login support.

A hardware key like this one removes the password from the login flow entirely for services that support passkeys, replacing a guessable secret with a cryptographic challenge the key alone can answer. Yet a surprising number of accounts still fall back on a password somewhere, whether as a recovery mechanism, a legacy login path a service has not yet upgraded, or the master password protecting the vault where your other credentials live. This section covers the 5C NFC’s full specification, its less obvious protocol capabilities, and the entropy considerations that still apply even after you have one in hand.

Yubico YubiKey 5C NFC specifications

Specification18	Value
Connector	USB-C 2.0
NFC support	Yes (ISO 14443-3 Type A)
Protocols	FIDO2/WebAuthn, FIDO U2F, Yubico OTP, OATH-TOTP/HOTP, PIV, OpenPGP
FIDO2 passkey capacity	100 discoverable credentials
Price	$58 (Yubico direct)

Why a hardware key doesn’t retire password entropy entirely

Registering a YubiKey with most services triggers a set of one-time backup codes, meant for the scenario where you lose the key or it stops working. Those codes are themselves short alphanumeric strings, and their entropy depends entirely on how the issuing service generated them. Treating that generation with the same care as a login password, and measuring a backup code’s entropy like a password, matters because these codes bypass the hardware layer entirely, so any attacker who learns one can log in without the physical key present.

When poorly generated backup codes undercut the key’s security

A poorly implemented backup code system can undercut the security gain the hardware key was supposed to provide, because a short or predictable code stands in as a full account bypass with none of the cryptographic protections the hardware key offers. These recovery codes exist as a fallback, but their quality varies widely across services, with shorter or sequentially predictable codes offering little real protection against attackers who intercept them or phish them directly after registration.

Beyond backup codes, plenty of accounts still require a password directly: the master password unlocking your password manager, admin logins on infrastructure that has not adopted passkeys, and any service where FIDO2 support simply is not available yet. A hardware key changes what you authenticate with day to day; it does not remove every password from your life, which is exactly why understanding the entropy behind the ones that remain still matters. Treat the backup codes generated at registration with the same care as a high-value password, since they are typically shown only once and function as a full bypass of the hardware key requirement.

The multi-protocol advantage, and where it actually matters

Most buyers reach for a YubiKey purely for FIDO2 login, but the 5C NFC’s other protocols solve problems FIDO2 alone cannot. The PIV applet lets you store an SSH key directly on the hardware token, so signing into a server never exposes a private key file on your laptop’s disk at all. The OpenPGP applet does the same for GPG commit signing and email encryption, keeping the private key material physically isolated on the device.

When OTP still earns its place

Yubico OTP and OATH-TOTP/HOTP cover services that never adopted FIDO2 but do support one-time codes, letting a single key act as your second factor across a much wider range of accounts than passkey-only hardware could reach. Because all seven protocols share the same physical key, you are not carrying multiple devices to cover different authentication standards across your accounts. For anyone maintaining a mixed fleet of legacy and modern services, that consolidation removes the need to keep a separate phone-based authenticator app solely for systems that have not yet enabled FIDO2.

Where the hardware especially pays off is in shared or loaner devices where you cannot rely on a persistent app installation; the key carries the credential material with you rather than leaving it behind on a machine you may not control. That portability matters for people who move between workstations frequently or who are providing their own hardware in a bring-your-own-device environment, because none of those sessions can recover a private key left behind on a previous machine’s disk after the fact.

Setup notes and the NFC activation quirk

Keys shipping with firmware above version 5.7 ship with NFC in a restricted mode by default; if you have never plugged the key into a USB port before, NFC will not respond until you connect it to any USB power source for at least three seconds to activate it. This trips up a fair number of first-time buyers who try NFC tap-to-authenticate straight out of the box on a phone. Once that initial activation completes, the restriction is lifted permanently for the key’s remaining lifetime, so you only need to perform that three-second USB connection once rather than before every mobile login.

Getting reliable NFC taps after activation

Once activated, NFC reliability still depends on your phone’s case and the key’s orientation against the NFC reader, and Yubico’s own support documentation notes you may need to hold the key at an unusual angle, sometimes 45 degrees, and longer than a typical NFC tag, since the key performs a real cryptographic operation rather than reading a static tag. Removing a thick case before your first NFC attempt resolves most reported issues.

Once you clear that first-use hurdle, subsequent registrations and logins tend to go smoothly, since the same activation state persists across the key’s lifetime rather than resetting between uses. That means the lost-key recovery codes generated during setup and any NFC tap-in flows you rely on remain usable indefinitely without repeating the USB activation step, because the hardware never reverts to restricted mode once it has been unlocked.

Notes for checking the YubiKey 5C NFC with CapyToolkit

• Backup codes bypass the hardware. Registering this key triggers one-time backup codes that bypass the hardware layer entirely. A poorly generated one undercuts the whole security gain, which is exactly what the Password Entropy Analyser is for.
• Seven protocols, still a master password. Even with PIV, OpenPGP, and OTP covering most logins, your password manager’s master password remains untouched by this hardware key. That’s why it still needs checking for entropy.

Common questions about the YubiKey 5C NFC

Do I still need a strong password if I use a YubiKey 5C NFC? Yes, for the accounts and recovery paths that still rely on one. The backup codes generated when you register the key, your password manager’s master password, and any service without passkey support all still depend on password or code entropy, so the fundamentals covered by the Password Entropy Analyser remain relevant even with a hardware key in daily use.

Should I buy two YubiKeys instead of one? Yubico and most security guidance recommend registering a second key as a backup, stored somewhere separate from your primary key, since losing your only hardware key can lock you out of accounts that require it. The 5C NFC’s $58 price makes a second key a modest cost against that risk.

Does the YubiKey 5C NFC work with a phone that has no USB-C port? Yes, via NFC. Most modern Android and iOS devices support NFC tap authentication with the 5C NFC even when the physical USB-C connector cannot be used, provided NFC has already been activated by an initial USB connection.

What is the difference between the 5C NFC and the cheaper Security Key C NFC? The Security Key C NFC supports only FIDO2 and FIDO U2F for about $29, while the 5C NFC adds Yubico OTP, OATH-TOTP/HOTP, PIV smart card, and OpenPGP for $58. Choose the 5C NFC if you need SSH key storage, GPG signing, or one-time-code support beyond basic passkey login.

Can I use the same YubiKey across multiple accounts and services? Yes. A single YubiKey 5C NFC can register as a FIDO2 authenticator on up to 100 discoverable passkeys, and its OTP and smart card functions work independently across as many services as support those protocols, all from the same physical device. CapyToolkit does not replace advice about physical-key management, but the password entropy tool does highlight why even a hardware-backed account still needs a strong recovery credential if your backup path falls back to a password or one-time code.

What a Browser Can’t Confirm, and When to Trust the Key Anyway

Be honest about the limits. A browser tool can’t test the physical USB controller, can’t prove the key is in your pocket, and can’t tell you whether someone else enrolled a key before it reached you. Those are hardware and custody questions no amount of certificate reading answers from a desk. None of this tells you the key in your hand is the one you ordered rather than a seller swapping the unit inside genuine packaging. Buy from a vendor you trust and check the seal, because a genuine key from a dishonest seller is still a problem the browser can’t see.

A clean attestation chain tells you the model and firmware are the real deal. It never tells you the key is in your pocket, because possession only shows up when the live challenge fires at login. So the chain is necessary and not sufficient: a genuine key in the wrong hands is still a genuine key, and the browser check names the device without naming who holds it right now.

Trust the key when the chain reads clean, the backup password clears the entropy bar, and you’ve got a recovery plan that doesn’t silently lean on a single weak factor. That combination is what verified should mean, not just the light turning green on the first tap. A key that passes all three checks has earned its place in your accounts.

Sources

1. 1.

   Mozilla Developer Network, “Web Authentication API,” developer.mozilla.org, accessed August 2026. https://developer.mozilla.org/en-US/docs/Web/API/Web_Authentication_API

2. 2.

   Microsoft Learn, “WEBAUTHN_COMMON_ATTESTATION structure (webauthn.h),” learn.microsoft.com, June 2026. https://learn.microsoft.com/en-us/windows/win32/api/webauthn/ns-webauthn-webauthn_common_attestation

3. 3.

   Elaine Barker and Allen Roginsky, “Transitioning the Use of Cryptographic Algorithms and Key Lengths,” SP 800-131A Rev. 2, NIST, March 2019. https://csrc.nist.gov/pubs/sp/800/131/a/r2/final

4. 4.

   Yubico, “WebAuthn Client Registration,” developers.yubico.com, accessed August 2026. https://developers.yubico.com/WebAuthn/WebAuthn_Developer_Guide/WebAuthn_Client_Registration.html

5. 5.

   Peter Eckersley, “Is Every Browser Unique? Results From The Panopticlick Experiment,” Electronic Frontier Foundation, May 2010. https://www.eff.org/deeplinks/2010/05/every-browser-unique-results-fom-panopticlick

6. 6.

   NIST, “Digital Identity Guidelines: Authentication and Lifecycle Management,” SP 800-63B, pages.nist.gov, June 2017. https://pages.nist.gov/800-63-3/sp800-63b.html

7. 7.

   Daniel Lowe Wheeler, “zxcvbn: Low-Budget Password Strength Estimation,” USENIX Security ‘16, August 2016. https://www.usenix.org/conference/usenixsecurity16/technical-sessions/presentation/wheeler

8. 8.

   Yubico, “Challenge-response,” docs.yubico.com, accessed June 2026. https://docs.yubico.com/yesdk/users-manual/application-otp/challenge-response.html

9. 9.

   NIST, “Cryptographic Module Validation Program: Certificate #4422,” csrc.nist.gov, accessed October 2026. https://csrc.nist.gov/projects/cryptographic-module-validation-program/certificate/4422

10. 10.

    W3C, “Web Authentication: An API for accessing Public Key Credentials - Level 2,” w3.org, accessed October 2026. https://www.w3.org/TR/webauthn-2/

11. 11.

    Wikipedia, “FIPS 140-2,” en.wikipedia.org, accessed October 2026. https://en.wikipedia.org/wiki/FIPS_140-2

12. 12.

    Thetis, “Thetis PRO FIDO2 Security Key - Passkey, USB-A, USB-C & NFC,” thetis.io, accessed October 2026. https://thetis.io/products/fido2-key-usb-a-c-nfc

13. 13.

    NIST, “Digital Identity Guidelines: Authentication and Lifecycle Management,” SP 800-63B-4, pages.nist.gov, accessed October 2026. https://pages.nist.gov/800-63-4/sp800-63b.html

14. 14.

    Google Store, “Titan Security Key - FIDO2 USB-A/USB-C + NFC,” store.google.com, accessed October 2026. https://store.google.com/product/titan_security_key?hl=en-US

15. 15.

    PCMag, “Google Titan Security Key Review: Simple, Effective Passkey Storage,” pcmag.com, accessed October 2026. https://www.pcmag.com/reviews/google-titan-scurity-key

16. 16.

    Kensington, “VeriMark Guard USB-C Fingerprint Security Key - FIDO2, WebAuthn/CTAP2, & FIDO U2F - Cross Platform,” kensington.com, accessed October 2026. https://www.kensington.com/p/products/data-protection/fingerprint-security-keys/verimark-guard-usb-c-fingerprint-security-key-fido2-webauthnctap2-fido-u2f-cross-platform/

17. 17.

    Yubico, “Security Key NFC by Yubico,” yubico.com, accessed October 2026. https://www.yubico.com/product/security-key-nfc-by-yubico/

18. 18.

    Yubico, “YubiKey 5C NFC,” yubico.com, accessed October 2026. https://www.yubico.com/product/yubikey-5c-nfc/