Users stay exposed to the same credential risks that passkeys were meant to reduce, including phishing, password reuse, and server-side credential compromise. In that situation, passkeys become an optional improvement rather than the main control. Organisations get the most value when passkeys are the default sign-in path, with passwords kept only as a transition or fallback mechanism.
Passwords remain the primary control, so the authentication risk does not really change
When passwords stay first, the service still depends on a shared secret that can be guessed, reused, phished, or stolen from the server side. Passkeys may reduce some login friction, but they do not remove the core exposure unless users are actually required to authenticate with them by default.
That means the security posture is still shaped by password policy, reset flows, recovery support, and how aggressively the platform discourages password fallbacks. If the password path remains the normal path, the organisation has only added an alternative sign-in method, not replaced the weaker one.
Why passkeys underperform when they are optional
Optional passkeys tend to be adopted by the most security-conscious users first, while everyone else keeps using the familiar password path. That creates uneven protection and leaves the higher-risk population, including users who reuse passwords or are more likely to fall for phishing, exposed to the old attack surface.
Passkeys also lose much of their practical value if the platform still optimises recovery and help desk processes around password entry. If a user can be pushed back to passwords through reset, fallback, or account recovery, the credential model remains only partially hardened. For workforce sign-in patterns, the broader Workforce Identity Security Guide is useful because it ties passkeys to phishing-resistant authentication, recovery, and session risk rather than treating them as a standalone feature.
Modern identity guidance also treats the authenticator choice as material, not cosmetic. NIST SP 800-63 Digital Identity Guidelines is relevant here because it distinguishes phishing-resistant authenticators from weaker login methods and helps teams reason about assurance instead of marketing labels.
What changes operationally when passwords stay in the flow
The main operational change is that incident response, account recovery, and support tooling still have to assume password compromise is possible at any time. That means password spraying, credential stuffing, and server-side credential theft remain live concerns even if the service advertises passkey support.
It also means the service must manage two parallel authentication experiences, which can confuse users and weaken adoption. If users are not steered toward the stronger path, many will keep choosing the method that is fastest today, not the method that is safest over time. The best implementations make passkeys the default path and treat passwords as a temporary transition mechanism, not an equal option.
For control mapping and implementation guidance, NIST SP 800-53 Rev 5 Security and Privacy Controls is useful because it anchors authentication, credential lifecycle, and least-privilege expectations in a formal control catalogue.
Risk and Threat Considerations
The security risk is that organisations advertise modern authentication while preserving the legacy credential path that attackers know how to target. That leaves phishing, password reuse, credential stuffing, and password database compromise as realistic failure modes, even when passkeys are available.
Failure mechanism: Users continue to authenticate with passwords, so attacker success still depends on credential capture, replay, reuse, or server-side theft rather than being blocked by phishing-resistant sign-in.
Impact: The service retains the same account-takeover exposure that passkeys were meant to reduce, and the passkey feature becomes a partial hardening measure instead of a meaningful control shift.
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 and CIS Controls v8 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-63 | Digital Identity Guidelines | Passkeys vs passwords is an authenticator assurance question. |
| Recommendation — Prefer phishing-resistant authenticators and set passkeys as the default sign-in path. | ||
| NIST SP 800-53 Rev 5 | IA-2 — Identification and Authentication (Organizational Users) | User login choice directly affects organizational authentication strength. |
| IA-5 — Authenticator Management | Password and passkey coexistence depends on credential lifecycle and recovery controls. | |
| Recommendation — Require stronger authenticators for primary user access and limit password fallback. Manage authenticator issuance, rotation, recovery, and revocation as controlled lifecycle events. | ||
| CIS Controls v8 | CIS-6 — Access Control Management | Default sign-in method and fallback access paths are access-control decisions. |
| Recommendation — Reduce password reliance and enforce stronger default access methods. | ||
| ISO/IEC 27001:2022 | A.5.17 — Authentication information | Passwords and passkeys are both authentication information requiring governance. |
| Recommendation — Protect authentication information and govern fallback mechanisms tightly. | ||
Practitioner Guidance
What to prioritise: Treat default sign-in routing as the real control decision. If passwords are still the first choice, prioritise changing the primary login path before you spend time polishing optional passkey UX.
What to verify: Confirm that recovery, help desk reset, and step-up flows do not silently send users back to passwords for routine access. The service is not effectively passkey-based unless the fallback path is genuinely exceptional.
Practitioner takeaway: Passkeys only change the risk profile when they are the normal authentication method; otherwise, the organisation has added a better option without removing the weaker one.
Related resources from NHI Mgmt Group
- What happens when passkeys are used as the primary login method without a good recovery process?
- What happens when users can still interact with a cloned login page before detection kicks in?
- What happens when service accounts keep weak or unrotated passwords in hybrid environments?
- What happens when users are allowed to enter passwords into cloned login pages?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 25, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
