Passwordless Authentication Implementation Checklist

Passwordless projects rarely fail on cryptography. They fail on enrolment, on recovery, and on the two or three populations nobody scoped. The sequence that works is: baseline what passwords actually cost you, choose a method per population, pilot with a group that will tell you the truth, then roll out by department with the old login still running in parallel. Budget six months end to end for an organisation of any size, and expect the recovery design to take longer than the integration.

This is the execution checklist. If you have not yet decided which method to deploy, start with the companion passwordless authentication selection matrix, which compares passkeys, FIDO2 security keys, push approval, magic links, and one-time codes on security, cost, assurance level, and rollout effort. That page answers "which one". This page answers "how do we ship it".

Last verified: September 2026. Aligned to NIST SP 800-63B-4 (final, July 2025), W3C WebAuthn Level 3 (a Recommendation since 25 August 2026), and the FIDO Alliance State of Passkeys 2026 report and Passkey Index.

Before you start: the four decisions that shape everything

Settle these four before Phase 1, because every later task inherits them.

• Scope. Workforce, customers, or both. They are different programmes with different success metrics. Workforce is measured in helpdesk load and assurance. Customer is measured in conversion and account takeover rate.
• Assurance obligation. If any framework, contract, or regulator pins a population to AAL3 or an equivalent, that population needs device-bound hardware. Synced passkeys do not qualify under NIST SP 800-63B-4, because the private key is exportable by design.
• Build or buy. WebAuthn is a day of work. Conditional UI, credential discovery, cross-device fallback, enrolment prompting, and recovery are the other eleven months. Most teams should buy the platform and spend their engineering on the flows.
• Rollback path. Decide, in writing, what triggers a rollback and how fast it can execute. A passwordless cutover you cannot reverse is a production risk, not a security improvement.

Phase 1: Assessment (weeks 1 to 2)

Current state analysis

• Document every authentication method currently in production, including the forgotten ones behind legacy apps.
• Count password-related helpdesk tickets over the last three months, and separate resets from lockouts from "cannot receive the code".
• Calculate the current fully loaded cost: helpdesk time, lost productivity, SMS or email delivery spend, and any per-factor licence fees.
• List every application requiring authentication and mark which speak a modern protocol (OIDC, SAML) and which do not.
• Identify the high-priority systems for migration, ranked by worst-case impact of a compromised account.
• Pull a baseline of account takeover incidents and credential-stuffing volume, so you can prove the change later.

Technical assessment

• Audit the existing identity infrastructure: directories, identity providers, federation, and any homegrown session logic.
• Record the compliance and assurance requirements per population, not for the organisation as a whole.
• List the supported protocols per application and flag anything still using basic auth, LDAP bind, or a proprietary token.
• Identify legacy systems that cannot be migrated and decide now whether they get an identity-aware proxy, a shim, or a retirement date.
• Survey device and browser capability across the population, including OS versions old enough to lack passkey support.
• Check that logging and SIEM can distinguish an authentication event from an authorization event, and that both carry the method used.

User and population analysis

• Segment users by worst-case impact and by the hardware they actually own, not by org chart.
• Explicitly enumerate the hard populations: frontline staff without a company phone, shared and kiosk devices, contractors on unmanaged machines, users in regions with poor SMS delivery, and users who cannot complete a biometric enrolment.
• Document accessibility requirements. Biometric enrolment excludes some users, and the fallback for them must be designed, not improvised.
• Survey password pain points to build the internal case, and capture the quotes.
• Identify a pilot group that is technical enough to report problems precisely and honest enough to complain.

Phase 2: Planning (weeks 3 to 4)

Method and vendor selection

• Choose a primary method per population and a designed backup for each, using the selection matrix.
• Define required features before seeing a demo, so the demo does not define your requirements.
• Confirm the platform supports conditional UI (WebAuthn autofill), because discoverability is the single largest driver of enrolment rate.
• Confirm it supports both synced and device-bound credentials, and that you can require device-bound for the privileged population.
• Check the export path before you sign. Import tooling is a sales function and export tooling is a retention risk, so ask specifically what you can get out and in what format.
• Price hardware at list plus a realistic replacement rate, and buy two keys per user where hardware is in scope.
• Run a timeboxed proof of concept against your real identity data, not a demo tenant.

Recovery design (do this before anything else)

This section is first in importance and last in most project plans. Reverse that. The recovery path becomes the attack surface for the whole system, because it is the one route that, by definition, works without the credential.

• Design a recovery path for each population and write down its assurance level. If recovery is weaker than the primary method, your real assurance level is the recovery one.
• Require at least two enrolled factors, or a second hardware key, before a user is allowed to turn off the old method.
• Decide what a helpdesk agent is and is not permitted to reset, and enforce it in the tool rather than in a policy document.
• Remove knowledge-based recovery. Security questions are public data.
• Define the high-assurance path for privileged accounts: in-person or video re-proofing, a second approver, or an escrowed spare key.
• Rate-limit and alert on recovery attempts, and treat a spike as an incident signal.
• Write the social-engineering scenario for your helpdesk and test it with a tabletop exercise.

