Plan an authentication rollout around high-value accounts, practical recovery and a supported transition for employees.
Know what protection you are adding
Multifactor authentication asks for more than one type of evidence when someone signs in. The method matters. A one-time code can still be entered into a convincing fake website, and an unexpected push prompt can be approved by mistake. Stronger authentication reduces these opportunities, but it must be deployed alongside account management and a usable recovery process.
Passkeys use public-key cryptography and are associated with the legitimate service. A user typically unlocks a device or security key with a local action such as a PIN or biometric check. FIDO describes passkeys as a phishing-resistant alternative to passwords. That does not make the entire account immune to compromise: devices, recovery channels and active sessions still need protection.
Prioritise the accounts that matter most
List the services that control other services: the main identity platform, business email, cloud administration, remote access, finance and backup management. Identify administrators and people who can approve payments or access sensitive records. Starting with a manageable high-risk group makes it easier to identify compatibility and support issues before a wider rollout.
For each service, record which authentication methods are supported and what can bypass them. Look for legacy protocols, shared accounts, recovery email addresses and service accounts that behave differently from ordinary users. CISA recommends planning a move towards phishing-resistant MFA. Where that cannot happen immediately, use the strongest practical supported method while documenting the remaining gap.
Choose recovery before enrolment
A lost phone should not force the help desk to disable protection after a persuasive phone call. Define how identity is checked when someone loses an authenticator, changes a device or needs emergency access. OWASP's MFA guidance treats recovery and factor replacement as security-sensitive processes. Protect backup methods and notify users when account authentication settings change.
Decide whether the organisation permits synchronised passkeys, requires device-bound credentials for particular roles, or supports both. The appropriate choice depends on management, assurance and usability requirements. Test the complete journey on the devices and browsers employees actually use. Include contractors, accessibility needs and people who do not have an organisation-issued phone.
Pilot with ordinary working tasks
Ask a small group to sign in, approve routine work, switch devices and recover access using the documented process. Provide a concise enrolment guide and a named support route. Explain what a legitimate sign-in prompt looks like and why an unsolicited approval request should be rejected and reported. Do not collect employees' personal PINs or biometric information.
Record failures rather than treating them as resistance to change. A shared workstation, unavailable USB port or unsupported application may require a different implementation. Resolve these cases before making the policy mandatory for everyone. Temporary exceptions should have an owner, a compensating control where appropriate and a review date, so that a pilot workaround does not become permanent.
Check coverage after launch
Measure active protected accounts, remaining weaker methods, recovery events and abandoned enrolments. Review privileges when people change roles or leave. Test emergency access through an approved exercise and inspect the resulting audit records. Authentication is a continuing operational control; a successful launch is the start of that work, rather than its completion.
