Passkeyless means an authentication flow that does not use passkeys. It usually relies on another method such as passwords, one-time codes, or device-bound factors, so it does not get the phishing resistance and credential replay protection that passkeys provide.
How passkeyless authentication works
Passkeyless authentication is still authentication, but it uses a different proof method than passkeys. In practice that usually means the user proves access with a password, one-time code, or another non-passkey factor, so the sign-in flow stays familiar but materially weaker than passkey-based login.
The key distinction is not whether the flow is “modern” or “old,” but whether the method is phishing-resistant and replay-resistant. Passkeys are designed to bind authentication to the site and device context; passkeyless flows often shift trust back to secrets or codes that can be copied, intercepted, or reused.
Why passkeyless sign-in is less resilient
Passkeyless flows usually depend on something an attacker can ask for, capture, or redirect: a password, SMS code, email code, push approval, or a fallback factor. That makes them easier to abuse with phishing, adversary-in-the-middle tooling, credential stuffing, SIM swap, or session theft than passkey-based authentication.
The weakness is not limited to a single factor. Even when a second step exists, it may only prove recent access to a channel rather than possession of a strong cryptographic authenticator. That difference matters because phishing resistance depends on the authenticator design, not just on the number of steps a user completes.
For a fuller comparison of the trust model behind passkeys and stronger sign-in patterns, see the Passwordless and Passkeys Guide.
Where organisations still use passkeyless flows
Many organisations keep passkeyless paths for legacy application support, account recovery, fallback access, or staged rollout. That can be operationally sensible, but it means the weakest accepted method often becomes the effective ceiling for account security.
Passkeyless methods also tend to persist where user population, device diversity, or vendor support makes universal passkey adoption difficult. In those environments, the authentication design should be treated as a layered system, with stronger methods preferred and weaker methods tightly limited rather than treated as equivalent options.
Guidance on workforce sign-in choices and the operational trade-offs around recovery and phishing resistance is covered in the Workforce Identity Security Guide.
What passkeyless changes for assurance and recovery
Passkeyless authentication lowers the assurance level of the login journey because the user is no longer proving possession of a phishing-resistant authenticator. That affects not only primary sign-in, but also recovery, step-up authentication, and how confidently a system can treat a successful login as evidence of the right actor.
Recovery becomes especially important. If users can bypass a stronger method through easy resets or weak backup channels, the organisation may have deployed passkeys but still retained a vulnerable path that attackers can target first.
The underlying standards for authenticator assurance and phishing-resistant authentication are described in NIST SP 800-63 Digital Identity Guidelines.
Detailed implementation considerations for sign-in ceremonies, authenticator behaviour, and verification are explained in the FIDO2 and WebAuthn Internals Guide.
Risk and Threat Considerations
Passkeyless sign-in expands the attack surface because it preserves reliance on secrets, shared channels, or user prompts that can be phished, replayed, or socially engineered. Attackers often prefer these paths because they are cheaper to scale than breaking strong cryptographic authentication.
Failure mechanism: An attacker captures, relays, or coerces a reusable credential or one-time code, then uses the resulting session or account access before the user or system can detect the abuse.
Impact: Account takeover, unauthorized access, session hijacking, and follow-on fraud become more likely, especially where recovery paths are weaker than the primary sign-in method.
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 OWASP ASVS set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-63 | Digital Identity Guidelines | Defines phishing-resistant authentication and assurance levels for digital sign-in. |
| Recommendation — Adopt phishing-resistant authenticator requirements and align fallback flows to the required assurance level. | ||
| NIST SP 800-53 Rev 5 | IA-2 — Identification and Authentication (Organizational Users) | Covers authenticating workforce users who may still use passkeyless sign-in paths. |
| IA-5 — Authenticator Management | Applies to the lifecycle of passwords, OTPs, and other authenticators used in passkeyless flows. | |
| IA-8 — Identification and Authentication (Non-Organizational Users) | Applies where external users or consumers authenticate without passkeys. | |
| Recommendation — Require strong user authentication and restrict weaker fallback methods for organizational accounts. Manage authenticator issuance, use, storage, and revocation to reduce abuse of non-passkey credentials. Apply stronger authentication requirements to external user sign-in and recovery paths. | ||
| OWASP ASVS | V6 — Authentication | Sets verification requirements for authentication strength, recovery, and factor handling. |
| V7 — Session Management | Passkeyless compromise often ends in session theft or reuse after successful login. | |
| Recommendation — Test login and recovery flows against strong authentication requirements and avoid phishable fallbacks. Verify session creation, binding, and timeout controls to limit post-authentication abuse. | ||
Practitioner Guidance
Why practitioners should care: “Passkeyless” should be treated as a descriptive warning, not a neutral label. If an environment still allows it, the organisation should know exactly which accounts, recovery paths, and applications depend on weaker authentication so that security expectations are set correctly.
What to watch for: The most important signal is inconsistency, where passkeys exist but users can still fall back to easily phishable methods for everyday access or account recovery. That is usually where the real risk sits.
Practitioner takeaway: If passkeyless access must remain, constrain it to the smallest possible surface and avoid treating it as equivalent to passkey-based authentication in policy, assurance, or incident response.