Before you start
An inventory of privileged accounts, hardware credentials or platform authenticators, and agreement on a helpdesk verification standard.
Agree the scope and recovery plan with the service owner. Adapt the exercise to your environment.
Build a sign-in inventory for a small pilot
List the human administrative accounts and every service they use, including supplier consoles and remote access. Separate non-human identities: they need an appropriate workload-identity design rather than an interactive enrolment exercise. For each route, record its current method, policy owner and whether it supports the proposed authenticator. Start with a small approved group and a test account; do not change the whole estate at once.
Define recovery and emergency access
Write how someone proves their identity after losing an authenticator, who can approve recovery and how the action is logged. Arrange and test emergency access according to the identity provider’s guidance before tightening policy. Keep that access independently protected and monitored. Name someone who can stop the pilot or restore the previous configuration if a legitimate administrator becomes unable to work. A recovery design is a prerequisite, not a follow-up task.
Choose a supported phishing-resistant method
Use the provider’s current compatibility guidance to select an appropriate FIDO/WebAuthn method for the accounts, devices and applications in scope. CISA recommends phishing-resistant MFA; registration and policy enforcement still need separate checks. Decide how credentials will be issued, replaced and revoked. Record application limitations as exceptions with an owner and review date. Do not assume every account can use the same authenticator or recovery arrangement.
Enrol and verify before enforcement
Follow an approved identity-verification and enrolment process with each participant. Where supported by the chosen design, register an additional protected authenticator for recovery and test it. Confirm successful access to each essential pilot application before changing the policy. Record completion without recording private credential material. Stop if the user cannot reach an essential application or if the recovery route has not been demonstrated.
Apply policy to the agreed pilot group
Capture the existing configuration and use the provider’s staged or test facilities where available. Require the intended method for the scoped sign-ins, then verify a successful sign-in and a weaker route that should be rejected. Inspect the sign-in evidence rather than inferring enforcement from a registered-device list. Keep the tested emergency route available. Remove or restrict other fallback paths only after their dependencies and recovery implications are understood.
Rehearse loss without disabling every route
Use a test account or a controlled exercise to simulate a lost authenticator while keeping a verified recovery option available. Have the support team follow its written identity checks. Record the time, approver, evidence and any unexpected bypass. Confirm the lost credential can be revoked and the replacement works. If support has to improvise around its own rules, revise and retest the process before expanding the rollout.
Decide whether to extend the pilot
Produce a route-by-route result: enforced method, successful tests, rejected weaker methods, recovery outcome and remaining exceptions. Check that ordinary work remains possible and support can repeat the recovery steps. Assign unresolved routes before scheduling a wider rollout. Stronger sign-in does not address every endpoint or session risk, so keep the organisation’s device and monitoring controls in place.
What you should leave with
An approved pilot report showing which sign-in routes enforce the intended method, a completed recovery exercise and an owned exception list. Enrolment counts alone are not the completion measure.