Check what the sign-in method actually requires
Multi-factor authentication covers a wide range of strength. A push notification that can be approved by a tired person on a phone, a code read out over the phone, and a hardware-backed credential bound to the site all satisfy the same tick box and behave very differently under a real phishing attempt.
CISA's guidance is explicit that phishing-resistant methods — FIDO/WebAuthn based — are the preferred target, with other methods treated as a step on the way rather than the destination.
Map where sign-in actually happens
Before choosing a method, list the routes into your environment: the identity provider, anything federated to it, legacy protocols still enabled, service accounts, VPN and remote access, and the administrative consoles held outside the main directory.
If a legacy route bypasses the new requirement, it may leave access exposed. Record whether each route supports the intended policy and how any exception will be handled.
Design recovery at the same time as enrolment
Every strong method needs an answer to a lost device on a Friday afternoon. A weak recovery process can undermine the protection at sign-in. If the helpdesk can reset a factor after a plausible phone call, the effective control is the helpdesk script.
Decide what proof you require, who is allowed to give it, and how the event is logged. Write it down before enrolment starts, because it will be tested in week one.
Start where the damage is concentrated
Privileged accounts are the sensible first group: small enough to support closely, valuable enough to justify the friction, and staffed by people who can tell you where the process breaks.
Run the enrolment with them in the room, fix what turns out to be awkward, then widen it. Publish the timetable for the rest of the estate so the pilot does not become the permanent scope.
Check the policy as well as the registration
Registering a stronger authenticator does not by itself prove a sensitive sign-in requires it. Use a test account and an agreed pilot group to check the policy on each important route. Confirm the expected method is required, inspect the resulting sign-in record and test a route that should be denied.
Keep an independently tested recovery route before changing access requirements. Record exceptions with a reason, owner and review date. Do not remove fallback methods across the estate in one step simply because a few successful enrolments have been recorded.
What a finished pilot should demonstrate
A useful pilot report names the accounts and applications covered, which sign-in methods were accepted, the recovery test result and any uncovered routes. It also records the support effort: a technically strong design that nobody can recover from needs further work.
Phishing resistance does not remove every account risk. A compromised endpoint or stolen session still needs attention. Keep device security, session handling and monitoring in scope, and use the sign-in change as one part of the broader identity service.
Sources
Practical suggestions in this article are editorial recommendations. The source supports the guidance attributed to it.
- CISA: Implementing phishing-resistant MFA ↗
Checked 8 September 2026
Something needs correcting?
Get in touch to explain which claim needs attention and share the supporting source.