Set up passwordless sign-in experience

You can create a password-optional or passwordless sign-in and sign-up experience for your end users. This not only makes the sign-up process quicker but also enhances 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 thereby reduce the number of users who abandon enrollment.

How it works

This setting is 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 is created with or without a password depends on the authenticator enrollment policy and the group memberships you specify when creating the user.

If the first matching authenticator enrollment policy corresponding to the specified groups require a password, and a password isn't provided by the admin at the time of user account creation, then the user will receive an email with a link they can use to access their org and enroll a password.

If the authenticator enrollment policy specifies that the user must have a password, and a password is provided by the admin, then the user is set to active and can sign in to their org directly. No activation email is sent and the user can sign in to their org directly using the admin-provided password.

If the authenticator enrollment policy specifies that the password is optional or disabled for a user, then the user is set to active upon account creation. No activation email is sent 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 none is provided.

Users registered through self-service

Users that don’t already exist in the org and are registering through self-service are 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 users have to enroll a password.

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

Before you begin

  • You need one of the MFA SKUs enabled.

  • Users are Okta-sourced. Users can create their account through self-service registration using Profile Enrollment. Alternatively, 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 are not inadvertently 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. Place this group at the highest priority (at no. 1) in the authenticator enrollment policy.

  • Similarly, to ensure that only passwordless users can sign in without a password and everybody else is appropriately 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. Place this group at the lowest priority (just above the default policy) in the authenticator enrollment policy.

    4. Ensure that passwordless users will never fall through to the default policy. Default policy should always have a password as a required 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 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

If you’ve enabled User Enumeration Prevention, a user signing in to the org for the first time from a particular device is presented with a sign-in prompt that asks them for password or email. You may disable this setting in Security > General for a streamlined sign-in experience. However, users that don’t have a password can still use their email as an authenticator and are able to sign in.

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.

  3. Configure Global Session Policy to set Primary factor to Password / IDP / any factor allowed by app sign on rules. 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 MFA enrollment policy.

    Unless email is set to Required, password cannot 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 is 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 is added based on the applicable authenticator enrollment policy. See About MFA 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.

If any authenticator enrollment policy applicable to the user requires a password, the admin can't remove their password. Similarly, if a user’s password is disabled in all applicable policies, the admin can't set or reset their password.

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’ll 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 already 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 are not 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

This functionality may be enabled and disabled without any side effects as long as no passwordless users are created. Users who don't have an enrolled password won't seamlessly roll back if this functionality is disabled. Instead they must be migrated.

If you have passwordless users, contact Support before disabling this functionality.

  • 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.