How to Implement Passwordless Authentication, Step by Step

To implement passwordless authentication, find where passwords are still used and decide who goes first. Then set up and test account recovery, and pilot with a small group while the password stays as a fallback. Widen in waves, and switch a password off for a group only when each check says yes. Each step below ends in a yes or no check that says whether to move on.

This guide is for an IT manager or business owner at a firm of roughly 250 to 2,000 people in India or the GCC. It assumes multi-factor sign-in is already on. If it is not, start with the guide to turning multi-factor sign-in on. The guide does not argue why passwords fail, choose between sign-in methods, score a checklist or cover administrator vaulting. It names no product.

Implement Passwordless Authentication in Short: Seven Steps and One Rule

These seven steps implement passwordless authentication in an order that keeps a way back for every user. Here, passwordless means the password leaves the sign-in.

Implement Passwordless Authentication, Step 1: Find Where Passwords and Codes Are Still Used

Step 1 produces one list. It holds every sign-in that still needs a password or a typed code, with the application owner beside it. Build it from the identity system’s sign-in reports, the application owners and the helpdesk. Include email, remote access, file sharing, the finance and HR applications and shared mailboxes. Service accounts are not people, so this guide does not move them. Keep them as a separate list.

Decide who signs off: the application owner, security, the helpdesk and whoever speaks to staff.

In our view, build the list before choosing any method, because it shows which applications sit outside the identity system. This is a recommendation, not a finding from a source or from a Signisys project. Without the list, it is hard to tell which applications still hold a password.

Check for Step 1: does every in-scope application have a named owner and a recorded sign-in method?

Step 2: Decide Who Goes First, and Who Is Not Ready

This step produces two lists: the groups in the order they move, and a not-yet list. CISA’s phishing-resistant MFA fact sheet, written in October 2022 for IT leaders and network defenders, asks leaders which resources they want to protect and which users are high-value targets. CISA also says a rollout to all users at once may be difficult. It gives the help desk and IT system administrators as an example of an initial group, and later phases expand on lessons learned. It suggests starting with the services that support phishing-resistant sign-in.

Split staff into groups of that kind. Name the groups before you implement passwordless authentication for any of them. The first group is the one the pilot tests.

Write the not-yet list now. It holds shared accounts, systems that do not support the new sign-in, and users without a suitable device. Step 7 gives each an owner. Administrator accounts carry an order of their own; see the risks specific to admin accounts.

Check for Step 2: is there a written initial group and a written not-yet list, each with an owner?

Implement Passwordless Authentication, Step 3: Check That Your Systems Support a Phishing-Resistant Method

Before you implement passwordless authentication for a group, Step 3 asks whether the identity system, the devices and the applications support a sign-in that resists phishing. NIST SP 800-63B is part of NIST’s 2025 digital identity guidelines (SP 800-63-4).

NIST writes for providers and verifiers, so you adapt its wording to your own decision. The same page adds that manual entry does not bind the output to the specific session, so an impostor could relay the code.

CISA’s fact sheet lists app-based one-time codes and push with number matching as vulnerable to phishing. It says SMS or voice codes should only be a last resort. The October 2022 sheet called FIDO/WebAuthn the only widely available phishing-resistant authentication it described. PKI-based methods such as smart cards were a less widely available form. Both documents are US guidance. CISA’s own table orders forms of MFA by exposure to phishing and similar attacks, but neither document ranks methods for your firm. For background, see what multi-factor authentication adds at sign-in.

For an application that does not support the method, CISA recommends identifying such systems and planning to upgrade or migrate them. It also recommends escalating the risk to senior leadership. CISA notes that some business applications can gain MFA support through the organisation’s identity and single sign-on system.

Check for Step 3: does each application in the initial group have a yes, or a named reason it is on the not-yet list?

Step 4: Set Up and Test Account Recovery Before Any Password Goes

