Most multi-factor authentication is not phishing-resistant, and the gap between "we have MFA" and "we have phishing-resistant MFA" is where a lot of organisations are currently sitting without knowing it.
What the term means
A method is phishing-resistant when an attacker cannot use it even if the user falls for the fake page.
That is a higher bar than it sounds. It rules out anything the user can read off a screen and type somewhere else, because if the user can type it into a fake site, the attacker can forward it to the real one within the seconds it stays valid.
The technical property that clears the bar is domain binding. The credential is cryptographically tied to the legitimate domain, and it simply will not produce a signature for a different one. The user cannot override that by being fooled, which is what makes it resistant rather than merely strong.
What does not qualify
SMS codes. Phishable, and separately vulnerable to SIM swapping.
Authenticator app codes, the six digits from Microsoft Authenticator, Google Authenticator or any TOTP app. Better than SMS, still typed by a human into whatever page asked for them.
Push notifications with simple approve and deny. Phishable through attacker-in-the-middle proxies, and separately vulnerable to fatigue, where an attacker sends prompts until someone taps approve to make it stop.
Number matching push, where the user types a number shown on the login screen into the app, is a genuine improvement and is not phishing-resistant. A proxy relays the number as easily as the user reads it.
Email codes and voice calls. Same problem as SMS.
What does qualify
FIDO2 and WebAuthn credentials. This covers hardware security keys and passkeys, including passkeys held in Microsoft Authenticator, in a platform account or in a password manager. The credential is bound to the domain and will not sign for an impostor.
Certificate-based authentication, including smart card logon, where the credential is a certificate on a device or a key rather than a code.
Platform authenticators such as Windows Hello for Business, which use the same underlying WebAuthn mechanism.
That is the list. If a method is not on it, assume it is phishable.
Why this is now a purchasing question
Frameworks and insurers have caught up to the distinction. Requirements increasingly name phishing-resistant MFA specifically rather than MFA generally, particularly for privileged accounts and internet-facing services.
The Australian Signals Directorate's Essential Eight addresses MFA strength directly, and the maturity levels distinguish between weaker and stronger methods. If Essential Eight maturity is the reason you are reading this, the Essential Eight assessment is where to establish which level you are actually at rather than which one you assumed.
Cyber insurance applications have moved the same way. Read the question carefully, because "do you use MFA" and "do you use phishing-resistant MFA on privileged accounts" are different questions with different consequences if answered loosely.
What to buy
For general staff, passkeys are usually the cheapest route. If you run Entra ID, a passkey in Microsoft Authenticator costs nothing and satisfies the requirement.
For privileged accounts, break-glass accounts, finance approvers and anyone the app model does not reach, hardware keys. Two each, because a single key is a lockout waiting to happen and the recovery path you fall back on is not phishing-resistant.
Then enforce it. Buying keys does not satisfy anything until Conditional Access requires a phishing-resistant method for the accounts in scope, and the policy is where most of this work actually sits. That is what a Conditional Access review covers.