FIDO2 client PIN trust breaks when the host is compromised

At a glance

What this is: NHI Mgmt Group's analysis, drawing on Crayonic's blog post: FIDO2 security keys can still be undermined by a compromised computer, because the Client PIN flow trusts the host for input and approval display.

Why it matters: This matters because IAM teams evaluating passkeys and security keys need to account for workstation trust, not just phishing resistance, especially in shared or hard-to-lock-down environments.

Context

FIDO2 is designed to move authentication secrets off the server and into a hardware authenticator, but the protocol still depends on the computer used for PIN entry and approval display. When that workstation is not trustworthy, the identity control inherits the workstation's weaknesses instead of eliminating them.

That creates a governance gap for workforce identity security and for shared-device environments where users assume hardware keys remove the need to trust the endpoint. The question is not whether the key is strong, but whether the host can be relied on to mediate the interaction safely.

Key questions

Q: How should teams reduce risk when a security key still relies on a workstation for PIN entry?

A: Reduce reliance on host-mediated PIN entry by moving verification and approval onto the authenticator wherever possible. If the workstation can be compromised, the control path for consent, transaction visibility, and PIN handling becomes part of the attack surface. The safest design is the one that keeps the secret and the confirmation step on hardware the host cannot intercept or rewrite.

Q: Why do compromised endpoints weaken FIDO2-style sign-in even when private keys stay in hardware?

A: Because the attacker does not need the private key to win. If the endpoint can intercept the PIN, relay the request, or alter what the user sees, it can redirect approval into an attacker-controlled session while leaving the key intact. The failure mode is trust in the host, not weakness in the authenticator's cryptography.

Q: What signs show that an authenticator binding process may be vulnerable to relayed registration?

A: Watch for registrations that originate from high-risk endpoints, unexpected device replacement, and inconsistent device provenance after enrollment. If your programme cannot distinguish a genuine device from a relayed or substituted one, then the binding process is relying on the workstation and network path too much. That is a governance signal, not just a technical anomaly.

Q: What is the difference between phishing-resistant MFA and removing host trust from authentication?

A: Phishing-resistant MFA can stop credential replay and website spoofing, but it still may depend on a workstation to handle input and approval. Removing host trust goes further by moving verification and confirmation to the authenticator itself. The first resists phishing; the second reduces what a compromised endpoint can manipulate during the sign-in flow.

Technical breakdown

Why the client PIN exchange is vulnerable

In the Client PIN flow, the user types a PIN on the computer and the host forwards it to the authenticator over USB, NFC, or Bluetooth. The two sides derive a shared key with ECDH, but that exchange is unauthenticated, so a malicious host can sit in the middle and replace the keys on both sides. The result is not private-key theft, but control over PIN decryption, PinToken capture, and the session state the user believes is protected. This is a protocol trust problem, not a cryptographic break. See the Passwordless and Passkeys Guide.

Practical implication: Treat any host-mediated PIN flow as part of the trust boundary, not a neutral transport layer.

How authenticator rebinding and parallel session abuse work

A compromised client can exploit two different weaknesses. In authenticator rebinding, malware relays registration to an attacker's device of the same model, causing the relying party to trust the wrong authenticator. In a parallel session attack, the malware forwards an attacker's login request to the victim's key, so the user approves a session they did not initiate. Both attacks succeed because the authenticator cannot see the real context and the user cannot verify it on the host. See the Hardware Security Keys Guide.

Practical implication: Design approval flows so the authenticator itself can verify the transaction context, not just the host.

Why on-device input and output change the trust model

Moving verification onto the authenticator changes the security boundary. If the device itself handles biometric input and displays the transaction details, the PIN never traverses the workstation and the user can confirm what is being signed on hardware the attacker does not control. That closes the blind spot created by host-mediated input and output. In practice, this is an identity assurance design choice, not a cosmetic feature: the more the host participates, the larger the attack surface becomes.

Practical implication: Prefer authenticators that handle verification and transaction confirmation locally when the workstation cannot be fully trusted.

Threat narrative

Attacker objective: The attacker wants to hijack trusted authentication flows without stealing the private key itself, so the relying party accepts the attacker-controlled session or device.

1. Entry begins when malware or a malicious client gains a position between the workstation and the authenticator during a normal sign-in or registration flow.
2. Credential access occurs when the attacker intercepts the PIN, relays an approval, or captures the PinToken needed for the session.
3. Escalation follows when the attacker rebinding the authenticator or steering a parallel session causes the relying party to trust the attacker-controlled device or login path.
4. Impact is unauthorized access under a legitimate authentication framework, with the user having unknowingly approved the wrong session or device.

