Independent analysis by NHI Mgmt GroupSource article: Teleport, “Passkeys for Infrastructure” (January 12, 2023)

TL;DR: Teleport reports that passkeys for infrastructure use WebAuthn, device-bound keys and proximity proof to make phishing harder, but synced passwordless access across devices can widen identity sprawl and exception handling overhead. The control problem shifts from password reuse to governance of where passwordless access is registered, stored and allowed to operate.


At a glance

What this is: NHI Mgmt Group's analysis, drawing on Teleport's blog post: Passkeys for infrastructure access reduce phishing exposure while creating new governance pressure around device sync, enrollment scope and exception management.

Why it matters: IAM teams, PAM teams and identity architects need to treat passwordless access as a governance change, not just an authentication upgrade, because the control boundary moves from password handling to device and lifecycle oversight.

👉 Read Teleport's analysis of passkeys for infrastructure access


Context

Passkeys are a passwordless authentication method for infrastructure access that use WebAuthn, a device-bound private key and local user verification instead of a reusable password. In this article, the core security gain is reduced phishing exposure, but the governance challenge shifts to managing where those credentials live, which devices can use them, and how exceptions are controlled.

For identity programmes, that matters because passwordless does not remove lifecycle work. It changes it. Once a passkey can be synced across devices or backed by cloud storage, teams must govern enrolment, recovery, second factors and device trust with the same discipline they once applied to passwords and OTP workflows.


Key questions

Q: How should security teams adopt passkeys for infrastructure access?

A: Start with the highest-risk interactive accounts, especially administrators who are exposed to phishing and push fatigue. Then tie enrolment to device trust, define recovery requirements, and keep terminal and break-glass workflows under separate policy. Passkeys improve authentication strength, but they only reduce risk when the surrounding identity process is controlled end to end.

Q: Why do passkeys still need identity governance if they are phishing-resistant?

A: Because phishing resistance solves one failure mode, not the whole identity problem. Teams still need to govern enrolment, device binding, fallback access, account recovery, and assurance changes over time. Without those controls, passkeys can create a stronger authenticator that is still attached through a weak process.

Q: What breaks when passkeys are used without endpoint governance?

A: Passkeys can still authenticate the wrong endpoint if organisations do not control device provenance. The cryptography remains strong, but the governance model weakens because login approval may occur on unmanaged or compromised devices. That creates assurance gaps in recovery, revocation, and auditability, especially where users can synchronise credentials across multiple endpoints.

Q: What is the difference between passkeys and traditional MFA for infrastructure?

A: Traditional MFA usually adds a second step to a password flow, while passkeys replace the password with cryptographic authentication bound to the device and user verification. That makes passkeys more resistant to phishing, but it also shifts control effort toward device enrollment, sync policy and recovery management.


Technical breakdown

How passkeys reduce phishing risk for infrastructure

Passkeys rely on public key cryptography through WebAuthn, with the private key staying on the device or in a secure enclave. The login flow also includes origin binding, so the credential only works with the legitimate site or application, which breaks the usual credential-harvesting model used in phishing. For infrastructure access, that means a stolen password or intercepted OTP no longer provides the attacker with a reusable secret. The article also notes proximity proof and local user verification, which combine device presence and biometric or local approval into a stronger authentication event than passwords alone.

Practical implication: treat passkeys as a phishing-resistant authentication method, not as a replacement for access governance.

Why synced passkeys create identity sprawl

The governance issue is that passkeys are often synced across multiple devices through a cloud-backed wallet such as iCloud Keychain or Google Password Manager. That makes access easier to use, but it also expands the set of endpoints that can authenticate as the same identity. In practice, the identity is no longer tied to one carefully enrolled workstation. It can exist across phones, laptops and browsers, which complicates inventory, recovery and offboarding. For infrastructure teams, that is a lifecycle problem as much as an authentication problem.

Practical implication: enrolment, recovery and device coverage must be tracked as part of identity lifecycle governance.

Why passkeys reduce 2FA dependence but not administrative exceptions

Passkeys collapse several verification factors into a single flow, combining possession, presence and user verification. That reduces reliance on separate OTP apps and removes one common failure mode in MFA fatigue attacks. But the article also shows that not every environment is uniformly passkey-ready. Terminal access, browser support gaps and device-specific constraints still require alternative methods such as security keys or passwordless fallback paths. Those exceptions become the real governance surface. The risk is not the passkey itself, but unmanaged variation in how different access paths are approved and maintained.

Practical implication: define approved fallback methods before passkeys spread across infrastructure workflows.


Threat narrative

Attacker objective: The attacker wants to obtain authenticated access to infrastructure accounts by exploiting weaker login methods before passkeys are fully deployed.

  1. Entry begins with phishing or MFA fatigue attempts against traditional login flows, where attackers exploit reusable credentials or approval prompts to gain a foothold.
  2. Credential abuse follows when the victim accepts a push request or otherwise satisfies a weaker second factor, giving the attacker authenticated access to the account.
  3. Impact comes from access to infrastructure systems without needing to defeat the passkey protections themselves, which is why phishing-resistant authentication matters.
  • Twilio 0ktapus breach 2022: SMS phishing of employees exposed 209 Twilio customers and 1,900 Signal users, part of the 0ktapus campaign against 130+ firms.

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


NHI Mgmt Group analysis

Passkeys solve the phishing problem, but they do not solve identity lifecycle governance. The article shows a stronger authentication factor, yet the underlying administrative burden does not disappear. Once access is tied to synced devices and multiple enrollment paths, the programme still has to govern who can register, recover and retire those credentials. The practitioner conclusion is that authentication hardening and lifecycle control must be designed together.

