FIDO2 Hardware Security Keys: What They Do—and What They Don’t

A FIDO2 key can make supported logins harder to phish by keeping cryptographic credentials on a physical device. Its protection depends on compatible software, sound setup, and verifying the service or server you are connecting to.

What a FIDO2 key is

A FIDO2 hardware security key is a small physical device that performs cryptographic authentication. FIDO2 is a set of standards that includes WebAuthn, commonly used for signing in to websites, and CTAP, which lets a computer or phone communicate with the key. Depending on the key and host device, that connection may use USB, NFC, or Bluetooth.

Instead of sending a reusable password to a service, a compatible sign-in flow asks the key to prove possession of a private cryptographic credential. The private key is held by the device and is generally not exported. The service stores a corresponding public key. A sign-in can require a physical touch, a local PIN, or another form of user verification, depending on the implementation.

How it relates to SSH

FIDO2 is not automatically a replacement for every kind of authentication. For SSH, support depends on the client, operating system, and server configuration. OpenSSH can use security-key-backed public-key credentials, commonly identified by key types such as ecdsa-sk or ed25519-sk. In this arrangement, the key helps prove the user’s identity during SSH authentication; it does not change the SSH protocol’s separate job of establishing an encrypted connection.

That distinction matters. A security key used for SSH authentication does not, by itself, confirm that the remote server is the intended server. SSH host-key checking remains essential: compare and validate the server’s host key through a trusted channel, and investigate unexpected changes rather than accepting them reflexively. A hardware key cannot make a diverted or impersonated destination trustworthy.

Specifications and compatibility to check

Start with the systems and login flows you actually use. Check whether the service supports FIDO2/WebAuthn or whether your SSH client supports security-key-backed credentials. Confirm the required connector or wireless method works with your computers and phones. Some keys support a PIN or biometric-related features; these options are not universal and do not all work the same way across services.

• Confirm protocol support on both the client and the service or server.
• Check connector type, operating-system support, and any required companion software.
• Understand whether the login requires a touch, PIN, or local user verification.
• Plan how to recover access if the key is lost, damaged, or unavailable.

Setup, backup, and maintenance

Enroll the key through the service’s official security settings, or follow your organization’s documented SSH setup. Register a second key where supported, store it separately, and test recovery before relying on the primary key. Keep recovery codes or alternate access methods protected; they can become the weak link if handled casually. For SSH, protect local private-key files and their passphrases as appropriate, and keep a record of which systems trust each public key.

Test authentication from each device you use, including after software or account changes. Keep the key physically secure and avoid sharing it. If it is lost or suspected compromised, remove its credentials from affected accounts and systems, then enroll a replacement. A key’s presence does not justify ignoring account alerts or unexpected authentication prompts.

Limits and common mistakes

A FIDO2 key helps with supported authentication, but it does not encrypt all network traffic, secure an infected computer, prevent every account-recovery attack, or prove that a remote SSH host is genuine. It also cannot help when a service falls back to a weaker login path that an attacker can exploit. Do not assume that any device described as a security key supports every FIDO2 feature, or that a key registered for a website automatically works with SSH.

The useful question is not whether a physical key is universally safer, but whether the systems in your workflow support it correctly and whether you have verified the endpoints you connect to. Strong authentication and careful server-identity checks address different parts of the login process; both deserve attention.