Breaches seen in the wild

• Salesloft OAuth token breach: hackers stole OAuth tokens to access Salesforce data via Salesloft.
• Klue OAuth Supply Chain Breach: OAuth tokens compromised in Klue integration breach affecting 700+ organisations via Salesforce data access chain.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Host trust is the real weak point in Client PIN flows: the protocol assumes the workstation can safely collect secrets and present approval context, but that assumption fails as soon as the host is compromised. The cryptography can remain intact while the approval path is redirected. For identity programmes, the lesson is that phishing resistance is not the same as host trust elimination.

Authenticator rebinding is a governance failure, not just a protocol edge case: if the relying party cannot distinguish the genuine device from a relayed registration, the programme has no reliable binding between identity proofing and authenticator provenance. That gap is exactly where device trust models collapse. Practitioners should treat device binding as a lifecycle control, not a one-time enrollment event.

Parallel session attacks expose an assumption collapse in user consent: the workflow presumes the user can see what they are approving and can reject a malicious request in time, but the host can obscure that context. That means consent is being validated on an untrusted interface. The implication is that approval semantics must move onto hardware the attacker cannot mediate.

Passkeys and FIDO2 are strongest when the authenticator owns both verification and confirmation: the article points toward a named design principle we can call host-trust minimisation. When the workstation is removed from the secret and approval path, the security value of the authenticator becomes easier to defend in shared and high-risk environments. The practical conclusion is to favour local verification over host-mediated trust wherever assurance matters most.

From our research library:

• 92% of organisations expose NHIs to third parties, raising concerns about supply chain security, according to the Ultimate Guide to NHIs.
• Read next: Passwordless and Passkeys Guide

What this signals

Host-trust minimisation: FIDO2 deployments that still depend on the workstation for PIN entry and approval preserve a gap that adversaries can exploit even when the private key never leaves the authenticator. Identity teams should treat the host as part of the authentication system unless the device itself owns verification and confirmation.

Shared-device environments intensify that gap because the attacker does not need to defeat the authenticator, only the interface between user intent and device approval. For programmes that manage clinicians, operators, or other pooled users, the next design question is whether the authenticator can replace the workstation as the trusted interaction point.

For practitioners

• Map the workstation to the trust boundary Document where the host participates in PIN entry, approval display, and device binding so you can see which parts of the flow remain exposed if the endpoint is compromised. See the Workforce Identity Security Guide.
• Prefer local verification on the authenticator Where the environment is shared or high risk, choose devices that verify the user on the token itself rather than routing a PIN through the computer.
• Require visible transaction context on hardware Use authenticators with an onboard display or equivalent trusted output so the user can confirm the actual request outside the control of the workstation.
• Review enrollment and re-binding assumptions Check whether your enrollment process can detect a relayed registration or an attacker-controlled device of the same model before it becomes trusted.
• Reassess shared-device sign-in patterns Prioritise environments such as wards, deskside kiosks, and other pooled endpoints where the host is hardest to secure and the approval path is easiest to tamper with.

Key takeaways

• The article's central warning is that FIDO2 can remain vulnerable when the computer mediating the session is not trustworthy.
• The weakness is not private-key compromise but the ability to intercept PINs, relays, and approval context through the host.
• Authentication design should shift as much verification and transaction confirmation as possible onto the authenticator itself.

Related NHI Mgmt Group resources: Passwordless and Passkeys Guide · Workforce Identity Security Guide · Hardware Security Keys Guide · MFA Guide

Key terms

• Account PIN: An account PIN is a numeric authentication factor used to verify a user before access is granted or account changes are allowed. If exposed in a breach, it can enable fraud, impersonation, or account takeover, especially when combined with other personal data. Its security value depends on secrecy and how tightly it is validated.
• Authenticator Binding: The process of linking a specific device, token, or biometric factor to a specific identity record. This binding is what allows the system to trust the factor at login, and it becomes a governance point when devices are replaced, lost, or stolen. Weak binding creates replay and recovery risk.
• Parallel session attack: A login attack where a user approves an authentication request that was actually initiated by someone else. The user sees a legitimate prompt on a compromised host, but the resulting signature or approval is attached to the attacker’s session rather than the intended one.
• Host-trust minimisation: A design principle that removes the workstation from secret handling and approval display wherever possible. In FIDO2 deployments, it means the authenticator itself verifies the user and shows the transaction context so the host cannot silently alter the authentication step.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.