Passkeys for infrastructure reduce phishing risk, but not NHI sprawl

At a glance

What this is: This is a technical blog post arguing that passkeys make infrastructure login more resistant to phishing by replacing passwords with device-backed, passwordless authentication.

Why it matters: It matters because IAM teams must decide where passkeys fit in access policy, especially for infrastructure admins, shared workflows, and other high-risk NHI-adjacent access paths.

By the numbers:

• Only 13% of organisations feel extremely prepared for the reality of agentic AI despite the majority racing toward autonomous adoption.
• Passkeys are supported with Teleport 10 and 11, while passwordless access is still available in the terminal for tsh.

👉 Read Teleport's analysis of passkeys for infrastructure access

Context

Passkeys replace reusable passwords with a cryptographic credential tied to a device and a user verification step. In infrastructure environments, that changes the IAM problem from password reuse and phishing resistance to lifecycle control, device trust, and recovery paths for privileged access and NHI-adjacent accounts.

Teleport's post frames passkeys as a way to reduce reliance on OTPs and push-based MFA, which is consistent with where enterprise identity is heading. The harder question for practitioners is how passwordless access behaves when the same access model has to cover human admins, shared operational accounts, and the broader NHI control plane.

The starting position here is typical of modern identity programs: security teams want stronger authentication, but the operational boundary between human access and non-human access is becoming less stable. That is exactly where governance gaps tend to appear.

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: What is the difference between passkeys and passwordless MFA?

A: Passkeys use public key cryptography and local user verification, while many passwordless MFA schemes still rely on a shared secret, a push approval, or an OTP. That means passkeys are generally more resistant to phishing and replay. For practitioners, the important question is whether the workflow remains secure once recovery and exception paths are included.

Q: Why do passkeys matter for privileged access?

A: Privileged access is a high-value target because a single stolen credential can expose broad infrastructure. Passkeys reduce the chance that an attacker can reuse a captured secret or trick an operator into approving access remotely. They are most effective when paired with least privilege, short session durations, and strong recovery controls.

Q: When do passkeys create less risk reduction than teams expect?

A: They create less value when the fallback path is weak, when unmanaged devices can enrol, or when the same authenticator is allowed to cover every account type. In those cases, the authentication surface shrinks at login but expands in recovery and exception handling. Teams should evaluate the entire identity journey, not just the sign-in screen.

Technical breakdown

How passkeys change infrastructure authentication

Passkeys use WebAuthn and FIDO2 to replace memorised secrets with asymmetric cryptography. The private key stays on the authenticator, usually a secure enclave on a phone or hardware token, while the server stores only a public key. Authentication succeeds when the client proves possession of the private key and the user verifies locally with biometrics or a device PIN. Because the browser and the service both verify the origin, passkeys also reduce phishing replay risk. For infrastructure, the important architectural shift is that authentication becomes device bound rather than password bound, which strengthens the first factor but raises new questions about enrolment, recovery, and device loss.

Practical implication: Practitioners should treat passkey enrolment and recovery as part of IAM policy, not as a UI choice.

Why proximity proof matters for phishing resistance

A passkey flow often includes proximity proof, typically using a local Bluetooth signal during QR-based login from a second device. That matters because a remote attacker cannot complete the ceremony without being physically near the authenticator and satisfying the local user verification step. This does not make identity unbreakable, but it narrows the attack path that enables conventional phishing and token replay. In infrastructure, that distinction is valuable because operators often work across browsers, operating systems, and device types. The more the login ceremony depends on a nearby trusted device, the less useful stolen credentials become to a remote adversary.

Practical implication: Use proximity-based sign-in for high-risk admin access, but still require strong device governance and recovery controls.

Passkeys versus legacy MFA and passwordless

Passkeys are not the same as OTP-based MFA or older passwordless deployments. OTP apps still depend on a shared secret and can be phished, while push MFA can fail through fatigue or approval bombing. Older passwordless methods often worked only on the enrolled device, which made cross-platform access awkward. Passkeys improve portability because they can sync through consumer identity ecosystems while still retaining public key authentication. That portability is operationally useful, but it also means the enterprise must understand where keys are stored, how they are backed up, and how exceptions are handled for terminals and non-browser workflows.

Practical implication: Map which infrastructure workflows can use passkeys today and which still require hardware-backed fallback methods.

Breaches seen in the wild

• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.
• MongoBleed breach — MongoBleed exposed secrets across 87K MongoDB servers.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Passkeys solve phishing, not identity governance. They materially reduce credential replay and push fatigue risk, but they do not answer who should have access, for how long, or under what conditions. That means passkeys should be treated as an authentication control inside a broader NHI governance model, not as a replacement for it. Practitioners should pair them with policy, review, and privileged access boundaries.

