QWYK ID is built to prefer passkeys first. Passkeys provide phishing-resistant, hardware-backed authentication and allow us to avoid relying on shared secrets as the primary foundation of identity.
Where passkeys are unavailable, we support multi-factor fallback. Users may still verify their email, create a password, and enroll secondary verification methods such as our mobile app, an authenticator app, or email OTP. A password alone is never sufficient
We do not treat these methods as equivalent. Passkey-backed authentication carries a higher level of assurance than password-based fallback, and our policies for login, recovery, and sensitive account changes reflect that distinction.
Passkeys should be the default authentication method for modern identity systems because they are phishing-resistant, hardware-backed, and do not depend on shared secrets stored on the server. QWYK ID is built around that model, but we also recognize that real-world onboarding, device compatibility, and recovery flows sometimes require a fallback path.
Our position is straightforward: passkeys are the preferred rail, but when passkeys are unavailable, access should require at least two weaker factors used together rather than a password alone. That preserves broader accessibility without pretending that password-based fallback offers the same assurance level as WebAuthn-based authentication.
What this means in practice
QWYK ID prefers passkeys as the primary login and registration method because passkeys use asymmetric cryptography, with the private key held on the user’s device and the public key stored by the service. If the database is exposed, the public key cannot be used to impersonate the user.
However, QWYK ID may still require users to verify their email, create a password, and enroll a second factor such as a mobile app, authenticator app, or email OTP. In that model, passkeys remain the strongest path, while password-based authentication is treated as a fallback path that must always be paired with another factor.
Why passkeys come first
Passkeys are not simply a convenience feature. They are a structural improvement over passwords because they are designed to resist phishing and cannot be replayed on a fake domain in the same way as traditional credentials.
CISA-aligned guidance identifies FIDO2 and WebAuthn as phishing-resistant authentication methods, while common OTP-based methods such as email OTP, SMS OTP, authenticator app codes, and push approvals do not provide that same phishing resistance. That distinction matters when a platform wants to claim a security-first posture.
Why fallback still matters
Even strong authentication systems need a compatibility and recovery model. Some users will be on older devices, some will interrupt the passkey ceremony, and some will lose access to their enrolled device.
Best-practice guidance on passkey deployment generally recommends using passkeys as the primary method while maintaining backup and recovery options appropriate to the risk level of the service. In other words, fallback can exist, but it should be constrained and intentionally designed.
We want to be clear…
“passwords with extra steps are NOT equal to passkeys”
That fallback only exists for continuity, but it carries lower assurance than hardware-backed authentication.
On QWYK ID…
- Password-only access is not permitted.
- If passkeys are unavailable, users must authenticate with at least two, sometimes more weaker factors in combination.
- Passkeys are the preferred authentication method always.
- Sensitive account actions always require step-up verification and shall favor passkey-based confirmation when available. For this reason, we require our users to always be logged in onto the QWYK ID mobile app.