Phishing-resistant MFA requires more than asking everyone to turn on an extra sign-in step. Choose a supported method, enrol the people in scope, enforce the intended requirement and test recovery before removing older routes.
NIST’s small-business MFA fact sheet explains that one-time codes can still be phished and identifies FIDO/WebAuthn authenticators as a common phishing-resistant option. “MFA enabled” and “phishing-resistant authentication required” are different checks.
Define the accounts and applications in scope
Start with your identity provider, administrator accounts, email and other sensitive services. Map normal users, external collaborators, service accounts and emergency access separately. A policy designed for employees may not work for an unattended integration.
Document every supported sign-in path. Check whether older applications or separate admin portals bypass the central requirement. Give each unsupported path an owner and a plan rather than claiming complete coverage.
Choose methods that meet the requirement
Use your provider’s current documentation to identify supported phishing-resistant methods and their device, browser and licensing requirements. Select appropriate credentials for each role, including how they will be issued and replaced.
Do not assume that an SMS code, an authenticator code or every push prompt is phishing resistant. For a passkey deployment, use our passkey rollout guide to plan devices and recovery.
Pilot the policy before broad enforcement
Use a small group with representative devices and applications. Where the identity provider supports a report-only or test mode, use it to identify affected sign-ins before enforcement. Otherwise, plan an equivalent controlled test with your administrator.
- A user with the approved method should be able to complete the intended sign-in.
- A user without it should receive the expected enrolment or access outcome.
- An older method should not satisfy a policy that explicitly requires phishing-resistant authentication.
- Device replacement and account recovery should follow the documented verification route.
- Emergency access should remain available through a tightly controlled, monitored procedure.
Resolve exceptions without hiding them
Record the affected account, reason, responsible person, temporary control and expiry date. Resolve application compatibility and accessibility issues with the people who use the systems. Do not leave a broad group permanently excluded because one account failed a test.
Plan enforcement with a qualified administrator. A mistaken identity policy can lock out users or administrators, so confirm recovery and support access before changing the requirement.
Measure actual use
Review available sign-in records for the method used, failed access and exceptions. Enrolment counts alone do not show which method satisfied a sign-in. Retire older routes only after compatibility, recovery and operational requirements are addressed.
Recheck the policy when applications, credentials or roles change. Keep the current scope and known gaps visible to the person responsible for security.