Configure access policies

External policies that define how Desktop MFA works are configured on the Windows endpoint registry keys. Enable additional functionality using registry keys.

On this page

• Configure registry keys

• Enable self-service password reset

• Enforce number challenge for Desktop MFA

• Desktop Passwordless Login

• User Verification with Biometrics

Configure registry keys

Create a PowerShell script and use your MDM solution to deploy the registry keys to your endpoints. For details see Use PowerShell scripts on Windows 10/11 devices in Intune in the Microsoft documentation.

The registry key is stored at HKLM\Software\Policies\Okta\Okta Device Access.

After initial installation, you can make updates to registry key parameters with PowerShell. Running the Okta Verify installer a second time with command-line parameters doesn't change existing registry key parameters.

Value name	Description	Values	Default value
MFARequiredList	List of users or Active Directory groups that must authenticate with MFA in addition to a password. Users who aren't in this list (including local users) don't have to authenticate with MFA. If the list is empty, users don't have to use MFA to sign in to Windows. The username format to specify individual users is username@domain.com. For groups, specify only the group name. Users must sign in to Windows at least once when the computer is online and connected to the organization's network (directly or by VPN). This resolves the users' Active Directory group membership. Users in this list are eligible to sign in using the passwordless experience. If a user isn't in this list, they're required to enter a password to gain access to the desktop computer.	REG_MULTI_SZ	* MFA applies to all users
MFABypassList	Users in this list aren't required to authenticate with MFA. If a user is listed in both MFARequiredList and MFABypassList, MFABypassList takes precedence. The username format to specify individual users is username@domain.com. For groups, specify only the group name.	REG_MULTI_SZ	Empty
MaxLoginsWithoutEnrolledFactors	Defines how many times users can sign in to Windows without an MFA method. This policy allows new users to postpone setting up MFA methods for the set number of times. If a user exceeds the sign-in attempts limit, access is denied. If a user is within this limit and hasn't yet set up a specific passwordless factor, they're prompted for another valid option. If no other options are available, the user is prompted for a password to gain access. When MaxLoginsWithoutEnrolledFactors is set to 0 and the user has an offline factor enrolled but no online factors, the user is prompted to use the offline factor.	REG_DWORD	50
MaxLoginsWithOfflineFactor	Defines how many times users can sign in to Windows with offline MFA methods (without internet access). This policy also applies when computers are online and the user authenticates with offline MFA methods. If a user exceeds the sign-in attempts limit, access is denied. The user is prompted to connect to the internet to authenticate with an online sign-in method instead.	REG_DWORD	50
MFAGracePeriodInMinutes	Defines the length of a grace period (in minutes) that a user has without needing to use MFA after locking the computer. If MFAGracePeriodInMinutes is set to 0, the user is prompted to verify their identity using MFA every time they sign in. The grace period is only applicable when locking the computer. Switching user accounts or restarting the computer prompts the user to verify their identity using MFA.	REG_DWORD	60
AdminContactInfo	Configurable string to allow end users to contact admins if they're locked out of their computer. This string has no default value. Example: Contact your Help Desk at help@org.com or call 1-800-xxx-xxxx.	REG_SZ	Empty
ExcludePasswordCredProvider	The standard Windows password credential provider is disabled by default. To show the Windows credential provider, set this value to 0. The Windows password credential provider is restored for end users.	REG_DWORD	Empty
CredProvidersToExclude	You can filter out any custom credential provider by specifying the provider GUID (for example, {60b78e88-ead8-445c-9cfd-0b87f74ea6cd}). The credential provider is hidden from end users when filtered out by this key. You can't hide the Okta Desktop MFA credential provider with this key. Use these GUIDs to exclude the most common credential providers: Credential provider GUID Description Password provider {60b78e88-ead8-445c-9cfd-0b87f74ea6cd} Username and password credentials. NGC credentials {D6886603-9D2F-4EB2-B667-1971041FA96B} Credentials for Windows Hello for Business PIN. FIDO credentials {F8A1793B-7873-4046-B2A7-1F318747F427} Credential used for FIDO2 security keys.	REG_MULTI_SZ	Empty
SelfServicePasswordResetEnabled	This value allows users to initiate a password reset if the user forgets their sign-in password. Self-service password reset is disabled by default.	REG_DWORD	0
PasswordlessAccessEnabled	This value enables passwordless access, allowing users to sign in to their device securely using non-password factors. Passwordless access is disabled by default.	REG_DWORD	0
NetworkTimeoutInSeconds	This value sets the network timeout in seconds to fetch a list of online MFA factors for validation. This timeout is for network operation only and doesn't apply to user interactions. The default value is 15 seconds. This setting is useful for users with intermittent DNS outages or other connectivity issues. The minimum value is 5, and the maximum value is 60.	REG_DWORD	15
OfflineLoginAllowed	This value indicates whether a user can sign in with an offline factor. When the policy is set to 1, users can see available offline factors. If the policy is true and OnlineLoginAllowed is false, users can only see and sign in with an offline factor. This setting is appropriate for orgs that want to use offline YubiKey for authentication and sign-in flows.	REG_DWORD	1
OnlineLoginAllowed	This value indicates whether a user can sign in with an online factor. When the policy is set to 1, users can see available online factors. If the policy is true and OfflineLoginAllowed is false, users can only see and sign in with an online factor. Offline factors aren't available.	REG_DWORD	1
SelfServicePasswordResetErrorMessage	Use this value to customize the Self Service Password Reset message for end users.	REG_MULTI_SZ	Unable to update the password. The value provided does not meet the length, complexity, or history requirements of the domain.

