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 user drop-offs.

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 group(s) requires a password, and a password is not 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 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 into 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 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 will need to change the admin-provided password upon first 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 does not require a password. No password 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 will 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 having to enroll a password.

Before you begin

  • You need an OIE org with one of the MFA SKUs enabled.

  • Users should be Okta-sourced. Users can create their account through self-service registration using Profile Enrollment. Alternatively, you as an admin can create the user accounts. Currently, you can not 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 enrollment, Okta, and app sign-on 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 enrollment, Okta, and app sign-on 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 sign-on 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 having to set 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 into the org for the first time from a particular device will be 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 will be able to sign in.

Configure policy for password as an optional or disabled factor

Configure different policies to allow end users to sign on 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 app’s sign-on 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, they both must be from different factor types (knowledge, possession, or biometric). See Multifactor Authentication.

    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 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 cannot 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, uncheck 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 tasks section below.

If any Authenticator Enrollment policy applicable to the user requires a password, the admin cannot remove their password. Similarly, if a user’s password is disabled in all applicable policies, the admin cannot set or reset their password.

End user tasks

Once 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 on their own. For example, through the End User Dashboard or a search engine. They’ll have to do the following to access the app:

  1. Enter the username. An email is sent to the address admin had specified while creating the account.

  2. Go to the inbox, and click the link or enter an OTP to verify the email address.

  3. In the app, 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. For this they’ll have to do the following:

  1. Go to the app sign-on page.

  2. Enter the name and email address. An email is sent to this address.

  3. Go to the inbox, and click the link or enter an OTP to verify the email address. The registration process will continue.

  4. Optional: In the app, set 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. Set up other factors as required in the enrollment policy.

  6. 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 can do this by going to Okta End User Dashboard > Settings > Security Methods > Password > 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 users are created who do not enroll a password (passwordless users). Users that do not have an enrolled password will not seamlessly roll back if this functionality is disabled. Instead they must be migrated.

Please contact support before disabling this functionality, if you have passwordless users at the time you disable the 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 or may not be required to enroll a password, depending on their group memberships and MFA enrollment policies.

  • RADIUS authentication uses passwords as the primary authentication mechanism. Traditional RADIUS authentication cannot 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. Please contact Okta Support if you wish to do so.