The reasoning is simple. A password can be stolen from another site's breach, guessed, or phished, and any one of those gives an attacker everything. Add a second factor of a different kind, something the user has, and the stolen password alone opens nothing. The vast majority of account takeovers in the wild use a credential and nothing else, which is why enabling any second factor cuts the risk so sharply, and why every security guideline now treats it as the floor rather than an enhancement.
- Text-message codes work everywhere and are the weakest: the code travels over a network the attacker can sometimes intercept, and the phone number can be transferred to a new SIM by a persuasive call to the carrier.
- App-generated codes, time-based and rotating, remove the carrier and are defeated by a phishing page that asks for the code and relays it to the real site within the thirty-second window.
- Push notifications are convenient and vulnerable to fatigue: an attacker sends prompts until the user taps approve to make them stop. Number matching, where the user types a code shown on the login screen, blunts that.
- Hardware keys and passkeys bind the response to the site's real address, so a phishing page on a lookalike domain receives a signature it cannot use. These are the phishing-resistant factors, and the only ones that hold against a live attacker.
Where the exams and the guidance land
The standards guidance ranks authenticators by assurance level and treats phishing resistance as the property that separates the top tier. The entry-level security exams test the vocabulary of factors and the fact that text messages are the weakest; the associate-level identity exams test conditional policies that demand a stronger factor for a riskier action. The practical version of both is the same sentence: enable something everywhere, and require the resistant kind for administrators, finance and email.