Passkeys and passwordless authentication: what IAM teams need

At a glance

What this is: This is a practitioner-focused explanation of passkeys as FIDO passwordless authentication and the security model they replace.

Why it matters: It matters because passwordless does not remove identity governance work, it shifts it into enrollment, device trust, recovery, and lifecycle control across human and non-human identity programmes.

👉 Read 1Kosmos's explanation of passkeys and passwordless authentication

Context

Passkeys are a passwordless authentication method built on FIDO standards, where a private key stays bound to the user’s device instead of being reused as a shared secret. That changes the risk model for IAM teams because the control problem moves away from password theft and toward enrollment integrity, account recovery, and device-bound trust.

For practitioners, the important question is not whether passkeys are secure in isolation. It is whether your authentication, lifecycle, and recovery processes can support passwordless access without creating new bypass paths, especially in enterprise environments that still depend on legacy account recovery and multi-service access patterns.

Key questions

Q: How should security teams implement passkeys without weakening recovery controls?

A: Security teams should implement passkeys with the same discipline they apply to other high-assurance authenticators. That means verified enrollment, device binding, controlled recovery, and removal of weak fallback methods. The goal is not just replacing passwords. It is ensuring that account recovery does not become the easiest way to bypass stronger authentication.

Q: Why do passkeys improve security but still require IAM governance?

A: Passkeys improve security by reducing phishing and secret theft, but IAM governance is still required because identity risk moves to enrollment, device trust, and recovery. If those processes are weak, the organisation can still suffer account takeover through the path around the passkey rather than through the passkey itself.

Q: What breaks when passkeys are added without changing fallback authentication?

A: What breaks is the assurance model. A strong passwordless login can be undermined by SMS resets, email-based recovery, or help desk exceptions that have lower assurance than the passkey. If those paths remain open, attackers will target the weakest recovery method instead of the primary authenticator.

Q: How do organisations know whether passkey adoption is actually working?

A: Organisations should measure whether passkeys are reducing password dependence, lowering phishing exposure, and shrinking the share of accounts that rely on weak recovery methods. Adoption is working only if the new authenticator improves real security outcomes and does not leave old bypass paths in place.

Technical breakdown

How passkeys replace password-based authentication

Passkeys use public key cryptography. The device stores a private key locally, while the service stores the matching public key and verifies a signed challenge during login. Because the private key never leaves the device, passkeys reduce exposure to credential stuffing, phishing, and server-side password theft. The practical shift is that authentication assurance now depends on device possession plus local unlock or biometric verification, not on a memorised secret. That makes the authentication flow stronger, but it also changes how identity teams design enrollment, recovery, and fallback paths.

Practical implication: review whether your current authentication architecture still assumes password-centric controls and recovery flows.

Why passkeys change the security boundary for IAM teams

A passkey is not just a nicer login experience. It changes where trust lives. In a password model, the main risk is secret compromise across centralised systems and users. In a passkey model, the trust boundary shifts to the enrolled device, the authenticator binding, and the policy that governs when a credential may be created, reused, or recovered. That means IAM teams need to think about device assurance, enrollment fraud, help desk recovery, and the handling of multiple authenticators for one account.

Practical implication: align passkey rollout with device trust and recovery policy, not only with user experience goals.

Passkeys in consumer and enterprise authentication

Passkeys can support both consumer identity and enterprise authentication, but the operational requirements are different. Consumer deployments must handle broad device diversity and self-service recovery. Enterprise deployments usually need tighter policy control, stronger assurance at enrollment, and clearer governance over who can register new authenticators. In both cases, the goal is to reduce dependence on shared secrets while preserving account continuity. The architectural risk is assuming that password removal automatically solves identity risk. It does not, because account takeover can still occur through weak recovery or poor enrollment controls.

Practical implication: treat passkey rollout as an identity programme change, not a front-end login swap.

NHI Mgmt Group analysis

Passkeys improve authentication security, but they do not remove identity governance risk. The private key model reduces phishing and secret replay, yet the operational burden shifts to enrollment, device assurance, and recovery. That means the security question becomes whether the organisation can govern the lifecycle of authenticators as carefully as it once governed passwords. Practitioners should treat passkeys as a control improvement, not a governance endpoint.