Infrastructure authentication is converging with NHI control problems. The same operational patterns that make passkeys attractive for human admins, such as portability and device binding, also appear in service accounts and automated workflows. Once access is cross-device and cross-platform, governance needs to distinguish human convenience from machine trust. Teams should design for lifecycle control before broad rollout.

Ephemeral authentication only works when recovery is equally disciplined. A passwordless model can reduce standing secret exposure, but weak fallback paths recreate the same risk in a different form. Recovery channels, alternate authenticators, and help desk overrides become the real attack surface if they are not held to the same standard. Practitioners should audit recovery as rigorously as primary sign-in.

Passkey adoption will expose identity debt in terminal and exception workflows. Browser login is easy to modernise, but infrastructure rarely lives only in browsers. CLI access, break-glass paths, and legacy operating-system constraints often force partial exceptions that accumulate over time. Teams should expect those exceptions to become the place where policy drift shows up first.

Passkeys are a useful control, but they are not a governance program. The discipline still needs strong access reviews, device trust policy, and separation between administrative, operational, and automated identities. Passkeys improve the front door, but they do not remove the need to control the rooms behind it.

From our research:

• Only 13% of organisations feel extremely prepared for the reality of agentic AI despite the majority racing toward autonomous adoption, according to The 2026 Infrastructure Identity Survey.
• 69% of security leaders agree identity management must fundamentally shift to address agentic AI systems, according to The 2026 Infrastructure Identity Survey.
• For the adjacent control plane, review The 2026 Infrastructure Identity Survey to see how AI access governance is reshaping identity decisions.

What this signals

Passkeys will become a baseline expectation for interactive access, but the governance burden shifts to recovery, enrolment, and exception handling. The authentication ceremony can be made stronger quickly, yet the surrounding identity process often remains loosely defined. Teams that focus only on the login flow will miss the places where policy drift and access abuse usually emerge.

Ephemeral credential design is only half the problem. When 70% of organisations already grant AI systems more access than they would give a human employee performing the exact same job, per The 2026 Infrastructure Identity Survey, it is clear that access policy, not just login strength, determines real risk. For infrastructure teams, that means passkeys should be evaluated alongside privilege boundaries, not in isolation.

For practitioners

• Classify passkey use by access tier Separate standard user sign-in, privileged admin access, and break-glass recovery into different policy paths so the same authenticator is not treated as a universal control.
• Audit fallback authentication paths Review SMS, push approval, and help desk recovery flows for every account that can use passkeys, then remove any route that would reintroduce phishable authentication.
• Map terminal and CLI exceptions Document which administrative workflows still rely on non-browser access, then define hardware-key or passwordless fallback rules for those cases before adoption expands.
• Bind enrolment to device trust policy Require managed-device posture, recovery ownership, and identity proofing before passkey enrolment so device loss does not become an access shortcut.

Key takeaways

• Passkeys improve phishing resistance for infrastructure access, but they do not eliminate the need for identity governance.
• The main practitioner risk shifts from password theft to enrolment, recovery, and exception handling.
• Teams should pair passkeys with least privilege, device trust, and explicit fallback controls before broad rollout.

Key terms

• Passkey: A passkey is a phishing-resistant credential that uses public key cryptography instead of a shared secret. The private key stays on the user’s device or authenticator, while the service verifies a signed challenge and the user locally confirms the login with biometrics or a PIN.
• WebAuthn: WebAuthn is the browser API that lets websites and applications use public key authenticators for login. It supports passwordless and multi-factor flows, and it is the technical layer that makes passkeys usable across web-based infrastructure access patterns.
• Phishing-resistant authentication: Phishing-resistant authentication is a sign-in method that cannot be easily replayed or captured by a fake login page. It relies on origin-bound cryptographic proof rather than a reusable password or one-time code, making it stronger against remote credential theft.
• Recovery path: A recovery path is the process used to regain access when the primary authenticator is lost, replaced, or unavailable. In identity governance, recovery is often where security weakens, so the controls around enrolment, proofing, and fallback access matter as much as the primary login method.

What's in the full article

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

• Step-by-step WebAuthn and passkey enrolment flow for Teleport users across supported devices
• Specific setup notes for iPhone, Android, Chrome, Safari, and Windows 11 environments
• Terminal and tsh limitations, including when passwordless still requires a USB security key
• Practical account settings for enabling a second factor and scanning the QR-based passkey flow

👉 Teleport's full post covers enrolment steps, browser support, and terminal limitations.

Deepen your knowledge

Passkeys for infrastructure and passwordless access controls are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are modernising authentication for admins, service workflows, or AI-adjacent access, it is worth exploring.