Set up passwordless sign-in experience

You can create a password-optional or passwordless experience for your end users. This makes the sign-up process quicker and also improves security:

• Passwords are a common source of security breaches. By making passwords optional or disabling them, you can make users use stronger authenticators such as possession-based authenticators or biometrics.

• By removing the need to set up a password during the self-registration process for an app, you can reduce the friction during the process and thus reduce the number of users who abandon enrollment.

How it works

This setting gets applied at a group level in Security > Authenticators > Enrollment. You can target specific groups in the authenticator enrollment policy to enable users to register and authenticate without having to set up a password.

Admin-created users

Whether a user gets created with or without a password depends on the following:

• The authenticator enrollment policy
• The group memberships that you specify when creating the user

The user receives an email with a link that they can use to access their org and enroll a password if both of the following conditions are fulfilled:

• The first matching authenticator enrollment policy corresponding to the specified groups requires a password.
• Admin didn't provide a password at the time of user account creation.

The user is set to active and can sign in to their org directly if both following conditions are fulfilled:

• The authenticator enrollment policy specifies that the user must have a password.
• Admin provides a password.

In this case, the user doesn't receive an activation email. They can sign in to their org directly using the admin-provided password.

The user is set to active upon account creation if the authenticator enrollment policy specifies that the password is optional or disabled for the user. In this case, the user doesn't receive an activation email and the user doesn't have to enroll a password. The user can sign in to their org directly using email as an authenticator.

You can find out in Directory > People whether a user requires a password, based on the user account status as follows:

User account status	Meaning
Password Expired	The user requires a password, and the admin provides it. The user needs to change the admin-provided password the first time they sign in.
Pending User Action	The user requires a password, but the admin doesn’t provide it. An email magic link is sent to the user so they can enroll their password and sign into the org.
Active	The user requires a password and the admin provides it. Or The user doesn't require a password and the admin doesn't provide one.

Users registered through self-service

Users that don’t exist in the org and are registering through self-service get added to the groups you’ve specified in the profile enrollment policy.

• If the authenticator enrollment policy corresponding to these groups requires a password, then the user has to enroll a password.
• If the authenticator enrollment policy corresponding to these groups has the password set up as optional or disabled, the user can sign up without enrolling a password.

Before you begin

• MFA should be enabled in your org.

• Users are Okta-sourced. Users can create their account through Self-Service Registration using Profile Enrollment. Or you can create the user accounts. Currently, you can't source users from any other directories such as Active Directory or LDAP.

Best practices

• Before you configure the passwordless experience, ensure that your admins continue to have passwords available. This ensures that users who don't have a password provisioned don't accidentally get blocked from signing in. To do this:

  1. Create a separate group for admins.

  2. Create separate authenticator enrollment, global session, and authentication policies for this group.

  3. Set the admin group's authenticator enrollment policy to the highest priority. Drag it to the top of the list of authenticator enrollment policies. The label for the highest priority policy is 1.

• Similarly, to ensure that only passwordless users can sign in without a password and everybody else is prompted for it, do the following:

  1. Create a separate group for passwordless users.

  2. Create separate authenticator enrollment, global session, and authentication policies for this group.

  3. Set the passwordless group's authenticator enrollment policy to the second-lowest priority. Drag it to the position just above the default policy in the list of authenticator enrollment policies. This ensures that passwordless users are subject to their authenticator enrollment policy and won't fall through to the default policy.

  4. The default policy should always require a password as an authenticator.

• Explicitly exclude your main admin account from passwordless policies.

Start this procedure

This procedure includes two types of tasks: admin and end user. Once you’ve configured the policies to make the password optional or disabled, you can then create users that don’t need a password. You can also remove the password requirement from the existing password-using users. End users can register themselves through self-service without setting up a password. Existing users can remove their passwords through the End-User Dashboard.

Admin tasks

You can perform the following tasks to create a password-optional or passwordless experience for your end users:

1. Configure policy for password as an optional or disabled factor

2. Create password-optional or passwordless users

3. Transition password-using users to password-optional/passwordless users