Passwordless authentication changes the failure mode, not the need for access control. A shared password can be stolen, but a passkey can still be mis-enrolled, recovered through weak support processes, or attached to an untrusted device. The programme impact is that IAM, help desk, and endpoint governance now intersect more tightly. Practitioners need a single view of authentication policy across identity proofing, enrollment, and account recovery.

Passkey adoption exposes the gap between modern authentication and legacy recovery processes. Many environments modernise the sign-in step while leaving fallback authentication, account reset, and identity proofing unchanged. That creates a new weak point because attackers often target the exception path rather than the primary login path. Practitioners should assume the weakest recovery path will define real-world assurance.

Passkeys are most useful when they are governed as part of a broader identity architecture. The value is not just stronger login security, but a cleaner path toward phishing-resistant authentication across user populations. However, the benefit only holds if teams align enrolment policy, endpoint trust, privileged access handling, and lifecycle review. Practitioners should use passkeys to simplify credentials, not to simplify governance thinking.

From our research:

• Only 44% of developers are reported to follow security best practices for secrets management, according to The State of Secrets in AppSec.
• The average estimated time to remediate a leaked secret is 27 days, according to The State of Secrets in AppSec.
• For a broader view of credential exposure and breach patterns, see The 52 NHI breaches Report.

What this signals

Passkey adoption will expose how much of your identity programme still depends on exception handling. The technology is sound, but the programme impact sits in enrollment, support, and fallback controls. Teams that modernise sign-in without reworking recovery will preserve the same risk, just under a different authentication method.

Device-bound credentials create a narrower but more governable trust surface. That is useful for IAM teams, but only if device assurance, endpoint policy, and authenticator lifecycle controls are aligned. Organisations should expect passkeys to simplify credential management while increasing the need for policy consistency across identity, device, and help desk processes.

Passwordless maturity is now a governance question, not just an authentication question. The organisations that succeed will be the ones that treat passkeys as part of a broader lifecycle model, where registration, revocation, recovery, and review are all controlled and observable.

For practitioners

• Define passkey enrollment policy Require a consistent enrollment standard that ties passkey registration to verified identity proofing, approved device state, and controlled authenticator binding.
• Harden recovery and reset paths Review help desk and self-service recovery flows so account reset cannot become a weaker bypass than the passkey itself, especially for high-value users.
• Map passkeys into IAM lifecycle controls Treat passkey issuance, replacement, and revocation as lifecycle events that belong in access review, offboarding, and privilege governance processes.
• Separate consumer and enterprise governance Apply lighter self-service expectations to consumer identity, but enforce stronger registration, device trust, and admin approval rules for enterprise accounts.
• Audit fallback authentication Inventory every fallback method, including SMS, email reset, and support-assisted recovery, then rank them by the assurance they actually provide.

Key takeaways

• Passkeys improve phishing resistance by replacing shared passwords with device-bound cryptographic credentials.
• The main operational risk shifts to enrollment, recovery, and fallback authentication, where assurance can quietly collapse.
• IAM teams should govern passkeys as part of lifecycle and device-trust controls, not as a standalone login upgrade.

Key terms

• Passkey: A passkey is a passwordless credential based on public key cryptography. The private key remains on the user’s device and the service verifies a signed challenge, which makes phishing and server-side password theft much harder than with shared secrets.
• Phishing-resistant authentication: Phishing-resistant authentication uses methods that cannot be easily replayed, copied, or tricked into revealing a reusable secret. In practice, it depends on cryptographic proof tied to the legitimate authenticator rather than on a password or one-time code.
• Authenticator recovery: Authenticator recovery is the process used to restore access when a primary login method is lost or unavailable. It is often the weakest part of a modern identity stack because attackers target support workflows, reset paths, and backup channels that have lower assurance than primary authentication.
• Device-bound credential: A device-bound credential is an authenticator that remains tied to a specific device or secure hardware environment. This limits portability, which improves security, but it also makes device assurance and lifecycle control more important for administrators.

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 responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.

This post draws on content published by 1Kosmos: passkeys and passwordless authentication. Read the original.