Device sync turns passkeys into a governance object, not just an authentication method. When the same passkey can be available across mobile and desktop environments, the access boundary becomes wider than the original enrollment event. That widens the review surface for IAM and PAM teams because the identity is now distributed across approved devices rather than anchored to a single endpoint. The implication is that inventory and offboarding matter as much as cryptographic strength.

Phishing resistance shifts the control problem from challenge-response weakness to exception management. Traditional MFA failures often come from user fatigue, but passkey deployments still require fallback paths for terminals, unsupported browsers and platform gaps. Those exceptions are where governance erodes if they are left informal. The practitioner lesson is that the most dangerous access path is often the one kept outside the primary policy because it is considered temporary.

Passkey adoption exposes a new kind of sprawl: passwordless sprawl. The article is useful because it shows that reducing passwords does not automatically reduce the number of identities, devices or approval paths that can authenticate a user. That is the named concept worth tracking: passwordless sprawl. The conclusion for IAM programmes is that passwordless adoption must be measured by governance scope, not by the number of passwords removed.

NHI and human identity governance are converging at the authentication edge. Infrastructure access increasingly depends on device-bound credentials, synced wallets and local verification, which makes the control surface look like both human IAM and NHI governance. The practical conclusion is that teams cannot treat passkeys as a purely human login feature when the same control model shapes service access, recovery design and privileged access workflows.

From our research library:

What this signals

Passwordless sprawl is the governance risk hidden inside passkey adoption. Removing passwords can improve security, but the programme still has to govern where credentials are stored, which devices can use them and how emergency access is approved. For IAM teams, the control boundary moves from secret handling to identity lifecycle discipline.

Infrastructure teams should expect passkeys to reduce phishing exposure without reducing policy complexity. The practical test is whether enrollment, recovery and fallback paths are documented tightly enough that passwordless access remains auditable across every device and workflow.


For practitioners

  • Define approved passkey enrollment paths Restrict passkey enrollment to managed devices and documented recovery workflows so that synced credentials do not bypass existing access approval processes.
  • Map every fallback login method Inventory terminals, unsupported browsers and emergency access paths, then decide which security key or passwordless fallback is permitted for each case.
  • Track device scope for each identity Record which phones, laptops and browsers can authenticate with the same passkey so offboarding removes every active trust point, not just the primary device.
  • Review MFA exception handling Set a clear policy for push, call and OTP exceptions so weaker factors do not become the default back door when passkeys are unavailable.

Key takeaways

  • Passkeys make infrastructure logins more resistant to phishing, but they do not remove the need for identity governance.
  • The hard part shifts to enrollment scope, device sync, recovery and exception handling across terminals and unsupported browsers.
  • IAM and PAM teams should treat passwordless access as a lifecycle problem, not just an authentication upgrade.

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 addresses the attack and risk surface, while NIST SP 800-63 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.

FrameworkControl / ReferenceRelevance
OWASP Non-Human Identity Top 10NHI-04 — Insecure AuthenticationPasskeys replace weaker authentication paths with phishing-resistant device-bound verification.
NHI-08 — Environment IsolationSynced passkeys across devices widen the authentication environment and complicate trust boundaries.
NHI-10 — Human Use of NHIThe article centers on human-operated infrastructure access through non-human credential mechanisms.
Recommendation — Adopt NHI-04 to replace reusable login secrets with phishing-resistant authentication for infrastructure access. Use NHI-08 to separate approved devices, recovery paths and fallback authentication methods by environment. Apply NHI-10 to govern how people use passkeys and other NHI credentials for privileged access.
NIST SP 800-63SP 800-63B — AuthenticationPasskeys are an authentication method governed by digital identity assurance and verifier requirements.
Recommendation — Align passkey deployment with SP 800-63B authentication requirements for phishing-resistant sign-in.
NIST CSF 2.0PR.AA-05 — Access Permissions, Entitlements and AuthorizationsPasskey rollout changes who can authenticate and on which devices, which is an authorization governance issue.
Recommendation — Apply PR.AA-05 to document and control the entitlements attached to passkey-enabled access.

Key terms

  • Passkey: A passkey is a passwordless credential based on public key cryptography. A private key stays on the user’s device, while a public key is stored by the service. During login, the device signs a challenge after local unlock, which reduces phishing and eliminates shared secret reuse.
  • WebAuthn: WebAuthn is a browser and platform standard for phishing-resistant authentication using public-key cryptography. It binds the authenticator to the origin and signs a challenge instead of sending a reusable code, which makes replay and relay attacks far harder.
  • Passwordless Authentication: An authentication approach that removes passwords and uses a device-bound cryptographic key plus local user verification. It reduces phishing and replay risk, but it only improves assurance when enrollment, recovery, and revocation are tightly governed.
  • Proximity Proof: Proximity proof is the assurance that the authenticating device is physically near the requesting device, often established through Bluetooth or a similar local signal. It is useful because it blocks remote phishing flows, but it also introduces a device-pairing dependency that must be governed like any other access boundary.

What's in the full article

Teleport's full blog post covers the implementation detail this post intentionally leaves for the source:

  • Step-by-step passkey enrollment guidance for Teleport environments
  • Platform-specific notes on iOS 16, Ventura, Windows 11 and browser support
  • Terminal access limitations and when a USB security key is still recommended
  • Practical setup steps for enabling WebAuthn and adding a second factor device

👉 Teleport's full post covers passkey setup, platform support and login-path limitations.

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.
NHIMG Editorial Note
Published by the NHIMG editorial team on June 1, 2026.
Updated on October 7, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org