Configure Desktop MFA policies

External policies that define how Desktop MFA works are configured on the Windows endpoint registry keys. Additional functionality can be enabled using registry keys.

On this page

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

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 Any custom credential provider can be filtered out 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.

The Okta Desktop MFA credential provider can't be hidden with this key. Use these GUIDs to exclude the most common credential providers:

Credential providerGUIDDescription
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

Enable self-service password reset

Early Access release. See Enable self-service features.

Self-service password reset allows your users to initiate a password reset if they're locked out of their computers. Self-service password reset requires users to be online. 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, open Settings Features. Locate and enable the following Early Access features:

    • Direct Authentication

    • IdP My Account API Password

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

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

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

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

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

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

For more information, contact your account representative.

  1. In the Admin Console, go to SettingsFeatures.

  2. Locate Enforce number challenge for Desktop MFA, and click the toggle to enable the feature.

This provides enhanced security for your org, ensuring that users are only able to verify their identity when physically with both the mobile device and the computer.

Desktop Passwordless Login

Early Access release

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.

If users don't have biometrics enabled for Okta Verify on their mobile device, configure your org's policies to block the users without biometrics enabled from using passwordless sign-in flows with Okta Verify and Desktop MFA.

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

Windows Desktop MFA user experience

Support your Desktop MFA users