Protect the whole sign-in journey
Multifactor authentication adds protection when a password is stolen, but methods differ. A one-time code can still be entered into an attacker-controlled page. FIDO/WebAuthn-based authentication ties the exchange to the legitimate service, making it a stronger choice against credential phishing. That distinction matters when selecting controls for accounts whose compromise would have a broad impact.
The implementation is also a service design problem. People must enroll, sign in from approved devices, replace lost authenticators and get support without creating an easier route around the control. Map that full journey before buying hardware keys or changing a tenant-wide setting. A secure primary sign-in flow is incomplete if account recovery can be persuaded to bypass it.
Inventory accounts before choosing a pilot
List administrators, ordinary users, contractors, shared operational accounts and service identities separately. Identify which applications use the central identity provider and which keep their own authentication. Include older clients and remote access tools. A rollout percentage is misleading when its denominator excludes the systems that matter most.
Choose a pilot with enough variety to reveal friction: different supported devices, remote workers, accessibility needs and at least one high-value administrative workflow. Agree on success criteria before the pilot begins. Successful enrollment alone is insufficient; users should complete their normal work, recover from a lost device and receive help through a documented support process.
Choose authenticators around the actual environment
Platform authenticators and roaming hardware keys support different working patterns. Device ownership, shared workstations, browser support and the needs of administrators all affect the choice. Verify capabilities with your identity provider and applications rather than assuming every product labelled “passwordless” provides identical protection.
For a sample rollout, an organisation might support platform authenticators for managed individual devices and hardware keys for a smaller set of privileged workflows. This is an example, not a universal prescription. Test the complete chain, including enrollment policy, cross-device use where supported, conditional access and the treatment of an unmanaged device. Make the supported options easy to understand.
Treat recovery as a privileged operation
Define how a person proves their identity when their usual authenticator is unavailable. Decide who can approve recovery, what evidence is required and what alerts should be generated. A convincing phone call or an urgent message from a purported executive should not be enough to reset a powerful account. Help-desk staff need a usable procedure and permission to follow it under pressure.
Where appropriate, arrange a second approved authenticator and test it before it is needed. Emergency administrative access needs separate controls, monitoring and periodic verification. Document its purpose and tightly restrict its use. Do not distribute reusable emergency credentials in ordinary chat or hide them inside the systems they are meant to recover.
Close the old routes deliberately
After a pilot, review all remaining authentication paths. Legacy protocols, local application passwords, excluded accounts and long-lived sessions may reduce the benefit of a stronger sign-in method. Make exceptions visible, time-limited where possible and owned by someone responsible for removing the underlying obstacle.
Roll out in stages with a clear support window and a tested rollback decision. A rollback should not silently leave the organisation in a weaker state forever. Record the reason, affected users and next attempt. Tell people what a genuine enrollment prompt looks like and where to find support through a channel they can independently verify.
Measure protection and user experience together
Track coverage of high-value accounts, successful use of the required authentication method, unresolved exceptions, recovery requests and support failures. Compare the policy you intended to enforce with observed sign-in behaviour. Ask whether a user can still reach a sensitive service through a weaker fallback.
Run a tabletop exercise in which an attacker requests an authenticator reset, then another in which a legitimate administrator loses every enrolled device. The first tests resistance to manipulation; the second tests whether the process remains usable. Strong authentication succeeds when the organisation can sustain it during normal work and stressful exceptions, not just demonstrate it in a clean pilot.