Implementation strategy

• Create a phased timeline with named owners per phase, not a single go-live date.
• Define success metrics and their baselines now, because retrofitting a baseline is not possible.
• Design the enrolment prompt strategy: when to ask, how often to re-ask, and when to stop asking. Prompting on every login trains users to dismiss.
• Plan the communication sequence and write the "why" in user language, not security language.
• Write the rollback procedure and the trigger thresholds.
• Decide the deprecation date for each legacy method and publish it internally.

Risk management

• List the failure modes explicitly: platform account lockout, device loss, browser without support, corporate link scanner burning single-use tokens, and helpdesk social engineering.
• Plan mitigation for each, and assign an owner.
• Update security policy and the authentication standard to name the approved methods and the banned ones.
• Extend incident response to cover a compromised enrolment, which is different from a compromised session.
• Confirm the privacy position on biometrics in writing: with platform authenticators the biometric never leaves the device, and your privacy review should record that explicitly.

Phase 3: Pilot (month 2)

Preparation

• Stand up a test environment that mirrors production identity data shape, including the awkward accounts.
• Configure the chosen platform, including conditional UI and the enrolment prompt rules.
• Write user guides with screenshots per platform, because Windows Hello, Face ID, and Android all look different.
• Train support staff on the new failure modes and on what they are forbidden to reset.
• Instrument everything before the pilot starts: enrolment funnel, authentication success rate, time to authenticate, and fallback usage rate.

Pilot launch

• Brief the pilot group on what to expect and how to report a problem.
• Enable the new method alongside the old one. Do not remove the old path during a pilot.
• Monitor enrolment drop-off at each step, which is where the real problems show.
• Track helpdesk contacts by category, and read the free text rather than the counts.
• Deliberately exercise the recovery path with real pilot users, including at least one person who deletes their credential on purpose.

Pilot evaluation

• Collect structured feedback and separate "confusing" from "broken".
• Analyse authentication logs for method mix, failure reasons, and fallback rate. A high fallback rate means the primary method is not working, whatever the satisfaction score says.
• Review any security incidents or near misses, including recovery attempts that should not have succeeded.
• Compare actual cost and effort against the plan, and correct the model before scaling it by a hundred.
• Document lessons learned and, specifically, the populations the pilot missed.

Phase 4: Rollout (months 3 to 6)

Pre-deployment

• Revise the plan with what the pilot taught you, rather than proceeding with the original.
• Rebuild training material around the questions people actually asked.
• Scale infrastructure and confirm rate limits will survive a Monday-morning enrolment spike.
• Staff the helpdesk for a week-one spike and brief them on the escalation path for recovery.
• Sequence departments from the most capable to the hardest, so the process matures before it meets the difficult populations.

User preparation

• Announce the timeline with a named deprecation date for the old method.
• Distribute platform-specific guides ahead of the enable date, not with it.
• Run live sessions for the populations with the lowest technical confidence.
• Open a dedicated support channel for the rollout and staff it visibly.
• Publish an FAQ, and put the recovery instructions where a locked-out user can reach them without logging in.

Deployment

• Roll out department by department with the old method still available underneath.
• Watch the enrolment funnel daily during the first week of each wave.
• Enforce a minimum of two enrolled credentials before removing the password for a given user.
• Require device-bound hardware for the privileged population, and verify it rather than trusting the setting.
• Track adoption and fallback rate per department, and pause a wave that goes sideways instead of pushing through it.

Post-deployment

• Remove or disable the legacy path only after the deprecation date passes and adoption holds.
• Confirm no orphaned password authentication endpoints remain reachable. This is the step most often skipped, and it silently preserves the attack you were removing.
• Recalculate ROI against the Phase 1 baseline, including the enrolment and recovery tickets that replaced the reset tickets.
• Update security documentation, the authentication standard, and the audit evidence pack.
• Schedule the review cadence below.

Ongoing operations

Monthly

• Review authentication success rate, fallback rate, and recovery volume for drift.
• Check enrolment coverage for new joiners and flag anyone still on the legacy method.
• Review recovery events that required a human decision.

Quarterly

• Re-examine the method mix against the population map, because populations change faster than plans.
• Review new platform capability. Browser and OS releases regularly change what is possible, and conditional UI behaviour in particular keeps improving.
• Re-run the helpdesk social-engineering tabletop.
• Audit the privileged population for anyone who has acquired a weaker credential.

Annually

• Run a security assessment that specifically targets the recovery path, not just the login path.
• Review the vendor: uptime, roadmap delivery, pricing changes, and the export path you asked about at purchase.
• Refresh compliance evidence against the current version of the applicable standard.
• Reassess the assurance level required per population, since regulation and contracts move.

Metrics that matter

Track a short list well rather than a long list badly. The four in bold are the ones that predict whether the programme succeeds.

