01Why some MFA can still be phished
A one-time code proves that someone has access to a second factor, but it does not necessarily prove that the website requesting it is legitimate. An attacker can operate a fake sign-in page that relays the password and the current code to the real service. The code may still be valid when it is used.
Push-based approvals have a different weakness: someone can be pressured into approving a sign-in they did not initiate. Repeated prompts can create confusion or fatigue. Number matching improves the approval process, but CISA treats it as an interim mitigation when phishing-resistant authentication is not yet available, not an equivalent replacement.
02What phishing resistance changes
FIDO-based authentication, such as supported security keys and passkeys, binds the authentication process to the legitimate service. Instead of handing over a reusable secret or typing a code into whichever page asks for it, the authenticator participates in a cryptographic exchange associated with the correct website. This addresses the fake-login relay problem that ordinary codes do not reliably prevent.
Availability depends on the service and the organization's configuration. Before a rollout, check which applications support the chosen method, which devices employees use and how recovery will work. A secure normal login is not enough if a help desk or fallback process can casually bypass it.
03Protect the session after the login
After authentication, a service usually maintains a session so the user does not have to sign in for every action. A stolen session cookie can sometimes give an attacker access without repeating the original MFA challenge. Phishing-resistant login does not, by itself, stop malware on a device from stealing session material.
Keep devices updated, restrict unnecessary browser extensions and review unusual account activity. If compromise is suspected, ask the responsible team to investigate and revoke relevant sessions as well as addressing credentials and the affected device. The exact steps vary by service; changing a password does not always invalidate every existing session or application grant.
04Start with accounts that can cause the most damage
Prioritize email, administrative access, finance systems and the identity service used to sign in to other applications. Pilot the new authentication method with a small group before expanding it. Test enrollment, a lost device, an unavailable employee and access from the devices people actually use.
Review fallback methods deliberately. Record who can approve recovery and what evidence they need. Keep a supported recovery option without making a weak alternative the default. Explain that an unexpected approval prompt should be denied and reported, even if the employee thinks it might be a technical error.
05Measure coverage, not just enrollment
An account with MFA enabled may still have applications or recovery paths that avoid it. Review whether important services actually enforce the intended method and whether exceptions have an owner and an end date. The goal is not a checkbox marked MFA: it is a trustworthy sign-in process, a controlled recovery process and an investigation path when a session looks wrong.