How does Push define ‘phishing-resistant’ MFA?
In the Push admin console, you’ll notice the term Not phishing resistant used to describe any accounts that are registered for an MFA method that is not phishing resistant or that are not registered for MFA at all.
This term appears in the Vulnerable identities section of the Dashboard, and as one of the Preset filters on the Accounts page.
![Vulnerable identities - not phishing resistant segment - KB 10118](https://images.ctfassets.net/y1cdw1ablpvd/7ihbd6KaD0Dz2bIfoMi3DV/352ca6da8267d0b65b83836ce31478eb/vuln_identities_panel_dashboard_not_phish_resistant.png)
Push defines “not phishing resistant” MFA methods as any method other than those using the U2F or WebAuthn standard. Common U2F or WebAuthn authentication methods include hardware authenticators such as security keys, or device-based biometric authenticators, such as Touch ID on macOS.
MFA methods considered not phishing resistant include:
SMS
Phone call-based authentication
Time-based passcodes shared via an app or hardware token (TOTP)
Push notifications from an authentication prompt on a device
An account in Push will be flagged as Not phishing resistant if it is using a password to access the app and the account is either not registered for MFA or is registered for methods other than those using the U2F or WebAuthn authentication standards.
Note that the Push platform checks for MFA registration (not usage), so an employee may have both phishing-resistant and non-phishing-resistant MFA methods registered on a single account. While an employee may frequently use a strong MFA method, the presence of a weaker method can still pose a risk of account compromise because it could allow an attacker to use that weaker method.
You can find a full list of all the MFA methods that Push can identify in our API documentation.