What is the difference between discoverable and non-discoverable FIDO2 credentials for SSH access?

Discoverable credentials are stored on the FIDO2 device itself, so authentication can still work if the device is available. Non-discoverable credentials require a separate private key for use, which creates a stronger loss boundary but less recovery flexibility. For SSH, the choice affects how teams balance usability, device loss, and control over key material.

Why Discoverability Changes the SSH Trust Boundary

For SSH, the difference is not cosmetic. A discoverable FIDO2 credential is tied to the token’s built-in resident storage, which means the authenticator can help identify and use the right credential without a separate private key file. A non-discoverable credential depends on an external private key path, so the operational model shifts toward explicit key custody, distribution, and recovery planning. That difference affects how teams handle device loss, onboarding, and the blast radius of a compromised workstation or misplaced token.

Discoverable credentials are often easier for users, but they also place more of the authentication state on the authenticator itself. Non-discoverable credentials preserve more deliberate control over where the key material lives, which can be useful when teams want tighter separation between the authenticator and the SSH client environment. The security trade-off is that convenience, recoverability, and custody do not line up the same way in both models.

In practice, teams often notice the difference only after they have already standardised an SSH rollout and then discover that recovery, inventory, and access revocation do not behave the way they expected.

How SSH Uses Discoverable and Non-Discoverable Credentials

SSH cares about how the credential is presented during login, not just about whether the authenticator is FIDO2-capable. With a discoverable credential, the device can store the credential handle locally and locate it during authentication, which reduces dependence on a separate on-disk private key. With a non-discoverable credential, SSH generally relies on an external key object and the credential is not meant to be found by the authenticator in the same way.

That difference changes the whole operating model. Discoverable credentials simplify user experience because the token can often serve as the primary source of truth for the login material. Non-discoverable credentials are more compatible with workflows that already treat SSH keys as managed artifacts, where administrators want explicit inventory, backup, rotation, and revocation processes around the key file. For teams comparing these modes, the real question is usually whether the identity should be recoverable from the device itself or governed through a separate key-management process.

Discoverable credentials are better when the goal is passwordless usability and simpler authentication flow.
Non-discoverable credentials are better when the goal is stricter custody and a clearer separation between the token and the key record.
Both still require lifecycle discipline, because the token choice does not remove the need to revoke access when a device, account, or operator changes.

The operational failure point is usually not the login step itself. It is the surrounding process: if teams do not know where the credential lives, who can reissue it, or how SSH access is restored after token loss, the authentication model becomes fragile. For a deeper NHI-oriented treatment of secret and credential patterns, NHIMG’s Ultimate Guide to NHIs — Static vs Dynamic Secrets is useful background, and the FIDO2 identity model is described in the OWASP Non-Human Identity Top 10. These controls tend to break down when organisations mix token-backed SSH with unmanaged key files, because the credential source and recovery path stop matching.

Common Edge Cases in SSH Rollouts

Tighter credential control often increases recovery friction, so teams have to balance user convenience against operational resilience. That trade-off becomes visible in multi-host estates, break-glass access, and environments where administrators expect to rebuild access quickly after a device failure.

One common edge case is assuming discoverable credentials are always safer because they are more modern. They can improve usability, but they also shift more reliance onto the authenticator’s internal storage and its recovery model. Another edge case is treating non-discoverable credentials as automatically more controlled. They can be better for explicit custody, but only if the external private key handling is disciplined; otherwise the surrounding file or secret management becomes the weaker link. Where SSH is part of a broader identity programme, the practical decision is usually whether the team wants the token to be the primary credential store or just one component in a managed key lifecycle.

The best practice is evolving, but current guidance suggests choosing discoverable credentials when user simplicity and device-contained access matter most, and non-discoverable credentials when you need stronger separation from the client system and a more traditional key governance model. NHIMG’s NHI Lifecycle Management Guide is a helpful reference when the decision needs to be tied to issuance, rotation, and revocation rather than to login convenience alone.

In environments with frequent device turnover, shared admin access, or weak offboarding discipline, both models can fail for the same reason: the organisation cannot confidently trace which credential is active, where it is stored, and how fast it can be removed.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

OWASP Non-Human Identity Top 10 address the attack and risk surface, while CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
OWASP Non-Human Identity Top 10	NHI Lifecycle — Credential Lifecycle Management	SSH FIDO2 credential discoverability directly affects machine credential storage and recovery.
Recommendation — Define issuance, storage, rotation, and revocation rules for SSH-backed non-human credentials.
CIS Controls v8	5 — Account Management	SSH credential choice changes how access is provisioned, revoked, and recovered.
	6 — Access Control Management	The question centers on how SSH access is controlled and separated by credential type.
Recommendation — Inventory SSH access paths and remove accounts or keys when access is no longer needed. Enforce least privilege and restrict SSH access to approved users and managed devices.
NIST CSF 2.0	PR.AA — Identity Management, Authentication, and Access Control	Discoverable versus non-discoverable credentials alters authentication and access governance.
	PR.DS — Data Security	Credential storage location determines exposure of key material and recovery artifacts.
Recommendation — Align SSH authentication with explicit identity proofing and access enforcement rules. Protect SSH credential material at rest and limit exposure on endpoints and tokens.

Practitioner Guidance

What to prioritise: Decide first whether SSH access should be recoverable through the authenticator or governed through a separate key-management process. That choice determines onboarding, loss handling, and the revocation path.

What to verify: Confirm where the credential material resides, how it is reissued, and what happens when a token is lost, replaced, or used on a new workstation. If those answers are unclear, the deployment is not ready for scale.

Decision rule: If the main failure concern is user friction and device portability, favour discoverable credentials; if the main concern is explicit custody and separation from the client system, favour non-discoverable credentials.

What practitioners underestimate: The hard part is not generating the SSH credential. The hard part is proving that offboarding, recovery, and emergency access still work when the original token or key path is no longer available.

Practitioner takeaway: The right choice is the one that matches your operational recovery model, because SSH credential design fails most often at the moment of loss, not during routine login.