Removing the password field from the login form is not the same as removing the password. If a password still exists in the account as a recovery path, an attacker can still target it. Passwordless should mean the password is gone as a credential — not gone from view.
Many passwordless logins work like this: the user signs in with a magic link or an OTP, and the experience feels password-free. But underneath, the account may still have a password set — or a password-equivalent recovery path — kept as a fallback for when the convenient method fails.
That fallback is the whole problem. An attacker does not have to defeat your shiny new login method. They attack the weakest credential the account still accepts — and a dormant password, or a "reset by email" path, is usually it.
The login screen looks modern. The attack surface underneath did not change.
Ask of any passwordless system: if an attacker knew the user's old password, could they get in? If the answer is yes, the system is password-hiding, not passwordless.
A credential that still exists can still be stolen. Passwordless only counts when there is no password left to attack.
TwinShield's passwordless is not a magic link sitting on top of a stored password. The credential is a hardware-bound key, generated in the device's secure hardware, released by biometric, signed on every request. There is no shared secret in the account for an attacker to reach.
Recovery — the place most passwordless systems quietly re-introduce the password — is handled as an explicit, policy-governed re-enrollment: a verified flow you define, not a dormant reset path. The weak fallback is not hidden better. It is not there.
MFA, when your policy calls for it, is delivered as a second factor on top — never as the thing propping up a password underneath.
If you are moving a mobile product to passwordless and want the credential genuinely gone — not just hidden — that is the conversation to have.
Talk to us →