Set up passwordless sign-in experience

Create a password-optional or passwordless experience for your users to make the sign-up process quicker and improve security.

Passwords are a common source of security breaches. By making passwords optional or disabling them, you can require possession-based or biometric authenticators. By removing the need to set up a password during Self-Service Registration, you can reduce the number of users who abandon enrollment.

In the authenticator enrollment policy, specify groups for which you want to make passwords optional or disabled. Users in these groups can register or authenticate into their org without having to set up a password.

Before you begin

  • Create users or have them register using Self-Service Registration. LDAP users aren't supported.
  • You can't use traditional RADIUS authentication with passwordless users. RADIUS authentication uses passwords as the primary authentication mechanism. You can use other factors for RADIUS authentication after clearing the application setting property Okta performs primary authentication. See 2FA Only (Passwordless Mode) in RADIUS applications in Okta.
  • If you disable this functionality, users who don't have an enrolled password don't seamlessly roll back. Instead they must be migrated. If you have passwordless users, contact Support before disabling this functionality.

Passwordless Self-Service Registration

Users who don't exist in the org and register through self-service are added to the groups you've specified in the profile enrollment policy. The authenticator enrollment policy corresponding to these groups decides whether these users need a password.

The user must enroll a password if the policy requires it. If the password is set up as optional or disabled in the policy, the user can sign up without enrolling a password. They still must enroll in other authenticators required by the policy.

Passwordless authentication for admin-created users

If you create a user without enrolling any authenticators for them, the user receives an activation email. The email contains a magic link that the user can use to activate their account and authenticate into their org. The user is created with Pending user action status.

If you create a user and set a password or enroll a YubiKey for them, the user is set to Active. They don't receive an activation email in this case. They can directly sign in to their org using the enrolled authenticator.

To determine whether a user requires a password, go to DirectoryPeople. A user account has one of the following statuses:

  • 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 doesn't have any authenticators enrolled by the admin. They receive an activation email.
  • Active: The user requires a password or a YubiKey, and the admin provides it. Or, the user doesn't require a password and the admin doesn't provide one.
  • Pending user action. User password selection required: Passwordless users synced from another org may have this status. These users receive the activation email. They may be required to enroll a password if their group memberships and authenticator enrollment policies require it.

Best practices

Ensure that admins can use passwords

  1. Create a separate group for admins.
  2. Create separate authenticator enrollment, global session, and authentication policies for this group.
  3. Set the group's authenticator enrollment policy to the highest priority. Drag it to the top of the list of authenticator enrollment policies (at number 1).

Ensure that only intended users can sign in without passwords

  1. Create a separate group for passwordless users.
  2. Create separate authenticator enrollment, global session, and authentication policies for this group.
  3. Set the 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 don't fall through to the default policy.
  4. Ensure that the default policy requires a password as an authenticator.
  5. Explicitly exclude your main admin account from passwordless policies.

Start this procedure

Configure the policies to make the password optional or disabled. Then create users that don't need a password. You can also remove the password requirement from the existing password-using users.

Configure policies to make password optional or disabled

  1. Configure the email authenticator. Set it for use in Authentication and recovery.
  2. Create an authentication policy.

  3. Add an authentication policy rule 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.
    • If you're using two factors, see Configure MFA for passwordless users.
    • If you're using Okta Verify as an authenticator for passwordless users, set User Verification to Required. See Configure Okta Verify options.
  4. Create a global session policy.
  5. Add a global session policy rule and set Establish the user session with to Any factor used to meet the Authentication Policy requirements.

  6. Create an authenticator enrollment policy. Set at least one authenticator enabled for authentication as required. Set up other authenticators as appropriate.

    • If 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.
    • If you've enabled User Enumeration Prevention, a user signing in to the org for the first time from a particular device gets a sign-in prompt that asks them for a password or email. You can disable this setting in SecurityGeneral for a simplified sign-in experience. However, users who don't have a password can still sign in using their email as an authenticator.

Create password-optional or passwordless users

  1. In the Admin Console, go to DirectoryPeople.

  2. Click Add Person.
  3. Select a User type or accept the default. See 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. Click Save.

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

To remove the password enrollment for a user, go to DirectoryPeople. In person, go to Reset or remove passwordRemove password.

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

End-user experience

After you've configured the password-optional or passwordless experience, users can sign in or register without a password.

Sign in for the first time without a password

Admin-created users receive an activation email when an admin creates their account. The email is sent to the address that the admin specified while creating the account. The user clicks the magic link in the email or enters an OTP to verify the email address. Then they're prompted to set up security methods as required by the authenticator enrollment policy. Once they set up the security methods, they're allowed to access the org or the resource.

Register through self-service without a password

Users who don't exist in the org can register using an email magic link and optional password set-up. On the app sign-on page, the user enters their name and email address. The email magic link is sent to this address. The user clicks the link or enters an OTP to verify the email address.

In the app, they're prompted to create a password if it's configured as an optional authenticator in the authenticator enrollment policy. They're also prompted to set up security methods as required by the policy. Once they set up the security methods, they're registered.

Remove a password in the End-User Dashboard

If the authenticator enrollment policy allows, users can remove their password as a security method by going to the Okta End-User Dashboard Settings. In the Security Methods section, they select Password and then click Remove. They can set up their password back again through the same setting.