Many businesses can truthfully say they have enabled multi-factor authentication and still remain vulnerable to account takeover.
The reason is simple: MFA is a category, not a single level of protection.
A texted code, a push notification, an authenticator-app code, and a FIDO security key all add protection beyond a password. They do not resist the same attacks.
For business leaders, the decision should not be “MFA or no MFA.” It should be:
Which authentication method is appropriate for each user, application, and business consequence?
Why ordinary MFA can still fail
Some authentication methods ask users to manually enter a code. An attacker operating a convincing fake login page can capture that password and code, then relay both to the legitimate service.
Push notifications can also be abused through repeated prompts or social engineering. A user may approve a request simply to stop the interruption.
NIST’s current definition of phishing resistance focuses on preventing authentication secrets or valid outputs from being disclosed to an impostor verifier without depending on the user noticing the deception. It explicitly says manually entered one-time codes are not phishing-resistant because they are not bound to the specific authentication session. pages.nist.gov
This does not mean conventional MFA is worthless. CISA says any MFA is better than none, but describes phishing-resistant MFA as the preferred standard. cisa.gov
What phishing-resistant authentication changes
FIDO/WebAuthn authenticators—including appropriately implemented security keys and passkeys—use public-key cryptography and bind authentication to the legitimate website.
Instead of giving the user a reusable secret to type, the authenticator proves possession of a private key associated with that service. A fake website cannot simply collect and replay a valid code.
NIST finalized Digital Identity Guidelines Revision 4 in July 2025. The update integrates syncable authenticators such as passkeys, and its AAL2 requirements say services must offer at least one phishing-resistant option. pages.nist.gov
That is a meaningful signal for private businesses even when the federal requirements do not apply directly to them.
Prioritize by business impact
A company does not necessarily need to migrate every account on the same day. Begin where an account takeover would have the greatest consequence:
Identity-platform and directory administrators
Cloud, security, and infrastructure administrators
Email and collaboration administrators
Finance, payroll, and payment approvers
Executives and executive-support staff
Software-development and source-code administrators
Customer-support users who can reset identities
Third parties with privileged or persistent access
This risk-based sequence reduces the most dangerous exposure first.
Passkeys and security keys involve tradeoffs
Phishing-resistant authentication is strong, but implementation still requires business decisions.
Synced passkeys can improve usability across a person’s devices. Their security also depends on the protections and recovery process of the synchronization account.
Hardware security keys can offer strong isolation and are useful for highly privileged users. They introduce purchasing, inventory, replacement, and remote-worker logistics.
Device-bound credentials can support managed-device policies but need careful handling during device replacement and disaster recovery.
NIST recommends controls around sync-fabric access, recovery, notifications, multiple bound authenticators, central identity management, and periodic review of registered keys. NIST Pages
The right answer may therefore differ between a customer portal, a managed employee laptop, and a cloud administrator.
Treat recovery as part of authentication
A secure sign-in method paired with a weak help-desk reset process is not a secure identity system.
Before rollout, define:
How users enroll their first authenticator
Whether a second authenticator is required
How lost devices are reported
What evidence the help desk requires
Which recovery actions need secondary approval
How recovery events are logged and alerted
How former employees and vendors are deprovisioned
How registered authenticators are reviewed and revoked
Test these procedures with realistic scenarios. Attackers frequently target the exception path because organizations focus only on normal login.
A practical rollout plan
Phase 1: Inventory
Identify the identity providers, business applications, privileged roles, existing MFA methods, unmanaged exceptions, service accounts, and recovery processes.
Phase 2: Define tiers
Create a simple authentication standard:
Phishing-resistant authentication required for privileged and high-impact access
Strong MFA required for the broader workforce during transition
Documented, time-limited exceptions with named owners
Separate controls for non-human identities
Phase 3: Pilot
Use a representative group spanning executives, administrators, remote employees, support personnel, and multiple device types. Measure enrollment failures, recovery requests, application compatibility, and user friction.
Phase 4: Deploy
Roll out by risk rather than alphabetically. Provide clear instructions, spare authenticators where appropriate, and a verified support process.
Phase 5: Monitor
Track enrollment coverage, fallback usage, recovery activity, legacy authentication, repeated failures, dormant accounts, and privileged accounts without the required method.
The business outcome
Phishing-resistant authentication does more than improve a technical control. It can reduce dependence on users identifying perfect imitations of login pages, strengthen privileged access, and create a clearer identity standard for employees and vendors.
The goal is not to buy security keys indiscriminately or announce a passwordless initiative before applications are ready. It is to build an authentication architecture proportional to business risk—with enrollment, recovery, monitoring, and deprovisioning designed as one system.
Up In Mars can help organizations inventory authentication methods, prioritize high-risk access, evaluate passkey and security-key options, and develop a phased identity-security roadmap.