Account recovery is the gate. NIST SP 800-63B describes it as a separate process, used when a person has lost control of the authenticators needed to sign in. It says recovery may be accomplished by repeating parts of identity proofing, using a prearranged recovery contact, or presenting recovery codes. A recovery event also causes one or more notifications to go to the person. NIST also says recovery is expected to be invoked infrequently, so it is generally less convenient than signing in. Those are NIST’s requirements and expectations for providers, and you adapt them.

These are your decisions:

• Register more than one sign-in method per person where the system allows.
• Set the identity check the helpdesk makes for a lost device.
• Decide who may approve a recovery.
• Send the person a notice after any recovery.

In our view the way back from a lost device is where a firm can re-open the weakness. Test it before the pilot group moves to passwordless sign-in.

Check for Step 4: has a person in the pilot group recovered access from a simulated lost device, and was a notice sent? If either answer is no, stay on this step.

Implement Passwordless Authentication, Step 5: Pilot With the Password Still Available

The pilot tries passwordless sign-in on real users while the password stays as the way out. Choose a small group from Step 2. Plan enrolment, which can use a one-time temporary access method for the first sign-in. Describe it in plain words, tied to no product. Test on real devices and browsers, and include a lost device and a failed sign-in.

Write down the measures before the pilot starts, and set no target you have no basis for:

• Sign-in success.
• Helpdesk contacts.
• Recoveries completed.

You set any target yourself, from your own baseline. This article gives none.

Watch the pilot against the Step 4 recovery path as well as the sign-in itself. If a pilot user is unable to recover access, the group fails the check even when the sign-in works.

Check for Step 5: did every pilot user sign in without a password at least once on each device, and did the helpdesk close every case?

Step 6: Widen in Waves and Switch Passwords Off Where the Checks Say Yes

When you implement passwordless authentication wave by wave, each wave gets its own yes or no on the three gate checks. They are support (Step 3), recovery (Step 4) and pilot (Step 5). Switch the password off for a wave only if all three are yes for that group. Otherwise the group stays on the fallback until you fix the failing check.

Stage the removal in two moves: stop prompting for the password, and later remove it where the identity system allows. The two moves let a group run without the prompt while the password still exists as a way back.

CISA says later phases can expand from an initial group, incorporating lessons learned from earlier ones. It also says that when users resist, IT security leadership should present the risk to senior leadership for a decision. Both lines are CISA’s US guidance.

Check for Step 6: has the wave owner signed off the three gate checks in writing? If not, the group keeps its fallback.

Step 7: Give Every Exception an Owner, and Measure

An exception is any account or system that stays on the old method, such as shared accounts, older systems, users without a suitable device and service accounts. Give each one a named owner, a reason, a review date and a compensating step. That step can be the stronger multi-factor method the firm already uses. That last choice is the reader’s, not a product claim. CISA’s route for a system without MFA support matches Step 3. Identify it, plan to upgrade or migrate it, and escalate the risk.

After go-live, track the same three measures as the pilot. Add the number of sign-ins that still fall back to a password. Set the target yourself.

Get specialist help in three cases. One is an older system that does not take the new sign-in. Another is a lost-device test showing that recovery does not work. The third is a large group of shared accounts.

Check for Step 7: does every exception have an owner and a review date? The work is complete for a group only when the answer is yes.

What This Article Leaves Out, and Where to Go Next

This article explains an order of work for passwordless sign-in, not a product choice. It does not choose a product, compare sign-in methods, or cover administrator vaulting or customer-facing sign-in. The guide also says nothing about Indian or GCC rules, because it draws on US guidance only (NIST and CISA).

Why passwords fail, a scored password checklist and the choice between passkeys and multi-factor sign-in are separate articles. For the wider picture, see Reduce Password Risk with Multi-Factor Authentication.

Signisys offers identity and access management services, and this is a Signisys offer, not neutral advice.

Signisys provides identity and access management, helping organisations control who can access what, with single sign-on, strong authentication, privileged access and automated provisioning. The exact scope is agreed for each engagement. Our Solution: Identity and Access Management (IAM). Our Service: Cybersecurity Services.

Implement Passwordless Authentication FAQ