TL;DR: Passwordless authentication is gaining momentum because FIDO-style passkeys and cryptographic credentials can reduce phishing risk, password resets, and user friction while improving sign-in success, according to Imprivata. The IAM question is no longer whether passwords are weak, but how to migrate identity controls without breaking workflow, assurance, or lifecycle governance.
At a glance
What this is: This is an Imprivata perspective on passwordless authentication and FIDO Alliance participation, with the key finding that passwordless can improve both security and user experience when identity controls are designed around workflow.
Why it matters: It matters because IAM teams must align human authentication, recovery, and lifecycle governance when replacing passwords with stronger factors and passkeys.
By the numbers:
- 77% of hacking incidents involve stolen credentials.
- most end users have an average of 100 online accounts.
- the average labor cost for just one password reset is $70.
- in 2025, the average cost of a data breach in the U.S. was $4.4 million.
👉 Read Imprivata's article on passwordless authentication and FIDO
Context
Passwordless authentication replaces shared secrets with stronger factors such as cryptographic keys, biometrics, and device-bound sign-in methods. In practice, the topic sits at the intersection of human IAM, recovery workflows, and access assurance, because the control shift only works when enrolment, verification, and fallback paths are handled cleanly.
The article argues that passwords create friction, reset burden, and phishing exposure, while passwordless methods can improve both security and usability. For IAM programmes, the real issue is not whether passwordless is attractive, but how to introduce it without creating new account recovery weaknesses, device dependency problems, or inconsistent policy enforcement.
Key questions
Q: How should organisations roll out passwordless authentication without breaking access recovery?
A: Start with high-assurance users and a narrow application set, then expand only after recovery, device binding, and step-up verification are documented. Passwordless fails when recovery is weaker than the sign-in method, because attackers target the fallback path. The rollout should be treated as an IAM change programme, not a login-page swap.
Q: Why do passwords still create so much identity risk in modern environments?
A: Passwords remain risky because they are reusable, easy to phish, and often tied to inconsistent user behaviour across many accounts. Once credentials are stolen, attackers can reuse them across services or pivot into reset flows. That is why reducing shared-secret dependence matters more than asking users to manage them better.
Q: What should security teams measure after introducing passwordless sign-in?
A: Track password reset volume, sign-in success, account recovery events, and help-desk load. If those numbers improve but recovery exceptions rise, the programme has only moved risk. Good passwordless governance shows lower friction and stronger assurance at the same time.
Q: How does passwordless differ from adding more MFA factors?
A: Passwordless replaces the password as the primary secret, while MFA usually adds a second factor on top of password-based login. That difference matters because passwordless removes the most phishable credential from the flow. Teams should use it where they need stronger assurance and less user friction, not as a cosmetic layer on top of weak authentication.
Technical breakdown
Passkeys and phishing-resistant authentication
Passwordless FIDO authentication uses public-key cryptography rather than shared secrets. A device stores a private key and the service stores the matching public key, so there is no password to steal or reuse in a phishing flow. Because the assertion is origin-bound, a fake login page cannot relay the credential the way it can with a password. The security gain comes from removing the reusable secret from the attack path, not from adding complexity to the login screen. For identity teams, this changes how trust is established at sign-in and reduces dependence on credential hygiene programs that are inherently fragile.
Practical implication: Prioritise phishing-resistant authentication for high-value user populations and apps that currently rely on password reuse.
Why passwordless changes IAM operations
Passwordless is not only an authentication pattern, it is an operating model. Teams must support enrolment, device binding, recovery, and fallback authentication across SSO, MFA, and application access. If the lifecycle design is weak, users can still be locked out, help desks still carry recovery load, and policy exceptions still accumulate. Passwordless succeeds when it is integrated into the identity layer rather than treated as a bolt-on convenience feature. That means sign-in assurance, recovery assurance, and access governance have to be designed together, especially in environments with mixed device states and mixed assurance requirements.
Practical implication: Map passwordless rollout to enrolment, recovery, and exception handling before expanding it across business-critical applications.
Password fatigue, resets, and authentication assurance
The article links passwordless to lower reset volume and better sign-in success, which is the operational side of identity assurance. Passwords generate repeated failure states: forgotten secrets, phishing capture, help-desk reset, and abandonment. Passwordless removes one large failure mode, but it also shifts control responsibility to device possession, biometric confidence, and recovery governance. That means IAM leaders should treat passwordless as a reduction in shared-secret risk, not a universal answer to identity trust. The architecture is stronger when policy, device posture, and user recovery are aligned under one governance model.
Practical implication: Measure whether passwordless reduces reset demand without increasing account recovery risk or policy exceptions.
Breaches seen in the wild
- Shai Hulud npm malware campaign — Shai Hulud campaign: npm malware exposed secrets on GitHub.
- Reviewdog GitHub Action supply chain attack — reviewdog/action-setup GitHub Action supply chain attack exposed secrets.
Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Passwordless is a human IAM control shift, not just an authentication upgrade. The article correctly frames passwords as a source of friction, reset cost, and phishing exposure, but the deeper change is in how identity assurance is established. Moving from shared secrets to passkeys changes the control surface for sign-in, recovery, and step-up verification. Practitioners should treat this as an authentication governance redesign, not a cosmetic login update.
Shared-secret dependence is the failure mode passwordless is designed to remove. Passwords create reusable credential material that can be phished, replayed, and abused across accounts. That is why passwordless aligns so naturally with phishing resistance and SSO patterns. The practitioner conclusion is simple: any programme that still depends heavily on memorised secrets is carrying avoidable authentication risk.
Credential reuse pressure: passwordless becomes compelling because the average user now manages an account estate that no human can secure well with memory alone. When end users juggle dozens of accounts, password hygiene breaks down into reuse, resets, and abandonment. The implication is that IAM architecture must reduce reliance on human memory and design for stronger, lower-friction verification instead.
Passwordless governance still depends on recovery design. Removing passwords does not remove identity recovery, exception handling, or fallback controls. If device binding, enrolment proofing, and account recovery are weak, attackers simply move to the recovery path. Practitioners should therefore evaluate passwordless programmes by the strength of their fallback governance, not by login convenience alone.
From our research:
- 77% of hacking incidents involve stolen credentials, according to LLMjacking: How Attackers Hijack AI Using Compromised NHIs.
- That same research shows attackers attempt access within 17 minutes of public AWS credential exposure, showing how little time shared secrets leave for manual response.
- For the broader identity picture, Ultimate Guide to NHIs , Key Challenges and Risks explains why credential sprawl and over-privilege keep creating avoidable exposure.
What this signals
Passwordless adoption should be read as an access assurance programme, not a user-experience project. When password resets and phishing incidents dominate support and incident queues, the organisation is signalling that shared-secret authentication has outlived its control value.
Credential fatigue boundary: the practical limit of password-based IAM appears when users can no longer manage account volume without reuse, resets, and abandonment. That is why the migration to phishing-resistant sign-in is now a governance issue, not just an authentication preference.
For practitioners, the next step is to connect passwordless policy with recovery proofing, device posture, and privileged access rules. The relevant benchmark is whether the organisation can reduce friction without weakening the fallback path or creating exception-driven access drift.
For practitioners
- Prioritise phishing-resistant sign-in for high-risk users Start with administrators, finance users, clinicians, and other high-value accounts where credential theft has outsized impact. Use passkeys or equivalent phishing-resistant methods where the application stack and device estate support them, and keep the rollout tied to assurance levels rather than broad convenience claims.
- Redesign recovery before removing passwords Document every fallback path, including help-desk resets, lost-device flows, and step-up verification after enrolment. If a user can recover access through weak proofing, the passwordless programme has simply moved the attack surface.
- Align passwordless with SSO and MFA policy Treat passwordless as part of the broader authentication stack so policy remains consistent across applications, session length, and step-up triggers. Preserve assurance requirements for privileged apps and avoid creating shadow exceptions for legacy systems.
- Track operational outcomes, not just adoption rates Measure password reset volume, sign-in success, help-desk load, and recovery exceptions after rollout. Those signals show whether passwordless is actually reducing friction without creating new identity risk.
Key takeaways
- Passwordless authentication reduces the attack surface created by reusable secrets, which is why it is gaining traction in modern IAM programmes.
- The operational proof point is not adoption alone, but fewer resets, stronger sign-in assurance, and lower reliance on weak recovery paths.
- Teams should treat passwordless as an identity governance change that must be aligned with recovery, SSO, MFA, and privileged access policy.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-63, NIST Zero Trust (SP 800-207) and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-63 | Passwordless and phishing-resistant authentication map directly to digital identity assurance. | |
| NIST Zero Trust (SP 800-207) | PR.AC-7 | Continuous verification and reduced reliance on shared secrets fit zero trust access decisions. |
| NIST CSF 2.0 | PR.AC-1 | Identity and credential management is central to replacing passwords with stronger factors. |
Use phishing-resistant authenticators for higher-risk users and align enrolment with assurance requirements.
Key terms
- Passwordless Authentication: An authentication approach that removes the password from the primary sign-in path and replaces it with stronger methods such as passkeys, biometrics, or device-bound credentials. In IAM practice, it improves phishing resistance, but only if enrolment, recovery, and fallback controls are governed as tightly as login itself.
- Passkey: A passkey is a cryptographic credential used for login without a password. The private key stays on the user’s device and the public key is stored by the service, which makes replay and phishing materially harder. In enterprise IAM, passkeys still require lifecycle controls for enrolment, device loss, and recovery.
- Phishing-Resistant Authentication: Authentication designed so a user cannot be tricked into handing over a reusable secret to an attacker. It depends on cryptographic proof rather than memorised credentials. For security teams, the value is not just stronger login, but a reduction in the credential theft path that attackers routinely exploit.
- Recovery Path: The fallback process used when a user cannot complete primary authentication, such as lost-device handling, help-desk verification, or step-up proofing. Recovery paths are often the weakest part of passwordless programmes because attackers target them after the main login secret is removed.
Deepen your knowledge
Passwordless authentication and recovery governance are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are planning a passwordless rollout in a mixed IAM environment, it is worth exploring.
This post draws on content published by Imprivata: passwordless authentication and the FIDO Alliance's role in reducing password reliance. Read the original.
Published by the NHIMG editorial team on 2026-04-03.
NHI Mgmt Group — the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org