Passwordless
In authentication, passwordless describes any sign-in that does not require the user to present a memorised shared secret. In practice the term is used for two very different things, and only one of them removes the phishing problem: credentials based on public key cryptography, as against codes and links delivered over a channel.
How it works
The strong form is FIDO2 and WebAuthn. A key pair is created on the user’s device, the private key never leaves it, and sign-in is a signature over a challenge from the site. Two properties follow. There is no shared secret stored on the server, so a database breach yields public keys. And the signature is bound to the origin that requested it, so a proxy on a different domain cannot obtain a usable response. The credential in this form is a passkey, which is the word the market now searches for, and it is the only widely deployed option that resists phishing by construction.
The weak form covers magic links and one-time codes sent by email or text message. They remove the memorised password and replace it with a secret in transit, which can be intercepted, forwarded, or simply typed into an attacker’s page by a user who believes they are signing in.
What goes wrong
Marketing flattens the two into one word, and a tender that asks for passwordless will accept both. An estate that adopts emailed codes has moved the whole authentication problem into the mail platform and remains fully phishable by an adversary-in-the-middle proxy.
The second problem is the fallback. A tenant that deploys strong credentials and leaves a recovery path through a code sent by text, or a help desk that resets on the basis of a caller’s answers, is exactly as strong as that path. We do not attack the good credential; we ask for the other one, which is also why multi-factor authentication and passwordless are not alternatives to each other.
The third is a distinction that decides whether the deployment satisfies a high assurance requirement: whether the credential is synchronised across a user’s devices through a platform account, or bound to a single device and non-exportable. Synchronised credentials are far easier to roll out and inherit the security of the platform account they sync through. Device-bound credentials in hardware are what a high assurance scheme expects; confirm the exact wording of the applicable scheme before making the claim in a document.
Where this shows up in an audit
We enumerate every authentication method that is enabled in the tenant, not the one the project deployed, and we test the weakest one that still works. The finding is normally the surviving fallback rather than the new method. We also check whether legacy protocols that cannot present a modern credential are still reachable, because they bypass the whole discussion. This is part of how we review authentication in a Microsoft 365 tenant.