Configure an authentication policy for Okta FastPass

Create an authentication policy that supports Okta FastPass.

This procedure provides an example of how to configure an authentication policy that allows passwordless access to apps.

With this policy, users must have Okta Verify installed and enrolled on their device (see Device registration) before they can access the apps. Users with unregistered devices are denied access to apps.

1. In the Admin Console, go to SecurityAuthentication Policies.
2. Select the policy that you want to update.
3. Click Add Rule.
4. Create authentication policy rules.

Use Rule 1 (example), Rule 2 (example), and Rule 3 (example) as a guide when setting up your authentication policy rules. In this example:

• Rule 1 allows seamless access (Okta FastPass) to the application if the device is managed, registered, has secure hardware, and the user successfully provides any two authentication factors.

• Rule 2 allows access to the application if the device is registered, not manage, and the user successfully provides a password and any other authentication factor except phone or email.

• Rule 3 denies access to all users that did not meet Rule 1 or Rule 2.

The most restrictive rule (Rule 1) is at the top and the least restrictive rule is at the bottom.

The following image reflects the rules that are provided as an example:



Rule 1 (example)

This rule applies to users with devices that are managed, registered, and have secure hardware. It allows them to have seamless access to the application. Users are prompted to re-authenticate only if it’s been more than one hour since they last authenticated.

Users matching this rule can use any two authentication factor types to access the application. If users want to access the application without entering a password, they must enable biometric authentication in Okta Verify. If they have enabled biometrics in Okta Verify, they're still prompted for their password (a knowledge factor).

1. In the Rule name field, enter a name for the rule. For example, Passwordless: Allow Registered + Managed + Hardware present + 2 factors.
2. Use the following configuration as a guide for rule 1:

Condition	Configuration	Description
IF User's user type is	Any user type	Configures the user type that can access the app. Select one of the following: Any user type (default): Any user type can access the app. One of the following user types: Only specific user types can access the app. In the fields that appear when this option is selected, enter the user types to include and exclude.
AND User's group membership includes	Any group	Configures user groups that can access the app. Select one of the following: Any group (default): Users that are part of any group can access the app. At least one of the following groups: Only users that are part of specific groups can access the app. In the fields that appear when this option is selected, enter the groups to include and exclude.
AND User is	Any user	Configures users that can access the app. Select one of the following: Any user (default): Allows any user to access the app. At least one of the following users: Only allows specific users to access the app. In the fields that appear when this option is selected, enter the users to include and exclude.
AND Device state is	Registered	Configures whether devices must be registered to access the app. Select one of the following: Any (default): Registered and unregistered devices can access the app. Registered: Only registered devices can access the app.
AND Device management is	Managed	Configures whether devices must be managed to access the app. Select one of the following: Not managed (default): Managed and not managed devices can access the app. Managed: Only managed devices can access the app.
AND Device assurance policy is	Any one of the following device assurance policies	Configures the security-related device conditions that are required. Select one of the following: No policy: No device assurance policy is required. Any of the following device assurance policies: From the list that appears when this option is selected, select the required device assurance policy. You can add more than one device assurance policy to cover other scenarios. See Add device assurance to an authentication policy.
AND Device platform is	Any platform	Configures the device platform needed to access the app. This option can't be changed from the default if specific device assurance policies are selected in the previous step. Select one of the following: Any platform (default): Any device platform can access the app. One of the following platforms: Only specified device platforms can access the app. From the list that appears when this option is selected, select one or more of the following: IOS ANDROID WINDOWS MACOS CHROMEOS MOBILE_OTHER DESKTOP_OTHER
AND User's IP is	Any IP	Configures the network zone required to access the app. Select one of the following: Any IP (default): Devices with any IP address can access the app. In any network zone defined in Okta: Only devices in a network zone defined in Okta can access the app. In any of the following zones: Only devices within the specified zones can access the app. Enter specific zones in the field that appears. Not in any network zone defined in Okta: Only devices outside of the network zone defined in Okta can access the app. Not in any of the following zones: Only devices outside of the specified zones can access the app. Enter specific zones in the field that appears.
AND Risk is	Any	Configures the risk score tolerance for sign-in attempts. Select one of the following: Any (default): The risk score can be low, medium, or high. Low: The risk score must be low. Medium: The risk score must be medium. High: The risk score must be high. See Risk scoring.
AND The following custom expression is true	Optional	Configures additional conditions using the Okta Expression Language (EL). See Okta Expression Language for devices.
AND Client is	Any client	Configures the clients that can access the app. Select one of the following: Any client (default): Any client can access the app. One of the following clients: Only specified clients can access the app. Choose one or more of the following: Web browser Modern Authentication Exchange ActiveSync/Legacy Auth
THEN Access is	Allowed after successful authentication	Configures the resulting app permissions if all the previous conditions are met: Denied: The device is denied access when all the IF conditions are met. Allowed after successful authentication: The device is allowed access when all the IF conditions are met and authentication is successful.
AND User must authenticate with	Any 2 factor types	Configures the authentication that is required to access the app: Password or Password / IdP: The user must enter a password every time the rule requires re-authentication. Possession factor: The user must provide a possession factor to authenticate. For example, Okta Verify, WebAuthn, phone, or email. Any 1 factor type or Any 1 factor type / IdP: The user must provide a possession, knowledge, or biometric authentication factor. For example, Okta Verify, WebAuthn, phone, email, password, or security question. Password + Another factor or Password / IdP + Another factor: The user must provide a password, and any other authentication factor. Any 2 factor types: The user must provide any two authentication factors. See About MFA authenticators.
AND Possession factor constraints are	Select the following checkboxes: Hardware protection Device bound (excludes phone and email)	Configures the possession factor characteristics: Phishing resistant (clear by default): Requires the possession factor to be phishing resistant. Hardware protected (clear by default): Requires keys to be stored in a hardware-backed keystore (TPM, Secure Enclave). Note: By default, Okta Verify attempts to store the Okta Verify keys on the secure hardware of the device: trusted platform module (TPM) for Windows and Android devices, or secure enclave for macOS and iOS devices. If secure hardware is not available, software storage is used. When software storage is used, Okta Verify will not satisfy the authentication policy if Hardware protection is selected as an AND Possession factor restraints are THEN condition. To identify how Okta Verify keys are stored for a device, view the secureHardwarePresent device attribute in the Admin Console, or use an Okta Expression Language (EL) expression to determine the value of device.profile.secureHardwarePresentview. If this value is true, secure hardware is used. See Okta Expression Language for devices and . Device Bound (excludes phone and email) (selected by default): Requires factor keys to be stored securely on the device.
AND Access with Okta FastPass is granted	If the user approves a prompt in Okta Verify or provides biometrics (meets NIST AAL2 requirements)	Configures when access with Okta FastPass is granted: If the user approves a prompt in Okta Verify or provides biometrics (meets NIST AAL2 requirements) (default): The user must prove that they are physically present when using Okta FastPass to authenticate. Without the user approving a prompt in Okta Verify or providing biometrics: The user is not required to approve a prompt in Okta Verify or provide biometrics. See Add a global session policy rule for more information about this setting.
Re-authentication frequency is	Re-authenticate after: 1 Hours	Configures how often a user is required to re-authenticate: Every sign-in attempt: The user must authenticate each time they sign in. Never re-authenticate if the session is active: The user is not required to re-athenticate if they are in an active session. Re-authenticate after (default): The user is required to re-authenticate after a specified time. The default time is 2 Hours.