Configure policy for password as an optional or disabled factor

Configure different policies to allow end users to sign in without a password:

1. Configure email as an authenticator. Set it for use in Authentication and recovery. See Configure the Email authenticator.

2. Configure your authentication policy to allow end users to authenticate without a password. Set User must authenticate with to any 1 or 2 factor type option, except the ones that explicitly require a password. See Add an authentication policy rule.

   If you’re using two factors, see Configure MFA for passwordless users.

   If you plan to use Okta Verify as an authenticator for passwordless users, set User Verification to Required. See Configure Okta Verify options.

3. Configure Global Session Policy to set Establish the user session with to Any factor used to meet the Authentication Policy requirements. See Add a global session policy rule.

4. Configure the authenticator enrollment policy to set email as a required authenticator. Set up other authenticators as appropriate. See Create an authenticator enrollment policy.

   Unless email is set to Required, password can’t be set to Optional or Disabled. If the password is set to Optional or Disabled, you can't set Security Question to Required as a stand-alone authenticator for authentication. However, it’s allowed for account recovery.

Create password-optional or passwordless users

1. In the Admin Console, go to Directory > People.

2. Click Add Person.

3. Select a user type in the User type list or accept the default. See About custom user types in Universal Directory.

4. Assign the user to the group corresponding to the password-optional or passwordless enrollment policy.

5. Complete other fields.

6. In the Activation field, select Activate now.

7. In the Password field, clear I will set the password.

8. Save.

The user gets added based on the applicable authenticator enrollment policy. See About authenticator enrollment policies and rules.

End users can register themselves as described in the End user tasks section below.

Transition password-using users to password-optional/passwordless users

To remove the password enrollment for a user, go to Directory > People > person > Reset or remove password > Remove password.

End users also can remove their password as described in the End users experience section below.

End-user experience

After you’ve configured the password-optional or passwordless experience, end users can do the following tasks:

1. (Admin-created end users) Sign in for the first time without a password

2. Register through self-service without a password

3. Make password-related changes on the End-User Dashboard

(Admin-created end users) Sign in for the first time without a password

End users don’t receive an activation email when an admin creates their account. Instead, they go to the app through the End-User Dashboard or a search engine. They have to do the following to access the app:

1. The end user enters their username. An email is sent to the address that the admin had specified while creating the account.

2. The end user goes to their inbox, and clicks the link or enters an OTP to verify the email address.

3. In the app, they set up security methods as prompted. They’re prompted if security methods are required by the authenticator enrollment policy.

Once they set up the security methods, they’re allowed to access the app.

Register through self-service without a password

End users that don’t exist in the org can register themselves using an email magic link and optional password set-up.

1. The end user goes to the app sign-on page.

2. They enter their name and email address. An email is sent to this address.

3. They go to their inbox, and click the link or enter an OTP to verify the email address.

4. Optional. In the app, the end user sets up a password, if prompted. They’re prompted if the password is set up as an optional factor. They aren't prompted if the password is disabled.

5. The end user sets up other factors as required in the authenticator enrollment policy.

6. They click Finish.

The end user is now registered.

Make password-related changes on the End-User Dashboard

If permitted by authenticator enrollment policy, end users can remove the password as an authenticator through their dashboard:

• They go to Okta End-User Dashboard > Settings.

• In the Security Methods section, they can select Password and then click Remove.

They can set up their password back again through the same setting.

Known issues

• Passwordless users synced from another org may have the status Pending user action. User password selection required. These users receive an account activation link. Once they click the link, they may be required to enroll a password, depending on their group memberships and authenticator enrollment policies.

• RADIUS authentication uses passwords as the primary authentication mechanism. Traditional RADIUS authentication can't be performed with passwordless users. RADIUS can use other factors for authentication when the application setting property Okta performs primary authentication is unchecked. See 2FA Only (Passwordless Mode) in RADIUS applications in Okta.

• Currently this feature requires one of the MFA SKUs. If after enabling this feature, you withdraw from your MFA SKU, then this feature will be disabled too. However, this may cause issues with existing policies. Contact Okta Support if you want to do so.