How should teams use hardware FIDO2 keys to protect SSH access to remote infrastructure?

Why FIDO2 hardware keys fit SSH for remote infrastructure

SSH access becomes much stronger when the login step is tied to a physical authenticator rather than a reusable password or a secret that can be copied. For remote infrastructure, that matters because the trust boundary is often an internet-exposed endpoint, and the attacker goal is usually to turn a stolen secret into durable access. A FIDO2 key changes the problem from “know a secret” to “possess the device and satisfy local user verification.”

This is also why teams should prefer the SSH-native FIDO2 flow instead of bolting on weaker compensating controls. The practical value is not just phishing resistance, it is that the private key material stays on the authenticator and the host only sees the derived public key structure that SSH expects. That keeps the authentication model usable for administrators without reintroducing password reuse, shared secrets or agent forwarding shortcuts that expand exposure.

For teams standardising the approach, Passwordless and Passkeys Guide is the clearest companion for understanding how FIDO2 and WebAuthn shift sign-in away from reusable secrets, and Hardware Security Keys Guide covers the device-side details that matter for PINs, backup keys and loss handling.

What changes in SSH operations when the key is hardware-backed

With hardware-backed SSH authentication, the main operational change is that access now depends on possession of a specific key plus local unlock, not on a password stored in a vault, password manager or clipboard. That reduces the chance that a credential dump, phishing page or reused password can open a shell on remote systems. It also gives teams a cleaner way to enforce individual accountability because each administrator can be issued a distinct device-bound credential.

OpenSSH support is important here because the workflow needs to remain practical at scale. Teams should make sure their SSH clients and servers support the FIDO2 key type they plan to use, then publish the matching public key in the format SSH accepts so normal administrative access does not depend on custom wrappers or brittle manual steps. The control is strongest when the process is boring for operators, because awkward workflows are what usually push teams back toward password exceptions.

When SSH is part of broader remote access design, the same logic applies to bastions, jump hosts and privileged administration paths. The hardware key should be treated as the primary interactive authenticator for that path, not as an optional second factor that can be bypassed for convenience. That preserves the property that compromise of a server, session transcript or configuration file does not automatically reveal a reusable login secret for the next target.

Rollout decisions that make FIDO2 SSH work in practice

Set a PIN on the key, use a current OpenSSH release, and test the full login path before declaring the rollout complete. Those are not cosmetic details. The PIN is what turns the device into a user-verifiable authenticator, the software version determines whether the FIDO2 key type works cleanly, and an end-to-end test confirms that administrators can authenticate without falling back to passwords during an incident.

• Register at least one backup key for every operator who will need production SSH access.
• Document the lost-key process before the first rollout wave, including replacement and revocation.
• Verify that the public key is enrolled on the right hosts and that stale authorized_keys entries are removed.
• Prefer per-user access over shared administrative accounts so the hardware key actually improves attribution.

Teams should also SSH Key and SSH Certificate Management Guide because the SSH question is not only how to authenticate, but how to govern keys over time, including rotation, orphaned key removal and the role of certificates when static key sprawl becomes a problem.

Risk and Threat Considerations

SSH access is a high-value target because it often leads directly to root-equivalent administrative control. The biggest risk is not simply weak authentication, it is credential portability: once a reusable secret exists, it can be copied, replayed, phished or harvested from another system. Hardware keys reduce that portability, but they do not remove the need to manage loss, backup, revocation and host enrollment carefully.

Failure mechanism: Teams that keep password fallback paths, shared admin accounts or unmanaged backup keys create alternate entry points that defeat the protection model. A stolen workstation, exposed private key file or sloppy host enrollment can still undermine the intended physical-device binding.

Impact: An attacker who gets a valid SSH path can move quickly from initial access to configuration changes, data access, persistence and lateral movement across remote infrastructure. The operational damage is amplified when SSH is used for fleet administration, because one compromised admin path can affect many systems.

For teams that want to understand the surrounding threat pattern, Keyloggers Guide explains why hardware-backed authentication is valuable when attackers try to capture credentials in transit or via endpoint compromise, and Cloud Credential Compromise Playbook is useful for the incident-response logic that follows if a remote access secret or session has already been exposed.

Practitioner Guidance

What to verify: Confirm that SSH access is actually using FIDO2-backed credentials end to end, not a key file exported from a weaker workflow or a password fallback left in place for emergencies. If the operator can still authenticate after losing the device-specific property, the rollout is not complete.

Decision rule: If the system is production remote infrastructure, require per-user hardware keys with PIN unlock and a tested replacement path. If a team cannot revoke and reissue access cleanly when a key is lost, treat that as a rollout blocker, not an acceptable convenience trade-off.

Practitioner takeaway: The real benefit of FIDO2 for SSH is not “stronger login” in the abstract, but the removal of reusable secrets from the administrative path, which forces teams to get serious about device binding, recovery and key governance at the same time.

Related resources from NHI Mgmt Group

• How should security teams use hardware-based second factors to protect SSH access to distributed infrastructure?
• Why do SSH keys create hidden access risk in complex infrastructure?
• How should security teams use SSH access in a zero-trust remote access model?
• How should teams manage SSH keys securely when developers and administrators need frequent remote access?