3. Click Save.

Rule 2 (example)

This rule applies to users with devices that are registered and not managed. It allows them to access the application after they provide a password and any other authentication factor except phone or email.

In addition to providing a password, users matching this rule can choose any enrolled authentication factor (except phone and email). If you select the option Okta Verify user interaction in this rule, users who choose Okta Verify as the authentication factor are prompted to provide user verification (biometrics).

1. In the Rule name field, enter a name for the rule. For example, Allow Registered + Not managed + 2 factor (password, possession).
2. Use the following configuration as a guide for rule 2:

Condition	Configuration	Description
IF User's user type is	Any user type	See Rule 1 (example).
AND User's group membership includes	Any group
AND User is	Any user
AND Device state is	Registered
AND Device management is	Not managed
AND Device assurance policy is	No policy
AND Device platform is	Any platform
AND User's IP is	Any IP
AND Risk is	Any
AND The following custom expression is true	Optional.
AND Client is	Any client
THEN Access is	Allowed after successful authentication
AND User must authenticate with	Password + Another factor
AND Possession factor constraints are	Select the Device bound (excludes phone and email) checkbox.
AND Access with Okta FastPass is granted	If the user approves a prompt in Okta Verify or provides biometrics (meets NIST AAL2 requirements)
Re-authentication frequency is	Set the following: Password re-authentication frequency is: 4 Hours Re-authentication frequency for all other factors is: 15 Minutes

3. Click Save.

Rule 3 (example)

This rule applies to users that did not match Rule 1 or Rule 2. It is a catch-all rule that denies access to the application.

1. In the Rule name field, enter a name for the rule. For example, Catch-all Rule.

2. Use the following configuration as a guide for rule 3:

Condition	Configuration	Description
IF User's user type is	Any user type	See Rule 1 (example).
AND User's group membership includes	Any group
AND User is	Any user
AND Device state is	Any
AND Device assurance policy is	No policy
AND Device platform is	Any platform
AND User's IP is	Any IP
AND Risk is	Any
AND The following custom expression is true	Leave blank.
THEN Access is	Denied

3. Click Save.

Related topics

• Authentication policies
• Add an authentication policy rule
• Add device assurance to an authentication policy