Enable self-service password reset

Self-service password reset allows your users to initiate a password reset if they're locked out of their computers. Users can't initiate a password reset without an internet connection. Self-service password reset can be enabled by setting the SelfServicePasswordResetEnabled registry to 1. It's disabled by default. The self-service password reset function is designed for the following users:

• Users created in Okta

• Active Directory users with delegated authentication

• Azure Active Directory users, where Okta is the Identity Provider (the password is set in Okta)

When a user changes their password with the self-service password reset feature, they're changing their Okta password, which is then synced with Active Directory or Azure Active Directory.

Before enabling the self-service password reset, ensure your Okta password policy and your AD Agent password policies match. See Sign-on policies and rules

1. In the Admin Console, go to SettingsFeatures.

2. Locate and enable IdP My Account API Password.

3. Open Security Authenticators. On the Password line, click Actions Edit.

4. Scroll to the section with the Add rule button. Click the pencil icon to edit the rule of the policy you want to modify.

   • Optional: If you use delegated authority, ensure that the policy applies to Active Directory. Under the Authentication Providers heading, use the dropdown menu to select Active Directory.

5. Next to Users can perform self-service, enable the Password reset option.

6. In the Recovery authenticators section, ensure that Okta Verify is selected.

7. Set Additional verification to Not required. Setting an additional verification requirement causes the password reset option to fail.

8. Click Save.

Enforce number challenge for Desktop MFA

Early Access release. See Enable self-service features.

You can enforce number challenge for Desktop MFA users. Enabling this feature makes all push notifications for Desktop MFA a number challenge, regardless of the authentication policy.

1. In the Admin Console, go toSecurity General.
2. Locate the Okta Device Access section.
3. Click Edit.
4. Use the dropdown menu next to Enforce number matching challenge for Desktop MFA to select Enabled.
5. Click Save.

This provides enhanced security for your org by ensuring that users can only verify their identity when their mobile device and computer are both present.

Desktop Passwordless Login

Desktop Passwordless Login can be enabled by setting the PasswordlessAccessEnabled registry to 1. It's disabled by default.

When Desktop Passwordless Login is enabled, users must sign in to their Windows computer with the password once to verify their identity. From that point on, users can sign in to their Windows computer without entering a password, by responding to a push notification. The computer must be online for passwordless access, and the user must have Okta Verify push notifications enabled. The user still has a valid password that can be used when push notifications are unavailable, the computer is offline, or if passwordless sign-in fails.

If the Windows computer is offline, the user is required to enter a password to sign in, even if the user is enrolled in passwordless login.

User Verification with Biometrics

To use Desktop Passwordless Login, you should enable User Verification with Biometrics in your Okta Verify options. If your Okta Verify options or authentication policy doesn't have user verification enabled, you shouldn't enable Desktop Passwordless Login, as you're not guaranteed that users have biometrics enabled on their mobile devices. See Configure Okta Verify options.

Without biometrics enabled, users are locked out of the computer because they can't use an online factor to authenticate. Additionally, if User Verification with Biometrics is disabled in both your Authentication Policies and your Okta Verify options, users can sign in to the desktop computer with single factor authentication. This isn't recommended. Refer to the examples to determine the expected behavior for user authentication and select the method that meets your org's needs.

Authentication Policy: User Verification with Biometrics	Okta Verify options: User Verification Required with biometrics only	User experience with biometrics enabled in Okta Verify	User experience without biometrics enabled in Okta Verify
Not enabled	Enabled	Users can authenticate with Passwordless push. Users can authenticate with an Okta Verify one-time passcode. Self-service Password Reset succeeds. This configuration offers the best balance between a secure environment and a good user experience.	Passwordless push verification fails and displays a warning. Okta Verify one-time passcode verification fails and displays a warning. Self-service Password Reset fails.
Enabled	Enabled	Users can authenticate with passwordless push. Okta Verify one-time passcode verification option isn't displayed. Self-service PasswordReset succeeds.	Passwordless push verification isn't displayed. Okta Verify one-time passcode verification option isn't displayed. Self-service Password Reset fails. With this configuration, only offline authentication factors are displayed. If the user has no offline authentication factors set up, the user can't sign in.
Enabled	Not enabled	Users can authenticate with passwordless push. Okta Verify one-time passcode verification option isn't displayed. Self-service PasswordReset succeeds.	Passwordless push verification isn't displayed. Okta Verify one-time passcode verification option isn't displayed. Self-service Password Reset succeeds. With this configuration, only offline authentication factors are displayed. If the user has no offline authentication factors set up, the user can't sign in.
Not enabled	Not enabled	Users can authenticate with passwordless push. Users can authenticate with an Okta Verify one-time passcode. Self-service PasswordReset succeeds.	This configuration isn't recommended. If User Verification with Biometrics is disabled in both the authentication policy and Okta Verify options, users can sign in with a single authentication factor, and user verification isn't required.

Next steps

Desktop MFA user experience

Support your users