They should treat passwordless as one control layer and add stronger identity verification around enrollment, recovery, and high-risk changes. That combination reduces credential theft without assuming the login method alone can prove identity. Organisations also need to harden help desk and delegation workflows, because attackers increasingly exploit the process around authentication rather than the password itself.
Why impersonation risk grows when passwordless rollout stalls
Passwordless reduces reliance on passwords, but it does not eliminate identity proofing problems. If adoption stalls, organisations often keep a mixed estate of passwords, passkeys, recovery paths, help desk resets, and delegated access, which creates more opportunities for social engineering and account takeover.
The core issue is that attackers usually do not need to break the strongest login factor if they can persuade a person, support desk, or delegated workflow to vouch for them. That is why passwordless by itself is not a complete impersonation control.
For the sign-in layer, stronger phishing-resistant authentication still matters. The practical benchmark is to use methods that bind authentication to the right device or authenticator and resist replay, not just to replace one user prompt with another. Passwordless and Passkeys Guide and NIST SP 800-63 Digital Identity Guidelines both support that direction.
Where organisations become most exposed: enrollment, recovery, and high-risk changes
The highest impersonation risk is usually not the daily login. It is the edge cases, new device enrollment, account recovery, MFA reset, profile changes, delegated access, and other actions that can silently transfer trust to an attacker. If those paths are weak, passwordless adoption delays leave the organisation dependent on brittle fallback processes.
Help desk workflows deserve the same scrutiny as primary authentication, because support staff are often asked to override normal proofing when users are locked out. That makes the recovery path a target for pretexting, SIM swap support, and impersonation through partial identity knowledge. Workforce Identity Security Guide is useful here because it covers help desk resets, account recovery, and the controls that reduce social-engineering success.
High-risk changes should also trigger step-up checks. If the request changes recovery channels, MFA enrollment, payment instructions, delegated authority, or admin privileges, the organisation should treat it as a trust transfer event, not a routine user service request.
How to reduce impersonation without waiting for full passwordless adoption
Organisations should separate sign-in assurance from change assurance. Passwordless may be the preferred login method, but the stronger control is to add explicit verification around recovery and sensitive changes, then limit who can approve exceptions. That means tightening help desk scripts, requiring stronger evidence for resets, and reducing the number of people or systems allowed to override policy.
Delegation also needs clear boundaries. Where a user can act on behalf of another person, the organisation should define when that delegation is valid, how it is revoked, and which actions require the original user to re-verify. The attack pattern is often abuse of legitimate delegation, not a broken cryptographic login.
RFC 8693: OAuth 2.0 Token Exchange is a useful reference for understanding controlled delegation and on-behalf-of flows, while Twilio 0ktapus breach 2022 shows how attackers commonly exploit authentication processes rather than the underlying password itself.
Risk and Threat Considerations
When passwordless stalls, the organisation can end up with a mixed authentication estate that is easier to exploit than either model on its own. Attackers focus on the weakest fallback path, especially recovery, support, and delegated approval workflows, because those controls often have lower assurance than the primary sign-in method.
Failure mechanism: An attacker impersonates a legitimate user through help desk pretexting, account recovery abuse, or delegated access misuse, then uses that trust transfer to enroll a new authenticator, reset credentials, or change recovery settings.
Impact: The result can be account takeover, persistence through newly enrolled recovery factors, and unauthorised access that survives even after the original password or session is revoked.
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 SP 800-53 Rev 5, OWASP ASVS and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-63 | Digital Identity Guidelines | Phishing-resistant auth and enrollment assurance are central to impersonation-resistant identity proofing. |
| Recommendation — Use phishing-resistant authenticators and stronger enrollment assurance for recovery and high-risk changes. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Stalled passwordless rollouts still depend on credential lifecycle and fallback authenticator control. |
| IA-2 — Identification and Authentication (Organizational Users) | The question concerns user identity assurance and impersonation risk for workforce access. | |
| AC-2 — Account Management | Help desk resets, delegation, and recovery are account lifecycle events that create impersonation exposure. | |
| Recommendation — Manage fallback authenticators tightly and rotate or revoke them promptly when trust changes. Require stronger authentication for workforce access paths that can be abused for impersonation. Restrict and audit account recovery, reset, and delegation actions that change identity trust. | ||
| OWASP ASVS | V6 — Authentication | Passwordless adoption and recovery security map directly to authentication assurance requirements. |
| Recommendation — Verify phishing-resistant authentication and recovery controls rather than relying on password replacement alone. | ||
| CIS Controls v8 | CIS-5 — Account Management | The subject centers on controlling account recovery and delegation pathways that attackers exploit. |
| Recommendation — Harden account lifecycle processes and remove unnecessary recovery and override paths. | ||
Practitioner Guidance
What to prioritise: Put your strongest verification on the actions that create future access, not just on everyday sign-in. Enrollment, recovery, MFA reset, and high-risk profile changes should require more assurance than low-risk user activity.
What to verify: Test whether help desk staff can be persuaded to bypass policy with partial identity data, and whether delegated actors can make changes that outlive the approval that granted them. If yes, the problem is process assurance, not only authentication strength.
Decision rule: If a request can alter a recovery method, an authenticator, or an admin path, treat it as an impersonation event until proven otherwise. If it only unlocks access without changing trust, the control bar can be lower.
Practitioner takeaway: Passwordless should reduce phishing exposure, but stalled adoption means organisations must compensate by hardening the trust-transfer points where impersonation actually happens.
Related resources from NHI Mgmt Group
- Why do passwordless logins still leave organisations exposed to impersonation risk?
- Which identity controls should organisations pair with passwordless to reduce the risk of impersonation and unsafe fallback access?
- Why do ephemeral credentials still leave risk in machine access models?
- How can organisations reduce shadow AI risk without blocking adoption?
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 8, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org