What makes an authenticator phishing-resistant, and which common authenticators are not?

Phishing resistance needs cryptographic authentication bound to the real verifier, by channel binding or verifier-name binding (as in passkeys and client-certificate TLS); anything the user types or approves manually, such as passwords, look-up secrets, OTP codes, SMS codes and push approvals, is not phishing-resistant.

A phishing site sits between the user and the real service. Whatever the user types into it, the attacker forwards in real time, including a fresh 6-digit code. Replay resistance does not help here, because the attacker uses the code immediately.

Phishing resistance closes the gap by tying the authenticator output to the identity of the site:

• Verifier-name binding: the authenticator only signs for the domain it was registered with. With passkeys (FIDO2/WebAuthn) the browser passes the real origin, so a key for bank.ch will not sign for bank-login.example.
• Channel binding: the signature covers data unique to the actual TLS connection, as in client-authenticated (mutual) TLS with a smartcard, so a relayed signature does not fit the attacker's own connection.

NIST requires at least one phishing-resistant option at AAL2 and phishing resistance at AAL3, and it explicitly says that manual-entry authenticators (OTP, out-of-band codes) can never count as phishing-resistant.

Go deeper:

• NIST SP 800-63B-4: Phishing resistance — channel binding, verifier-name binding and why manual entry is excluded.
• WebAuthn (Wikipedia) — the web standard behind passkeys and its origin binding.