Metric	Why it matters	What to compare it against
Enrolment completion rate	The share of prompted users who finish enrolment. The single best predictor of programme success.	Your own pilot result. No credible cross-industry benchmark exists.
Fallback usage rate	How often users end up on the backup method. A high number means the primary is not working.	Your pilot result, then the trend. Investigate a rise, not an absolute.
Recovery request rate	Volume and trend of account recovery. Also an attack signal.	Your Phase 1 baseline. Spikes get investigated as incidents.
Privileged coverage	Share of privileged accounts on a phishing-resistant, device-bound credential.	100%, as a policy target, verified rather than assumed.
Authentication success rate	Baseline health of the login path.	Your pre-rollout baseline. Passkey Index participants report 93% for passkey sign-ins against 63% for other methods.
Time to authenticate	The user-visible benefit you promised.	Your pre-rollout baseline. Passkey Index participants average 8.5 seconds with passkeys against 31.2 seconds with traditional multi-factor methods.
Password-related tickets	The cost case, measured net of the enrolment and recovery tickets that replace resets.	Your Phase 1 baseline. Passkey Index participants report up to an 81% reduction in sign-in-related helpdesk incidents.
Account takeover incidents	The security case.	Your Phase 1 baseline.
Legacy method usage	Proves deprecation actually happened.	Zero after the deprecation date you published.

The three figures above come from the FIDO Alliance Passkey Index, which aggregates numbers reported by nine member deployments including Amazon, Google, Microsoft, PayPal, and TikTok. They are self-reported and drawn from very large consumer services, so use them as a reference point for the direction and size of the change, not as a target your own deployment must hit. Every other row is set from your own measurement, which is why Phase 1 baselining is not optional.

The five mistakes that derail these projects

1. Shipping the primary method and improvising the backup. The improvised path becomes the weakest link and the route attackers use. Design recovery in Phase 2, not after go-live.
2. Scoping only the easy population. Frontline staff, shared devices, and contractors on unmanaged machines are not edge cases. They are where the programme stalls at 60% adoption.
3. Treating enrolment as a technical event. It is a behaviour-change exercise. Prompt strategy, timing, and wording move the number more than any platform feature.
4. Leaving the old path reachable. A disabled UI button is not a disabled endpoint. Confirm at the API layer.
5. Letting the privileged population drift. Admins get exceptions during rollout and the exception becomes permanent. Audit it quarterly and treat a gap as a finding.

How this checklist was built

Last verified: September 2026. This is a standards and documentation review, not a lab test, and it makes no hands-on benchmarking claims. What was checked: NIST SP 800-63B-4 (final, July 2025) for assurance levels and the position on syncable authenticators. W3C WebAuthn for credential models, conditional UI, and cross-device transport. The FIDO Alliance State of Passkeys 2026 report for deployment patterns. The FIDO Alliance Passkey Index (October 2025) for the three reported performance figures in the metrics table. The survey and reporting methodology of each is noted rather than assumed. Every other value in that table is set from your own Phase 1 and pilot measurement, because no credible published benchmark exists for it. The phase durations are planning estimates for sequencing the work, not measured averages.

Frequently Asked Questions

How long does a passwordless rollout take?

Plan for six months from assessment to a completed departmental rollout, with two of those months in pilot and revision. Organisation size changes the rollout duration less than you would expect, because the limiting factors are recovery design, population complexity, and legacy applications rather than user count. Hardware key programmes add one to two months for procurement and distribution.

What is the first step?

Baseline what passwords currently cost you: helpdesk tickets by category, delivery spend, and account takeover incidents over the last three months. Without that baseline you cannot prove the programme worked, and you cannot size the business case. It takes a few days and it is the step most often skipped.

Should we remove passwords entirely or run both?

Run both during rollout, then remove the password path on a published deprecation date once adoption holds and every user has at least two enrolled credentials. Leaving the password endpoint reachable indefinitely preserves the exact attack surface the project was meant to close, so a dual-run with no end date is a failed project that looks like a successful one.

How do we handle users who cannot use passkeys?

Design their path deliberately rather than leaving them on the legacy method by default. Options include a device-bound security key on a lanyard for frontline and shared-device staff, a supervisor-attested reset for populations without personal devices, and an accessible alternative for users who cannot complete a biometric enrolment. Enumerate these groups in Phase 1, because finding them in month four is what stalls rollouts.

What does NIST say about passkeys?

NIST SP 800-63B-4, published in final form in July 2025, folded the earlier syncable-authenticator supplement into normative text and pushes implementers toward phishing-resistant authentication. Its operative constraint for deployment planning: syncable authenticators are not acceptable at AAL3, because the private key is exportable by design. Device-bound authenticators are required for that level.

How do we measure success?

Four numbers carry most of the signal: enrolment completion rate, fallback usage rate, recovery request volume, and the share of privileged accounts on a device-bound phishing-resistant credential. Each is read against your own Phase 1 baseline rather than an industry target. Authentication success rate and ticket volume matter, but they move slowly and can look healthy while adoption is stalling. A high fallback rate with high satisfaction scores is the classic false positive.

Related reading

Choosing the method: passwordless authentication selection matrix. Vendor selection: top passwordless CIAM platforms. Technical background: passkeys explained, WebAuthn explained, and account recovery design, which ranks recovery mechanisms by what they preserve.